Cursor desktop app cannot connect on SFR hotspot (France).
It works on my home Wi-Fi.
Issue is reproducible every time on SFR hotspot.
Switching HTTP/1.1 did not help.
Cloudflare WARP did not help.
Please advise required network endpoints and debug steps.
Steps to Reproduce
Connect Mac to SFR hotspot.
Open Cursor desktop app.
Cursor cannot connect.
Switch to home Wi-Fi.
Cursor works normally.
Expected Behavior
Cursor should connect on SFR hotspot the same way it connects on home Wi-Fi
Operating System
MacOS
Version Information
Cursor IDE desktop app on macOS.
Issue is reproducible on SFR hotspot (France) and does not occur on home Wi-Fi.
HTTP/1.1 mode did not fix it. Cloudflare WARP did not fix it.
Hey, this is almost certainly the SFR hotspot blocking or filtering the traffic Cursor needs to connect, like gRPC or HTTP/2 streaming. SFR hotspots are known for restrictive network policies like port blocking, deep packet inspection, and transparent proxies.
A few things to try:
Run Cursorâs network diagnostics: Cursor Settings > Network > Run Diagnostics. Share the results here. Itâll show exactly where the connection breaks.
Try these curl tests from the SFR hotspot to narrow it down:
# 1. Basic connectivity test to the Cursor API
curl -I -v https://api2.cursor.sh
# 2. HTTP/2 test (if this fails, it points to an HTTP/2 issue)
curl -I --http2 -v https://api2.cursor.sh
# 3. Force HTTP/1.1
curl -I --http1.1 -v https://api2.cursor.sh
# 4. Check the TLS certificate
openssl s_client -connect api2.cursor.sh:443 -servername api2.cursor.sh < /dev/null 2>&1 | grep -A2 "subject="
Use a real VPN, not just WARP. Cloudflare WARP in free mode may only proxy DNS and may not tunnel all your traffic. You need a full VPN, like Mullvad, ProtonVPN, or WARP+ in full tunnel mode, to bypass SFR filtering.
If the HTTP/1.1 toggle didnât help, it could be because some internal Cursor components still use HTTP/2 no matter that setting. Thatâs a known limitation weâre tracking.
Let me know the diagnostics results and whether a full VPN helps.
Iâm seeing a paradoxical connectivity issue on my MacBook Pro when using my SFR hotspot (and sometimes hospital Wi-Fi): Cursor appears unable to connect/sign in, but Network Diagnostics shows all checks as Success.
What I tested:
Cursor Run Diagnostics (while on SFR hotspot, during the issue):
VPN tests: with my VPN enabled, behavior is not better; in some cases Cursor is also blocked even on personal Wi-Fi.
So transport-level connectivity seems fine, but Cursor UI/session still fails to connect.
Could this be a client-side auth/session state issue or a known bug where diagnostics pass but app connection still fails?
I can provide the full diagnostics logs if needed.
Hey, this is an interesting update. If diagnostics and curl both pass, then the SFR hotspot isnât actually blocking traffic. That changes the picture.
A few things I need from you to narrow this down:
What exactly does the Cursor UI show when it âfails to connectâ? A screenshot of the error would really help.
Open Help > Developer Tools, reproduce the issue, and share what shows up in the Console tab. Thatâll tell us whatâs actually failing at the app level.
What Cursor version are you on? (Cursor > About Cursor > Copy)
You mentioned VPN also breaks things on personal WiâFi now. Does Cursor work reliably on home WiâFi without VPN? This matters because if itâs also failing at home now, it may be a session or auth issue rather than a network one.
Hi, thanks for your follow-up.
Here are the requested items point by point.
1) What Cursor UI shows when it fails to connect
When the issue happens, Cursor shows it cannot establish/maintain the remote connection (connection attempt then failure/close).
I attached a screenshot of the failure state and a screenshot of DevTools Console during reproduction.
Thanks for such a thorough follow-up. The screenshot and console logs are super helpful.
From the screenshot, I can see youâre using Remote-SSH to connect to an Ubuntu server at 51.75.124.82. Thatâs the key detail. The issue isnât Cursor failing to reach our API. Thatâs what the diagnostics test checks, and it passes. The issue is that the SSH tunnel to your remote server is dropping on those networks.
The console errors match this chain:
The SSH multiplex connection drops (âremote server not configuredâ, âread ECONNRESETâ, âFailed to ping remote serverâ)
The remote extension host loses contact (âExtension host became UNRESPONSIVEâ)
That explains the weird part. Diagnostics pass because they test Mac â Cursor API directly. But your workflow breaks because it goes through the SSH tunnel.
French mobile carriers (SFR, Bouygues, Orange) often use Carrier-Grade NAT on hotspots, and that can kill idle TCP connections in as little as 5 seconds. Thatâs almost certainly whatâs dropping your SSH tunnel.
A key test to narrow this down:
Can you keep a plain SSH session stable on the SFR hotspot? Open Terminal.app (not Cursor) and run:
ssh -v [email protected]
# once connected, leave it idle for 30+ seconds, then run a command
If that also drops, then itâs fully a network issue, not Cursor.
Either way, add this to your ~/.ssh/config:
Host 51.75.124.82
ServerAliveInterval 4
ServerAliveCountMax 22
TCPKeepAlive no
IPQoS none
ServerAliveInterval 4 sends keepalives every 4 seconds, since CG-NAT on French carriers can drop connections after ~5 seconds of inactivity
TCPKeepAlive no avoids false disconnects from packet loss, and relies on SSH keepalives instead
IPQoS none disables DSCP marking that some hotspots or CG-NAT setups drop or deprioritize
Also:
What SSH port are you using, 22 or custom? SFR is known to do DPI on some ports
Can you share your current SSH config for this host, including any ControlMaster, ControlPersist, ProxyJump settings?
Which VPN are you using? Some VPNs with split tunneling can break SSH routing even on a good network
Let me know what happens with the plain SSH test. That will tell us if this is just the network or something Cursor specific in the SSH layer.
Quick follow-up: we successfully fixed the issue. Your diagnosis was correct â this was not API reachability, but SSH transport instability on some mobile networks (SFR hotspot / CG-NAT behavior).
What we changed:
Kept Cursor Remote-SSH workflow, but hardened SSH transport settings.
Added aggressive SSH keepalives on the client side (ServerAliveInterval, ServerAliveCountMax, TCPKeepAlive no, IPQoS none).
We could not use SSH on port 443 because HTTPS/Nginx already occupies IPv4:443 on the server.
So we moved SSH to a dedicated alternate port (2222) and updated the SSH host config accordingly.
On the server, we updated systemd socket listening config to include 2222 (in addition to 22), then reloaded/restarted SSH/socket units.
Added security hardening:
key-based auth only (password auth disabled),
fail2ban enabled for SSH on port 2222,
UFW limit rule on 2222.
Validation results:
Stable in home Wi-Fi.
Stable in SFR hotspot (including idle/reconnect checks).
Cursor Remote-SSH now reconnects and stays usable in both contexts.
Thanks again â your guidance on the SSH tunnel/network layer was exactly what unlocked the resolution.
