Cursor Connection Failed: Internet, VPN & MCP Fixes

Cursor Connection Failed: Check Your Internet Connection or VPN

If Cursor says "connection failed" and asks you to check your internet connection or VPN, the cause is usually one of six layers: general internet access, VPN or proxy interference, Cursor service availability, authentication or session state, DNS/TLS/network filtering, or an MCP server connection failure when the error appears while using MCP tools. Not every Cursor connection error is an MCP error; first identify whether Cursor itself, your network, or one MCP server is failing.

Direct answer: start by proving normal websites and Cursor services load, then temporarily switch VPN/proxy/network conditions, refresh your Cursor session, and only then inspect MCP configuration if the failure happens during MCP usage.

Users often see wording like "Connection failed. If the problem persists, please check your internet connection or VPN." Treat that as a network-layer hint first, not proof that your MCP server is broken.

60-second checklist

1. Check whether normal websites and the Cursor status page load.
2. Temporarily disable or switch VPN if your organization permits it.
3. Check proxy, TLS inspection, and corporate firewall settings.
4. Restart Cursor and sign in again to refresh the session.
5. Test another network, such as a mobile hotspot, when safe.
6. Inspect Cursor logs or Developer Tools for DNS, TLS, authentication, or MCP errors.
7. If only MCP fails, inspect the MCP server separately.

Cursor service, network, or MCP server?

If Chat, Agent, sign-in, and model requests all fail, debug Cursor service status, authentication, DNS, VPN, proxy, or firewall first. If Cursor works normally but one MCP server or tool fails, switch to MCP-specific troubleshooting: use the Cursor MCP server failed to connect guide, check whether the process failed with spawn npx ENOENT, or diagnose a later Cursor tool call failed error.

For non-Cursor clients or shared MCP infrastructure, the broader MCP failed to connect guide and MCP error codes reference can help classify protocol-level failures without treating every Cursor network error as an MCP problem.

What Cursor Actually Connects To

Cursor is not a single connection. At any given time it may be maintaining several independent network relationships:

This matters because a "Cursor connection error" reported in the UI does not tell you which connection failed. The diagnostic path is completely different depending on the answer.

Cursor Connection Diagnostic Table

Use this table before editing mcp.json. If the failure affects all Cursor traffic, MCP config changes are unlikely to help.

Is Cursor Down?

The first question to answer for any Cursor connection failure is whether the problem is on Cursor's side.

Primary source: status.cursor.com — this is the official Cursor status page. It reports current incident status, past incidents, and per-component degradation.

To distinguish a Cursor outage from a local problem:

1. Load status.cursor.com from a browser (not from within Cursor). If you see an active incident affecting API access, model requests, or authentication, the failure is on Cursor's side.
2. Check whether multiple independent Cursor features fail simultaneously — if Chat, login, and all model requests fail at the same time, that pattern points to a backend issue rather than a misconfiguration.
3. Test from a second device or network — if Cursor fails on your work laptop but works on your phone's hotspot through the same account, the problem is your network, not Cursor's backend.
4. Check incident history — the status page shows recent resolved incidents, which can explain why Cursor started failing after a specific time.

Why not use third-party outage sites like Downdetector? These aggregate user reports without access to Cursor's internal metrics, and they conflate local issues with real outages. Use them only as a secondary signal, never as your primary source. The official status page is always more accurate.

If the status page shows all systems operational and Cursor still fails for you, stop looking at Cursor's backend and focus on your local environment.

Common Causes of Cursor Connection Errors

How to Diagnose a Cursor Connection Error Step by Step

This workflow classifies the failure before attempting any fix. Applying a fix before classifying the failure is the most common mistake.

┌─────────────────────────────────────────────────┐
│ Cursor shows a connection error                 │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 1. Check status.cursor.com                      │
│    Active incident? ──YES──► Wait / monitor     │
└────────────────────┬────────────────────────────┘
                     │ NO
                     ▼
┌─────────────────────────────────────────────────┐
│ 2. Does basic internet work?                    │
│    No ──────────────────────► Fix local network │
└────────────────────┬────────────────────────────┘
                     │ YES
                     ▼
