How to Fix the Cursor "Connection Failed" Error in 2026

Cursor's "connection failed" error is almost never a code problem but a network or authentication handshake failure, fixable in about 90% of cases by clearing the auth cache, checking corporate proxies, or forcing re-authentication. The most common cause is a stale or corrupted auth token, followed by VPN/proxy interception, a wrong system clock, or rare server outages. Users should clear the auth cache in storage.json, add cursor.sh domains to proxy bypass lists, and sync the system clock before considering a reinstall.

How to Fix the Cursor "Connection Failed" Error in 2026 Cursor /en/tags/cursor/ "connection failed" error is almost never a problem with your code — it is a network or proxy handshake problem between the editor and Cursor's backend. You fix it in about 90% of cases by clearing the auth cache, checking your corporate proxy, or forcing Cursor to re-authenticate. Restart the app after each step and test by opening the Chat panel Ctrl+L / Cmd+L . What exactly triggers the "connection failed" error in Cursor? The error is a failed TLS or authentication handshake, not a syntax problem. I spent a full Tuesday afternoon chasing my own code before realizing the editor itself was offline. Cursor 1.x and 2.x reach out to endpoints like api2.cursor.sh and chatapi.cursor.sh to verify your license and route AI requests. When any of the following is true, the handshake breaks: - Your auth token is stale or corrupted the most common cause - A corporate VPN or proxy is silently intercepting traffic - Your system clock is wrong by more than a few minutes — TLS certificates fail on skewed clocks - Cursor's servers are genuinely down, which happens maybe 0.5% of the time - An extension crashed the background process that holds the connection How do I clear Cursor's authentication cache? Clear the auth cache first because it fixes the majority of cases and takes under a minute. On Windows it lives in %APPDATA%\Cursor\User\globalStorage\storage.json , and on macOS it is at ~/Library/Application Support/Cursor/User/globalStorage/storage.json . Here is the exact flow I used after the 1.95 update broke my session: 1. Close Cursor completely check the system tray — the process lingers 2. Open the storage.json file and delete the cursorAuth and cursor.keychain objects 3. Save the file, relaunch Cursor, and log back in One catch: editing storage.json while Cursor runs is useless — it overwrites your edit on exit. I made that mistake once and lost five minutes to a file that looked fixed but wasn't. Is a VPN or proxy the culprit? Yes, corporate proxies and privacy VPNs cause a large share of these errors. When I joined a team that forced traffic through a Zscaler proxy, Cursor failed to connect every single morning until I added exceptions. Check your proxy settings in three places: - System proxy Windows Settings Network, or macOS System Settings Network - Cursor's own network config in Settings Proxy - Any VPN kill-switch that routes only some apps For VPN users, add these to your bypass or exclude list: cursor.sh api2.cursor.sh .cursor.sh If you are behind a company proxy, tell your admin Cursor uses WebSocket connections on port 443 and port 80 for the update channel. A blocking rule on either kills the connection while leaving your web browser looking fine. Why does a wrong system clock break Cursor? A wrong clock breaks TLS certificate validation, and Cursor treats it as a failed secure connection. TLS certificates are valid only between two timestamps; if your machine claims it is 2023, the handshake fails even though every other setting is correct. To check on Windows: right-click the clock Adjust date and time Sync now. On Linux: sudo timedatectl set-ntp true . Then confirm with date . I hit this after a BIOS battery died on an old laptop. Everything else worked — the browser, npm, even my GitHub CLI — because those tools were more forgiving of time skew. Cursor's strict TLS check caught it where others did not. Should I reinstall Cursor, or is that overkill? Reinstalling is overkill for a connection error and rarely helps, because it keeps your global settings unless you delete them manually. The real fix is often just the auth cache or proxy settings above. Reinstall only if both of these are true: - The chat panel shows the error but the editor works fine offline - You have already cleared auth, checked the clock, and confirmed servers are up If you do reinstall, back up your keybindings.json , settings.json , and your .cursor/rules folder first. Losing those hurt more than the connection error ever did. How can I check whether Cursor's servers are actually down? Verify server status before you touch anything else — it takes seconds and prevents wasted effort. Cursor posts real-time status at status.cursor.com, and the endpoint https://api2.cursor.sh/api/health returns a JSON payload when the service is healthy. From the terminal you can run: curl -s https://api2.cursor.sh/api/health A healthy response looks like a small JSON object with a status field. If the request times out or returns an error, the problem is on Cursor's side and there is nothing to fix locally. Downages during 2025 and 2026 were mostly short — under an hour — so waiting is often the correct move. Does Cursor 2.0 behave differently with this error? Cursor 2.0, released in late 2025, changed some connection internals, and the error message is slightly less descriptive. The core fixes still apply, but 2.0 added a server-side settings sync that can re-corrupt your token if you sign out improperly. If you are on 2.0 and still failing after the cache clear, do this in order: 1. Sign out through the account menu, not by deleting files 2. Fully quit and relaunch 3. Sign back in and let the sync complete before opening Chat On 2.0 the app sometimes needs 10–15 seconds after login to finish syncing extensions and settings. Opening Chat during that window shows a fake "connection failed." Give it a beat. What if the error only happens in the chat or Composer panel? A connection error isolated to Chat or Composer points to the WebSocket connection rather than authentication. This is different from a full login failure and usually clears by restarting the background process. Try these, in order: - Run Developer: Reload Window from the command palette Ctrl+Shift+P - Toggle the proxy off and back on inside Settings - Clear the cache folder at ~/Library/Caches/com.todesktop.230313mzl4w4j2/Cache on macOS, or the matching %TEMP% path on Windows The cache folder grows to hundreds of megabytes and a corrupted entry there produces exactly this symptom. Deleting it is safe — Cursor rebuilds it on next launch. Are there log files that tell me the real reason? Yes, and this is the step most guides skip. Cursor writes connection logs you can inspect to stop guessing. On macOS the main log is at: ~/Library/Logs/Cursor/main.log On Windows it is at: %APPDATA%\Cursor\logs\main.log Grep for lines containing connection , websocket , or ETIMEDOUT : grep -iE "connection|websocket|etimedout" ~/Library/Logs/Cursor/main.log If you see ECONNRESET , suspect a proxy or firewall dropping WebSocket frames. If you see certificate errors, go check your clock again. The log tells you which of the five causes above actually bit you — no more guessing. Frequently Asked Questions Can I keep using Cursor offline during a connection failure? Yes. Cursor lets you keep writing and editing local files while disconnected. Only the AI features, model switching, and cloud sync pause until the connection returns. Unsaved work is not lost. Does this error affect my Cursor subscription or token usage? No. A connection failure does not consume tokens or cancel your plan. It is a transport problem, not a billing one. Your usage resumes normally once the connection returns. How long does a typical Cursor server outage last? Most outages in 2025 and 2026 lasted under an hour, with the biggest incidents around feature launches stretching to a few hours. Check status.cursor.com for real-time confirmation before assuming the problem is on your side. Will changing my DNS provider fix this error? Usually not. DNS problems cause a different "host not resolved" symptom. If you reach other Cursor endpoints but not the API, try switching to a public DNS like 1.1.1.1 or 8.8.8.8 once, but expect the real fix to be the proxy or auth cache steps above. The fastest path to a working connection Do these in order and stop as soon as it works: clear the auth cache, check the system clock, confirm servers are up with the curl command, then look at your proxy. That sequence resolves the overwhelming majority of cases without a reinstall. For deeper help, communities like PromptCube /en/ keep threads on Cursor troubleshooting and tool setup that go beyond the basic checklist. Next Stablecoins Are Already Winning the Cross-Border Payment Race — → /en/threads/5146/ All Replies （0） No replies yet — be the first