Cursor proxy settings

This guide covers two different jobs. The first is Cursor's own network settings: what to set when Cursor has to reach its servers through a company proxy. The second is the proxy for the code and the browser that Cursor's agent writes and drives, which is where netdash fits. Cursor's settings change between releases, so the version numbers below come from Cursor's docs and staff answers on the Cursor forum, with the dates in the sources.

Quick answer: Cursor behind a proxy

Open your user settings with Preferences: Open User Settings (JSON) from the command palette and add the proxy your network requires:

{
  "http.proxy": "http://proxy.example.com:8080",
  "http.proxySupport": "override",
  "cursor.general.disableHttp2": true
}

• http.proxy is the proxy address. override makes Cursor use that address instead of looking for a system proxy.
• cursor.general.disableHttp2 sends Agent and Chat requests over HTTP/1.1, the path that goes through http.proxy. In the settings UI it's Cursor Settings > Network > HTTP Compatibility Mode > HTTP/1.1. Cursor's support staff say Agent, Chat and Tab keep working on HTTP/1.1, with slightly higher latency.
• Fully quit Cursor and start it again. Reload Window isn't enough.

Then open Cursor Settings > Network and click Run Diagnostics to check each connection.

Why Cursor ignores your proxy

Since version 3.9, Cursor sends its AI requests (API, Chat, Agent, Ping) through a separate HTTP/2 transport, according to Cursor staff on the forum. Node's HTTP/2 client can't go through a proxy agent, so those requests connect directly. Sign-in, the extension marketplace and downloads still use the editor's main network stack, which honors the proxy. That is why sign-in works while Agent fails with ConnectError: [unavailable].

Cursor 3.11.13 started honoring http.proxy and the HTTP_PROXY and HTTPS_PROXY variables for this traffic, but a proxy that the system picks up automatically, such as one from a PAC file or WPAD, is still ignored. If your company configures the proxy automatically, ask IT for the proxy host it points to and set it in http.proxy. A bug report filed on the forum on 2 October 2026 against Cursor 3.22.12 shows Agent requests still going direct while HTTP/2 is on and using the proxy once cursor.general.disableHttp2 is set, so keep that setting until Cursor's release notes say otherwise.

Cursor's network docs also describe an automatic fallback to HTTP/1.1 when a proxy breaks HTTP/2 streams. That fallback covers proxies that buffer streams, not a network that blocks direct connections, so set HTTP/1.1 yourself when Agent can't connect at all.

Settings UI and settings.json

Cursor is built on VS Code, so the http.* settings are the ones VS Code documents; cursor.general.disableHttp2 is Cursor's own. User settings apply to every project. Put the proxy there rather than in a project's .vscode/settings.json, which ends up in the repository.

HTTP_PROXY and HTTPS_PROXY

Cursor staff also suggest launching Cursor with HTTP_PROXY and HTTPS_PROXY set to the same address as an alternative to http.proxy. Cursor reads these variables from the environment it starts in. Started from a terminal where they're exported, it sees them; started from the Dock, the Start menu or a desktop shortcut, it may not. If the variables stop reaching Cursor after an update or when you launch it differently, set http.proxy with "http.proxySupport": "override" instead, which staff call the most reliable option.

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

Terminals inside Cursor and the commands its agent runs inherit the environment Cursor started with, so pip, npm and git use the same proxy. That is fine for a company proxy and the reason netdash shouldn't go here: see give your code a netdash proxy.

Behind a company proxy

What IT needs to allow, from Cursor's network docs:

• Domains: *.cursor.sh, *.cursor-cdn.com and *.cursorapi.com over HTTPS, plus *.cursorvm.com and *.*.cursorvm.com if your team uses Cursor's hosted computers. Cursor recommends allowing these patterns rather than IP addresses, which change. Sign-in uses a few more hosts, which Cursor lists in its sign-in domain docs.
• TLS inspection: Cursor recommends excluding its domains from SSL inspection and DLP. Inspection is one of the most common reasons Agent times out or stalls behind a company proxy.
• Streaming: if inspection stays on, the proxy must pass HTTP/2 bidirectional streaming or Server-Sent Events without buffering, and must not cut long-running connections.