┌─────────────────────────────────────────────────┐
│ 3. What exactly fails?                          │
│    All of Cursor ──────────► Go to step 4       │
│    Only Chat/Agent ────────► Go to step 5       │
│    Only one MCP server ────► Go to step 7       │
│    Only remote SSH/WSL ────► Go to step 6       │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌────────────────────────────────────────────────────────────┐
│ 4. Auth/network/proxy check                                │
│    Sign out and back in → fixed? ──YES──► Auth was expired │
│    Works on hotspot? ──YES──────────────► Network/firewall │
│    VPN active? ──YES────────────────────► VPN interference │
│    Proxy configured? ───────────────────► Proxy config     │
└────────────────────┬───────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 5. Model request failure                        │
│    Using default Cursor models? ──────► Cursor  │
│    Using custom API key? ─────────────► Step 5a │
│    Step 5a: Validate API key + check  │
│    provider status page               │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 6. Remote development failure                   │
│    Confirm remote host / container is running   │
│    Check SSH config and credentials             │
│    Check port forwarding and firewall           │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 7. MCP server failure                           │
│    Local stdio? ──────────────► Step 8          │
│    Remote HTTP? ──────────────► Step 9          │
└─────────────────────────────────────────────────┘

Step 1 — Cursor Service Availability

What to check: Open status.cursor.com in a browser.
What confirms it: An active incident banner, a component showing degraded or partial outage.
Action: If confirmed, there is nothing to fix locally. Monitor the page for resolution updates.

Step 2 — Local Internet or DNS Connectivity

What to check: Load any non-Cursor website. Then specifically test DNS resolution for Cursor's domain.

# macOS / Linux
nslookup cursor.com
curl -I https://cursor.com

# Windows PowerShell
Resolve-DnsName cursor.com
Invoke-WebRequest -Uri https://cursor.com -Method Head

What confirms it: If nslookup or Resolve-DnsName returns no addresses, DNS is broken. If curl or Invoke-WebRequest returns a TLS error, there may be a certificate problem (see SSL inspection below).

Step 3 — Scope the Failure

This is the most important diagnostic step. Ask:

• Does Cursor's login/account page work?
• Does the Chat panel respond at all (even with an error)?
• Does a different model work?
• Does a different project work?
• Does a different MCP server work?

Answering these questions narrows the failure to one of the categories below.

Step 4 — Authentication or Session Failure

Open Cursor Settings > Account. If your session shows as expired or signed out, re-authenticate. If re-authentication fails, that itself is a connection failure pointing back to Cursor's backend or your network blocking cursor.com.

Step 5 — Proxy, VPN, Firewall, or Enterprise Network

If Cursor works on one network but not another, the block is environmental. See the platform-specific sections and corporate network section below.

Step 6 — Model Provider Failure

If Cursor Chat fails but your Cursor account session is valid:

• Check whether the failure affects all models or only specific ones
• If using Cursor's built-in models, check status.cursor.com
• If using a custom API key (OpenAI, Anthropic, etc.), validate the key is active and the provider's own status page shows no incident
• Check your usage limits with the provider — exhausted quotas look like connection failures

Step 7 and 8 — Local MCP Server Failure

See the dedicated MCP section below.

Step 9 — Remote MCP Server Failure

See the dedicated MCP section below.

Cursor Connection Error vs Cursor MCP Connection Error

These are not the same thing, and conflating them leads to wasted debugging time.

A Cursor connection error means Cursor itself cannot reach its backend, authenticate, or communicate with a model provider. Symptoms: Chat is unavailable, login fails, or all AI features are broken.

A Cursor MCP connection error means Cursor cannot communicate with a specific MCP server. Symptoms: one or more MCP tools show as unavailable in the tools panel, but Chat and Agent still work normally. If the server is reachable but one invocation fails, debug it as a Cursor tool call failed problem instead.

Quick Answer: If Cursor Chat works normally and only MCP tools are broken, the problem is the MCP server — not Cursor's networking, not your internet connection, and not your authentication. Do not go down the path of checking firewalls and proxies for an MCP-specific failure unless the MCP server is a remote service that your network might block.

