You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When VS Code is on a corporate network with a TLS-intercepting (MITM) proxy, Live Preview's built-in server binds to 127.0.0.1. Accessing the preview via a remote tunnel (e.g. https://<id>-3000.aue.devtunnels.ms/) returns 401. The root cause is distinct from the host-header issue described in #462: here, the corp proxy intercepts the TLS handshake and presents a corporate CA-signed cert for 127.0.0.1, which the tunnel ingress rejects with a 401/SSL error.
Connect VS Code to a corp network with an HTTPS-intercepting proxy.
Open any HTML file → Live Preview: Start Server.
Open Command Palette → Ports: Forward a Port → forward port 3000.
Open the forwarded devtunnel URL (https://<id>-3000.aue.devtunnels.ms/) from a browser outside the corp network (or from a mobile device).
Observe 401 Unauthorized response.
Expected Behavior
The preview loads normally via the forwarded tunnel URL (as it does on non-proxied networks).
Actual Behavior
401 response. Browser network trace shows the proxy presents its own TLS certificate for 127.0.0.1; the tunnel ingress sees a cert it didn't issue and rejects the connection.
Notes
The mitmproxy / ngrok workarounds in 401 when using remote tunnel #462 do work, but they require installing extra tools that are often blocked on corp machines.
The simplest corp-safe fix would be a livePreview.serverCertificatePolicy setting or an explicit opt-in to skip TLS for loopback-only addresses, or a proxyBypass config that tells VS Code's http.proxy to exclude 127.0.0.1 from interception.
"no_proxy": "127.0.0.1,localhost" in settings.json → http.noProxy does NOT help because the interception happens at the OS/Zscaler driver level, below VS Code's Node http stack.
Workaround
Set "http.proxySupport": "off" in VS Code settings and ensure 127.0.0.1 is in the system NO_PROXY env var. Partial relief only — the tunnel ingress still validates the cert chain.
Summary
When VS Code is on a corporate network with a TLS-intercepting (MITM) proxy, Live Preview's built-in server binds to
127.0.0.1. Accessing the preview via a remote tunnel (e.g.https://<id>-3000.aue.devtunnels.ms/) returns 401. The root cause is distinct from the host-header issue described in #462: here, the corp proxy intercepts the TLS handshake and presents a corporate CA-signed cert for127.0.0.1, which the tunnel ingress rejects with a 401/SSL error.Related: #462 (generic tunnel 401, host-header workaround)
Environment
Steps to Reproduce
https://<id>-3000.aue.devtunnels.ms/) from a browser outside the corp network (or from a mobile device).Expected Behavior
The preview loads normally via the forwarded tunnel URL (as it does on non-proxied networks).
Actual Behavior
401 response. Browser network trace shows the proxy presents its own TLS certificate for
127.0.0.1; the tunnel ingress sees a cert it didn't issue and rejects the connection.Notes
livePreview.serverCertificatePolicysetting or an explicit opt-in to skip TLS for loopback-only addresses, or aproxyBypassconfig that tells VS Code'shttp.proxyto exclude127.0.0.1from interception."no_proxy": "127.0.0.1,localhost"insettings.json→http.noProxydoes NOT help because the interception happens at the OS/Zscaler driver level, below VS Code's Nodehttpstack.Workaround
Set
"http.proxySupport": "off"in VS Code settings and ensure127.0.0.1is in the systemNO_PROXYenv var. Partial relief only — the tunnel ingress still validates the cert chain.