DNS resolution failing for agentn.global.api5.cursor.sh and agent.api5.cursor.sh β€” API/Chat/Agent all broken

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor IDE cannot connect to its AI backend. The network diagnostic shows DNS resolution
failing specifically for agentn.global.api5.cursor.sh and agent.api5.cursor.sh, causing
API, Chat, Agent, and Ping checks to all fail with ENOTFOUND. All other Cursor endpoints
(api2, api3, repo42, authentication, CDN) resolve and connect successfully.

Steps to Reproduce

  1. Open Cursor IDE
  2. Attempt to use Chat or Agent
  3. Observe connection failure
  4. Go to Help β†’ Run Network Diagnostic
  5. Note ENOTFOUND errors on API, Ping, Chat, Agent, and Agent Endpoint checks

Expected Behavior

All network diagnostic checks should pass and Chat/Agent should be functional.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.2.16
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Auto

For AI issues: add Request ID with privacy disabled

N/A β€” requests never complete due to DNS failure

Additional Information

The api5.cursor.sh subdomain appears to be unresolvable via local/ISP DNS, while all
other Cursor subdomains resolve normally. Switching to a public DNS resolver (1.1.1.1)
may work around the issue. This could be a propagation or routing problem affecting
certain regions β€” particularly East Africa.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report. Your diagnostics look great, and you’re already on the right track.

This looks like a known regional DNS issue pattern. The api5.cursor.sh domains use a deep CNAME chain geo to latency to NLB, and some ISP resolvers don’t fully resolve it, especially in East Africa. Server-side everything works, and our logs show your account is active, so this is DNS on the path from your provider.

What to try, in order:

  1. Switch your DNS resolver to 1.1.1.1 Cloudflare or Quad9 149.112.112.112. On macOS: System Settings β†’ Network β†’ your connection β†’ Details β†’ DNS β†’ add 1.1.1.1 and 1.0.0.1. Restart Cursor.
    • Important: don’t use Google DNS 8.8.8.8 for this case. It can resolve to a Cloudflare endpoint with an SSL mismatch and break in a different way.
  2. If you use Apple iCloud Private Relay, turn it off: System Settings β†’ Apple Account β†’ iCloud β†’ Private Relay. It often breaks CNAME chains.
  3. As an extra workaround, enable HTTP/1.1 in Cursor: open settings Cmd+,, find cursor.general.enableHttp11, set it to true. Restart.

Related threads with the same fix if you want to compare:

Let me know what helped. If nothing did, share the output of dig agent.api5.cursor.sh +trace from your ISP resolver and we’ll see where the chain breaks.

Hello thank you , this worked for me