The decision rule:

• Chat works, MCP fails → troubleshoot the MCP server
• Chat fails, MCP also fails → troubleshoot Cursor's connectivity first
• Chat works, only one specific MCP server fails → that MCP server has a configuration or runtime problem

Cursor Connection Error with MCP Servers

Understanding the MCP Initialization Sequence

When Cursor starts an MCP server, it goes through a specific sequence:

1. Cursor spawns the process (stdio) or makes an HTTP connection (HTTP/Streamable HTTP)
2. The MCP handshake occurs: Cursor sends initialize, the server responds with capabilities
3. Cursor requests the tool list via tools/list
4. Tools become available in the Cursor UI

A failure at any of these stages looks like a "connection error" in the UI, but each has a different cause.

Validating Your MCP Configuration

Cursor reads MCP server configuration from two locations:

• Global: ~/.cursor/mcp.json (applies to all projects)
• Project-level: .cursor/mcp.json in the workspace root

A minimal valid stdio configuration:

{
  "mcpServers": {
    "my-tool-server": {
      "command": "node",
      "args": ["/absolute/path/to/server.js"],
      "env": {
        "API_KEY": "your-key-here"
      }
    }
  }
}

A minimal valid HTTP configuration:

{
  "mcpServers": {
    "my-remote-server": {
      "url": "https://your-mcp-server.example.com/mcp",
      "headers": {
        "Authorization": "Bearer your-token-here"
      }
    }
  }
}

Critical validation points:

• command must be the executable name or absolute path — do not assume PATH is inherited
• args must be a JSON array, not a string
• env only adds or overrides variables; it does not replace the full environment
• cwd sets the working directory; if omitted, the working directory is not guaranteed
• For remote servers, url must be the full URL including the path prefix

Diagnosing stdio MCP Server Failures

The single most effective debugging step for stdio servers: run the command manually in a terminal.

# macOS / Linux — run exactly what mcp.json specifies
node /absolute/path/to/server.js

# Or with environment variables
API_KEY=your-key-here node /absolute/path/to/server.js

Observe:

• Does the process start at all? If not, the command or path is wrong.
• Does it exit immediately? Note the exit code. A non-zero exit indicates a crash — check stderr.
• Does it print anything on stdout that is not valid JSON-RPC? This is stdout contamination and will break the stdio transport. Any console.log, debug output, or startup banner on stdout will corrupt the MCP protocol stream.
• Does it hang waiting for input? If yes, it is ready to receive MCP messages — this is correct behavior for a stdio server.

Stdout contamination is the most common stdio MCP failure that developers miss. The MCP stdio transport uses stdout exclusively for JSON-RPC messages. Any other output on stdout — including console.log('Server started') — breaks initialization. Move all logging to stderr.

Diagnosing Remote MCP Server Failures

For HTTP and Streamable HTTP servers, verify the server is reachable and responding correctly before investigating Cursor configuration:

# Check basic reachability
curl -I https://your-mcp-server.example.com/mcp

# Send a test MCP initialize request
curl -X POST https://your-mcp-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-token" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl-test","version":"1.0"}}}'

If the server responds correctly to manual curl requests but Cursor cannot connect, the problem is in Cursor's configuration, authentication headers, or a network path that differs between your terminal and Cursor's process environment.

For remotely accessible MCP servers, MCPForge Verify can test MCP protocol compliance, tool discovery, and authentication independently of Cursor — which helps determine whether the problem is the server or Cursor's connection to it.

MCP Authentication Failures

Cursor supports passing authentication headers for HTTP MCP servers via the headers field in the configuration. OAuth-based MCP servers using the MCP Authorization specification require Cursor to complete an OAuth flow before tool access is available.

Common authentication failure symptoms:

• Tools show as unavailable or connection errors appear immediately after startup
• Cursor logs show 401 or 403 responses from the MCP server
• OAuth flow does not complete or is not triggered

For Bearer token authentication, verify the token is not expired and is correctly entered in the headers field. For OAuth, check that the server's .well-known/oauth-authorization-server metadata endpoint is accessible and correctly configured.

