HTTP/2 disabled but still extremely slow, unresponsive, and reconnects mid‑response

Describe the Bug

After disabling HTTP/2, responses are still extremely slow, often cut off halfway, and the agent keeps reconnecting mid-response without completing replies.

Steps to Reproduce

  1. Install Cursor version 3.1.17 on Windows 11
  2. Go to Settings → search “HTTP/2” → enable “Disable HTTP/2”
  3. Fully restart Cursor
  4. Open the Agent (Composer) and send any prompt, for example: “Write a function to sort an array”
  5. Observe the behavior:
    • The response takes 1-2 minutes to start
    • It often disconnects halfway through with “Connection Error: The connection failed 10 times”
    • The agent then enters a “Reconnecting…” loop and never completes the response
    • Even simple prompts like “hello” are extremely slow or timeout

Note: This issue occurs consistently on networks in high-latency regions (e.g., China), even with HTTP/2 disabled, DNS changed to 1.1.1.1, and Cloudflare WARP enabled.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.1.17 (user setup)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report.

Based on the symptoms, this isn’t a client bug. It’s regional network latency. api2.cursor.sh currently goes straight to AWS without a CDN edge, so the round trip from China is very large, and long-lived streams like SSE often get cut off at the network level. “Connection failed 10 times” means the client hits its retry limit after disconnects. Disabling HTTP/2 won’t help here, because HTTP/1.1 SSE uses the same high-latency route.

This is a known issue and we’re already tracking it internally. Unfortunately there isn’t a reliable client-side workaround right now. The fix needs infrastructure changes, like putting a CDN or edge in front of the API endpoint. I can’t share an ETA yet.

Related thread for context: Slow Cursor responses and prolonged 'Reconnecting' status

I’ll follow up once we have an update on the infrastructure side.