To see whether a proxy rewrites Cursor's certificate, check the issuer. Cursor's docs say you should see Amazon RSA; your proxy vendor's name means SSL inspection is active.

curl -sv https://api2.cursor.sh -o /dev/null 2>&1 | grep -i -A1 "issuer:"

If the proxy re-signs traffic with a company certificate, install that root certificate in your operating system's trust store; VS Code's docs describe this as the preferred fix, since the editor uses the system's certificates. Cursor staff mention "http.proxyStrictSSL": false for a proxy with a self-signed certificate, but it turns off certificate checks for proxied requests, so use it to confirm the cause and then ask IT for the certificate or an inspection exception.

VS Code's docs list Basic, Digest, NTLM and Negotiate (Kerberos) as the proxy authentication methods of the editor's network stack, with a sign-in prompt. Cursor's docs don't say which of these its AI requests support. If Agent fails only on a proxy that uses NTLM or Kerberos, ask IT to exempt Cursor's domains from authentication.

Cloud agents and their egress

Cloud agents run on Cursor's infrastructure, not on your machine, so your http.proxy and your network don't apply to them. Agents in the editor and the CLI run on your machine and inherit its network, firewall and proxy settings, and so do agents on self-hosted machines.

• Egress IPs: cloud agents connect from IP ranges Cursor publishes at https://cursor.com/docs/ips.json. If an API or site you operate only accepts known addresses, you can allow-list these ranges. Cursor changes them from time to time and doesn't recommend IP allow-lists as the main security control, so monitor the file if you rely on it.
• Network access modes: in the Cloud Agents dashboard you, a saved environment or a team admin can choose Allow all network access, Default + allowlist or Allowlist only. With an allowlist, add every host the agent's code has to reach, including your netdash gateway, for example scale-us.netdash.io.
• Environment variables: store proxy credentials as a Runtime Secret, for example NETDASH_USERNAME and NETDASH_PASSWORD. Runtime Secrets load as environment variables but are redacted from tool output, the chat transcript and commits. Secrets of type Environment Variable are visible to the agent.

Setting HTTP_PROXY or HTTPS_PROXY in a cloud agent's environment sends every tool in it that reads those variables through that proxy, package installs and git included. For a netdash proxy, read the credentials in the code that needs an exit country, as below.

Give your code a netdash proxy, not the editor

Cursor's own traffic, the model requests and the editor's updates, shouldn't go through netdash. It would count against your balance and add latency, and the model requests don't need an exit country. The traffic that needs a netdash exit IP is what your code sends to websites and the browser your agent drives.

For an HTTP client, pass the proxy to the client itself: Python, Node.js and the Go guide show it per library. For a task that spans several requests, a sticky session keeps one exit IP: add -session-{SID}-ttl-{MIN} to the username, with a new session ID per task.

For the browser, Cursor reads MCP servers from .cursor/mcp.json in the project or ~/.cursor/mcp.json for all projects and fills in ${env:NAME} from the environment. The Playwright MCP entry and its config file with the netdash credentials are in Cursor and other coding assistants on the Claude Code guide. If your admin restricts the network of local MCP servers to an allowlist, the netdash gateway host has to be on it.

Check that it works

1. Cursor's connection: open Cursor Settings > Network and click Run Diagnostics. Each check (API, Chat, Agent and the others) should report success.
2. netdash from your code: run this in Cursor's terminal. It prints the exit IP netdash assigned, in the country from the username.

curl --max-time 30 -x "http://USERNAME-cc-US:PASSWORD@scale-us.netdash.io:2000" \
  "https://api.ipify.org?format=json"

Replace USERNAME and PASSWORD with the proxy username and password from the dashboard, not your sign-in password. If the first check fails and the second works, the problem is between Cursor and its servers, not netdash.

Errors and fixes

FAQ

Next steps

• Claude Code and Playwright MCP

  Credentials in .env, a proxy per client and an authenticated Playwright MCP browser, including the Cursor mcp.json entry.

• Proxies for AI agents

  Where a proxy fits in an agent, which traffic stays direct, and sessions per run.

• Troubleshooting

  407 errors, timeouts, requests that skip the proxy and the wrong exit country.

Stuck? See troubleshooting or email support with your username (without the password) and the error message.