Distinguishing MCP Failure Types

Local MCP Server vs Remote MCP Server Connection Errors

How to Inspect Cursor Logs

Logs are your best diagnostic tool, but Cursor menu labels and log locations can vary by version and operating system. Use the UI first rather than relying on a hardcoded path.

Cursor UI and Developer Tools

Open the Command Palette (Cmd/Ctrl+Shift+P or Ctrl+Shift+P) and search for log-related commands such as "Show Logs" or "Open Logs Folder" if they are available in your installed Cursor version. You can also open Developer Tools from the Help menu and inspect the Console tab for network, authentication, extension, and MCP errors.

MCP Server Output

For MCP-specific failures, look for the MCP server name in Developer Tools and in any stderr output from the server process. A stdio server that crashes, prints non-JSON output on stdout, or returns an initialization error usually leaves a clearer message there than in the top-level Cursor UI.

Relevant Log Entries to Look For

• Failed to connect to MCP server - MCP transport failed before the handshake
• MCP server exited with code X - the process crashed; check stderr for the reason
• certificate or SSL - TLS problem, often from enterprise SSL inspection
• ECONNREFUSED - the remote server is not listening on the specified port
• ENOTFOUND - DNS resolution failed for the remote hostname
• 401 or 403 - authentication failure
• net::ERR_ - Chromium networking errors visible in Developer Tools

Windows-Specific Fixes

Windows Network Diagnostics

# Test basic connectivity to Cursor's domain
Test-NetConnection -ComputerName cursor.com -Port 443

# DNS resolution check
Resolve-DnsName cursor.com
Resolve-DnsName api.cursor.sh

# Trace the network path (useful for identifying proxy or firewall drops)
Test-NetConnection -ComputerName cursor.com -Port 443 -TraceRoute

# Check if a specific port is reachable for a remote MCP server
Test-NetConnection -ComputerName your-mcp-server.example.com -Port 443

Test-NetConnection returns a TcpTestSucceeded field. If it is False for port 443 to cursor.com, a firewall or proxy is blocking the connection.

Proxy Configuration

Cursor inherits the system proxy configuration on Windows. If your organization uses a proxy, ensure it is configured in Windows Settings > Network & Internet > Proxy. To check the current WinHTTP proxy (used by many system-level connections):

netsh winhttp show proxy

If a proxy is configured in WinHTTP but not in Windows Settings, or vice versa, Cursor may not route traffic through it correctly. You can also set proxy environment variables before launching Cursor:

$env:HTTPS_PROXY = "http://proxy.company.com:8080"
$env:HTTP_PROXY = "http://proxy.company.com:8080"
# Then launch Cursor from this session

PATH and Executable Resolution for Local MCP Servers

On Windows, Cursor's process does not inherit PATH from your shell profile the same way a terminal session does. This means:

• node or python may not be found if installed via nvm-windows or pyenv-win without system-level PATH entries
• Use absolute paths in your MCP configuration:

{
  "mcpServers": {
    "my-server": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": ["C:\\Users\\you\\my-mcp-server\\index.js"]
    }
  }
}

To find the absolute path of an executable:

(Get-Command node).Source
(Get-Command python).Source

WSL-Specific Issues

If running Cursor on Windows with MCP servers running inside WSL, the MCP server command must account for the WSL boundary:

{
  "mcpServers": {
    "wsl-server": {
      "command": "wsl",
      "args": ["--", "node", "/home/user/my-mcp-server/index.js"]
    }
  }
}

Environment variables set in WSL .bashrc or .profile are not available when the process is spawned this way. Pass them explicitly in the env field.

Certificate Problems on Windows

Enterprise networks that perform TLS/SSL inspection replace the certificate on outbound HTTPS connections with one signed by an internal CA. If this CA is not trusted by Cursor's bundled certificate store, you will see TLS errors in the logs. The fix is to add the enterprise CA certificate to the Windows system certificate store (done by IT, usually via Group Policy), which Cursor then inherits.

You should not disable TLS verification. Doing so removes your only protection against man-in-the-middle attacks.

