Cursor Enterprise: Network Configuration

Cursor uses HTTP/2 bidirectional streaming by default for real-time chat and agent work. Some enterprise proxies don't handle HTTP/2 streaming correctly; Zscaler is the most widely used proxy with this limitation. When HTTP/2 streaming doesn't work, Cursor automatically falls back to HTTP/1.1 Server-Sent Events (SSE), a fallback built specifically for Zscaler and similar proxies that buffer or break HTTP/2 streams. The switch happens transparently.

The other common blocker is SSL inspection. Many corporate proxies perform SSL man-in-the-middle inspection for security or data loss prevention (DLP), replacing Cursor's certificates with the proxy's. When Cursor traffic passes through a Secure Web Gateway, SSL inspection or DLP, it often causes timeouts, slowness or errors in Agent work. Cursor's services are already encrypted end-to-end, so the documentation recommends excluding these domains from SSL inspection:

• .cursor.sh
• cursor-cdn.com
• marketplace.cursorapi.com
• authenticate.cursor.sh
• authenticator.cursor.sh

Cursor recommends allowlisting domain patterns rather than IP addresses, which can change. For most networks, allow traffic to *.cursor.sh, *.cursor-cdn.com and *.cursorapi.com. If your firewall mandates granular subdomain entries without wildcards, the documentation lists each subdomain and what it handles.

Cursor encrypts data both in transit and at rest, which is the assurance security reviewers usually ask for when you request an SSL-inspection exclusion.

It depends on where the agent runs. When you run Cursor agents in the editor or via the CLI on a machine inside your VPC, they inherit that machine's network configuration: security groups, firewall rules, DNS, and VPN or private network access. So those agents can reach internal resources the machine can reach while following your existing controls.

Cloud Agents are different because they run on Cursor's infrastructure, not your network. They can reach public GitHub, GitHub Enterprise Cloud repos you've granted access to, GitHub Enterprise Server, on-prem and cloud GitLab, Bitbucket Cloud and public package registries. They cannot reach resources behind your corporate firewall, on-premises GitHub Enterprise Server or private package registries without internet access. For Enterprise teams that need Cloud Agents, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. or Cursor backend services to reach private source control, Cursor supports private connectivity via AWS PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. and Cloudflare Tunnel.

Most connectivity issues come from proxies buffering streaming responses. The documentation includes curl tests that simulate the requests Cursor makes. To check whether SSL inspection is active, run curl -v https://api2.cursor.sh |& grep -C1 issuer: and look at the certificate: you should see Amazon RSA, and seeing your proxy provider (such as Zscaler) means SSL inspection is intercepting the connection.

1. 1Test basic connectivity to api2.cursor.sh.
2. 2Check whether SSL inspection is active and consider excluding the Cursor domains above.
3. 3Verify streaming works with the HTTP/1.1 SSE and HTTP/2 bidirectional curl tests from the docs.
4. 4Confirm firewall rules allow *.cursor.sh and related domains.
5. 5Review proxy logs for connection errors or timeouts.
6. 6Test from a machine outside your network to isolate network-specific issues.