VS Code Proxy Settings: How to Configure and Secure Them

VS Code proxy settings control how the editor and its extensions route outbound HTTP traffic, and the single most important security rule is to never disable TLS verification to make a proxy "just work." Behind a corporate firewall, VS Code needs a proxy to install extensions, check for updates, and let extensions reach their APIs. Configuring it correctly takes a few minutes; configuring it insecurely quietly turns your editor into a soft target for traffic interception.

How VS Code decides which proxy to use

VS Code resolves proxy configuration from several sources, and knowing the precedence saves a lot of confusion:

1. The http.proxy setting in your settings.json.
2. Standard environment variables — HTTP_PROXY, HTTPS_PROXY, and NO_PROXY — which VS Code respects when the setting is not defined.
3. On Windows and macOS, the system proxy configuration, which VS Code can inherit depending on the http.proxySupport value.

If none is set, VS Code makes direct connections. When both a setting and an environment variable exist, the explicit http.proxy setting generally wins for the editor's own requests, though individual extensions may read the environment variables directly.

Configuring the proxy in settings.json

The direct approach is to set the proxy in your user or workspace settings. Open the Command Palette, run "Preferences: Open User Settings (JSON)", and add:

{
  "http.proxy": "http://proxy.example.com:8080",
  "http.proxyStrictSSL": true,
  "http.proxySupport": "override"
}

A few notes on each key:

• http.proxy is the proxy URL, including scheme and port.
• http.proxyStrictSSL should stay true. This is the setting people are tempted to flip to false when they hit certificate errors, and doing so is the mistake this whole guide is warning about.
• http.proxySupport set to "override" tells VS Code to route extension traffic through its own proxy support layer, which improves consistency across extensions.

Workspace settings apply only to a project. For a machine behind a permanent corporate proxy, user settings are the better place so every workspace inherits them.

The environment-variable approach

Some teams prefer setting the proxy at the shell or system level so every tool — not just VS Code — picks it up:

export HTTP_PROXY="http://proxy.example.com:8080"
export HTTPS_PROXY="http://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

This is often the cleaner choice, because your terminal, git, npm, pip, and VS Code all read the same configuration and behave consistently. The NO_PROXY list is easy to forget and matters for security and function alike: it keeps internal hosts and localhost off the proxy path, which avoids leaking internal hostnames to the proxy and prevents breakage when a local dev server should never be proxied.

Proxy authentication and the credential trap

Authenticated proxies are where security most often goes wrong. It is tempting to embed credentials directly in the URL:

{
  "http.proxy": "http://username:password@proxy.example.com:8080"
}

Avoid this. Your settings.json frequently ends up in a dotfiles repository, a synced settings profile, or a screen share, and a plaintext proxy password travels with it. Prefer a proxy that supports integrated OS authentication, or supply credentials through a secure mechanism rather than a settings file. If you must use environment variables, at least keep them out of committed shell profiles and inject them from a secrets manager or a machine-local file that is git-ignored.

The TLS verification pitfall

Here is the core security issue with any "proxy code" setup. Corporate proxies commonly perform TLS inspection: they terminate the outbound TLS connection, decrypt and inspect it, then re-encrypt with a certificate signed by an internal CA. If your machine does not trust that internal CA, VS Code throws certificate errors, and the fastest-looking fix is "http.proxyStrictSSL": false.

Do not do that. Disabling strict SSL tells VS Code to accept any certificate, including one presented by an attacker performing a machine-in-the-middle attack. You lose the guarantee that you are talking to the server you think you are, which is the entire point of TLS. Every extension update, marketplace download, and API call your editor makes becomes tamperable.

The correct fix is to trust the corporate CA certificate properly:

• Add the internal root CA to your operating system's trust store. VS Code and its extensions generally honor the OS store, so the certificate errors resolve without weakening verification.
• Where a specific extension or a Node-based tool ignores the OS store, point it at the CA bundle explicitly (for example via NODE_EXTRA_CA_CERTS) rather than turning verification off.

You get a working proxy and keep the security property that matters. Downloading extensions over an unverified channel is a genuine supply-chain exposure — a tampered VSIX runs with your permissions — and it is the kind of build-and-tooling risk an SCA tool such as Safeguard exists to reason about, but the first line of defense is simply not disabling verification.

Troubleshooting checklist

When the proxy misbehaves, work through this in order:

1. Confirm the proxy URL, scheme, and port are correct and reachable from your network.
2. Check whether a conflicting environment variable is overriding your setting, or vice versa.
3. Verify the internal CA is in your OS trust store instead of reaching for proxyStrictSSL: false.
4. Make sure NO_PROXY covers localhost and internal hosts so local development is not routed out.
5. Restart VS Code fully — proxy changes are not always picked up live, especially for extensions.

Configured this way, VS Code proxy settings are boring in the best sense: extensions install, updates arrive, and no security property was traded away to get there.

FAQ

Where do I set proxy settings in VS Code?

Set http.proxy in your settings.json (via "Preferences: Open User Settings (JSON)"), or use the HTTP_PROXY and HTTPS_PROXY environment variables. The explicit setting generally takes precedence for the editor's own requests, while some extensions read the environment variables directly.

Should I set http.proxyStrictSSL to false?

No. Setting it to false disables TLS certificate verification and exposes your editor to machine-in-the-middle attacks on every download and API call. If a corporate proxy inspects TLS, add its internal CA certificate to your OS trust store instead.

How do I handle an authenticated proxy in VS Code?

Avoid putting the password in the proxy URL, since settings files get synced and shared. Prefer OS-integrated proxy authentication or inject credentials from a secrets manager, and keep any environment variables holding credentials out of committed shell profiles.

Why do my extensions still fail behind a proxy?

Common causes are a conflicting environment variable overriding your setting, an untrusted corporate CA, or NO_PROXY not covering internal hosts. Set http.proxySupport to "override", trust the CA in your OS store, and restart VS Code fully so extensions pick up the change.