macOS and Linux Fixes

macOS and Linux Network Diagnostics

# Test DNS resolution
nslookup cursor.com
dig cursor.com

# Test HTTPS connectivity
curl -v https://cursor.com 2>&1 | head -50

# Test connectivity to the MCP server endpoint
curl -v https://your-mcp-server.example.com/mcp 2>&1 | head -50

# Check which process is listening on a port (for local MCP servers)
lsof -i :3000  # replace with your server's port

# macOS: Check system proxy configuration
scutil --proxy

# Linux: Check environment proxy settings
env | grep -i proxy

Proxy Environment Variables

On Linux, many applications respect HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables. If Cursor is launched from a desktop launcher rather than a terminal, these may not be set in its environment.

# Check if proxy variables are set in Cursor's environment
# Launch Cursor from a terminal with these variables:
export HTTPS_PROXY=http://proxy.company.com:8080
export HTTP_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1
cursor &

On macOS, the system proxy is configured in System Settings > Network > [interface] > Proxies. Cursor generally inherits this, but verify via scutil --proxy.

Executable Permissions for MCP Servers

# Ensure the MCP server script is executable
chmod +x /path/to/your/mcp-server

# Check file permissions
ls -la /path/to/your/mcp-server

PATH and Runtime Version Issues

On macOS and Linux, tools like nvm, rbenv, and pyenv add shims to PATH by modifying shell profile files (.bashrc, .zshrc). These profiles are not sourced when Cursor spawns MCP server processes. Use absolute paths:

# Find the actual node binary path when using nvm
which node  # in a terminal where nvm is active
# or
nvm which current

# Use the absolute path in mcp.json
# Example: /Users/you/.nvm/versions/node/v20.11.0/bin/node

Alternatively, use npx with the full path or configure the env field to set PATH explicitly:

{
  "mcpServers": {
    "my-server": {
      "command": "/Users/you/.nvm/versions/node/v20.11.0/bin/node",
      "args": ["/Users/you/my-mcp-server/index.js"]
    }
  }
}

Certificate Issues on macOS and Linux

On macOS, the system keychain is generally trusted by Electron apps including Cursor. If your organization deploys a custom CA certificate via MDM, it should appear in Keychain Access under System Roots.

On Linux, you may need to manually add enterprise CA certificates:

# Ubuntu / Debian
sudo cp /path/to/enterprise-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# RHEL / CentOS / Fedora
sudo cp /path/to/enterprise-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Minimal Connection Test

This procedure helps isolate whether a connection failure is specific to one context or affects everything.

Test 1 — Account-wide test
Open Cursor in a new empty folder (not your project). Does Cursor Chat work? If yes, the failure is project-specific or configuration-specific, not account-wide.

Test 2 — Network-wide test
If available and safe, connect to a different network (personal hotspot, different Wi-Fi). Does Cursor Chat work? If yes, the failure is your network environment.

Test 3 — Model-specific test
If Chat fails, try switching to a different model in Cursor Settings. If a different model works, the failure is specific to one model or provider.

Test 4 — Project-specific test
If the failure only happens in one project, check whether the project has a .cursor/mcp.json that might be causing startup problems, or whether remote development (SSH/WSL) is involved.

Test 5 — MCP-server-specific test
If only one MCP tool is unavailable, disable all other MCP servers temporarily. Then test the failing server in isolation. Run its command manually in a terminal. If it runs correctly in a terminal but fails in Cursor, compare the environment variables and working directory.

Test 6 — Minimum configuration test
Temporarily rename your ~/.cursor/mcp.json to mcp.json.bak to disable all global MCP servers. Restart Cursor. Does Chat work now? If yes, one of your MCP server configurations is causing a startup problem that cascades.

Corporate Networks and Enterprise Firewalls

Corporate network restrictions are one of the most common causes of Cursor connection failures that are not Cursor's fault and cannot be fixed by changing Cursor configuration.

Domains Cursor requires access to:

• cursor.com and *.cursor.com — authentication, features, documentation
• api.cursor.sh — AI model requests
• The API endpoint of any model provider you use (e.g., api.openai.com, api.anthropic.com)
• Any remote MCP server your team operates

If your organization uses a web proxy, content filter, or firewall appliance, work with your IT or network security team to:

1. Allowlist the above domains on ports 80 and 443
2. Exclude Cursor traffic from SSL inspection (or deploy the enterprise CA to all endpoints)
3. Confirm whether an authenticated proxy requires credentials in the proxy configuration

Do not attempt to bypass corporate security controls. Instead, provide your IT team with the list of domains and ports Cursor requires.

Collecting Information for a Bug Report

If you have worked through this guide and cannot identify the cause, collect the following before contacting Cursor support or opening a GitHub issue:

1. Cursor version — Help > About or the title bar
2. Operating system and version
3. Reproduction steps — precise sequence of actions that triggers the error
4. Whether the failure is consistent or intermittent
5. Whether it affects all networks or one specific network
6. Cursor log entries from the time of the failure (see log paths above)
7. Developer Tools console errors — screenshot or paste the relevant lines
8. Your MCP configuration (redact secrets) if MCP is involved
9. Whether this started after a specific Cursor update — check the changelog

Report bugs at github.com/getcursor/cursor for confirmed reproducible bugs, or through the Cursor forum for general support questions.

Prevention and Best Practices

For MCP Server Operators

• Keep MCP server stderr and stdout strictly separated — never log to stdout in a stdio server
• Use absolute paths in all MCP configuration files to avoid PATH-dependent failures
• Pin MCP server dependencies to avoid silent breakage from upstream updates
• Document required environment variables explicitly so consumers can configure them correctly
• For remote MCP servers, expose a health check endpoint that Cursor administrators can monitor independently of MCP tool availability
• If you publish a remote MCP server, consider using MCPForge to validate MCP protocol compliance and catch initialization issues before your users encounter them in Cursor

For Cursor Users and Teams

• Store MCP configuration in project-level .cursor/mcp.json when the server is project-specific — this avoids a global misconfiguration affecting all projects
• Use secret management (environment variables, not hardcoded tokens) for API keys in MCP configs
• Test new MCP servers manually before adding them to Cursor — run the command and send a test request
• When upgrading Cursor, check the changelog for known issues before upgrading on a production workstation
• If on a corporate network, proactively get Cursor's required domains allowlisted before widespread team adoption
• Configure NO_PROXY or proxy exclusions for localhost when running local MCP servers behind a system proxy

For Teams Running MCP Servers in Production

Deploying MCP servers for team use introduces operational concerns beyond basic connectivity. For guidance on making MCP servers reliable and observable in production, see Running MCP in Production.

Recent Changes Worth Knowing About

Cursor has been actively evolving its MCP support. A few changes that affect troubleshooting:

• Streamable HTTP is now the preferred transport for remote MCP servers per the MCP specification (replacing SSE-based transports for new implementations). If you are troubleshooting a remote MCP server connection and documentation refers to SSE, check whether you are using a legacy transport that may have reduced support.
• Project-level MCP configuration (.cursor/mcp.json in the workspace root) was introduced relatively recently — team members on older Cursor versions may not have this feature and will only read global config.
• OAuth support for MCP follows the MCP Authorization specification. If a remote server requires OAuth and you are seeing auth failures, confirm Cursor has been updated to a version that supports the OAuth flow for MCP.

Always check the Cursor changelog for the version you are running.

Summary

Cursor connection errors are a family of distinct failures, not a single problem. The path to resolution depends on accurately classifying what failed:

• Cursor backend problems → check status.cursor.com and wait
• Authentication failures → re-authenticate in Settings > Account
• Network/firewall/proxy problems → test on another network, work with IT
• Model provider failures → validate API keys and check provider status
• MCP stdio failures → run the server command manually, fix stdout contamination, use absolute paths
• MCP HTTP failures → verify the URL, test with curl, check authentication headers
• Remote development failures → verify the remote host or container independently

The most important rule: scope the failure first, then fix it. Applying fixes before diagnosing wastes time and can mask the real cause. Use Cursor's logs, the Developer Tools console, and manual server tests to gather evidence before changing configuration.