[Mitigated] HTTP/2 Connection Failures with SSLV3_ALERT_HANDSHAKE_FAILURE, primary affecting users in Ukraine

Support Bug Reports
22

This is the same issue I’m having. I assume something happened specifically for Ukraine because a couple of my friends are facing the same issue. Please help, http1 is really slow and has a bad experience compared to http2

2 Likes
23

I am also working from Ukraine and local internet issue was my first suspect but .49 update fixed the issue. I suppose Cursor can help from their end.

24

Hey, thanks for the report. Looks like the same issue as here: SSLV3_ALERT_HANDSHAKE_FAILURE when creating new chat. Most users fix it temporarily by disabling HTTP/2:

  • Settings → search for HTTP/2 → enable Disable HTTP/2 or in Network set HTTP Compatibility Mode to HTTP/1.1, then restart Cursor

We’re investigating it as a regression in 2.1.50. I’ll update you once there’s a fix.

3 Likes
25

(duplicate my message for better visibility):

My observation

26

I’m also from Ukraine and have the same issue.

Working with HTTP/1.1 seems to be slower and produces worse quality of code.

2 Likes
27

Thanks for getting back! HTTP1.1 does not work, it breaks in the middle so Cursor literally out of order. I just wanted to make it clear.

1 Like
28

Same issue here, i build my own VMs and i thought this has something to do with firewall or it’s a dns problem, AI chat features is not working when connected via ssh, and it was working a few hours ago, is there someone else in north Africa have same issue?

30

No mate, it is not about geography. I also enjoyed working SSH all day until it stopped working again at night. Cursor can fix it. Based in Ukraine.

33

Have you found any solution to this issue? Yesterday everything was working like clockwork for me, but today, after updating Cursor to the current version (2.2.20), I started having HTTP/2 problems. Switching to HTTP/1.1 isn’t working either.

34

No, it is going back and forth. 1.1 backup works nearly always though.

35

Check my last post. I found a solution.

1 Like
36

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.

37

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I cannot create new chats in Cursor. Each attempt fails with the following error:

Request ID: 0f9061c2-c37a-41fe-8b20-c42b6d1f3d7f
ConnectError: [internal] 1185413480192:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:486:SSL alert number 40

I also noticed that the domain api.cursor.sh does not resolve for me.
dig, nslookup, ping, and curl all fail to resolve this host across multiple DNS providers (1.1.1.1, 8.8.8.8, 9.9.9.9).
Other Cursor domains (like api2.cursor.sh) resolve and respond normally.

Things I already tried:
• disabling VPN
• restarting my Mac
• clearing the Cursor cache
• fully reinstalling Cursor
• trying different networks
• logging out/in
• flushing DNS cache (dscacheutil, mDNSResponder)
• changing system DNS servers
• verifying that no entry exists in /etc/hosts
• testing with curl, dig, nslookup, ping — all show NOANSWER for api.cursor.sh

Steps to Reproduce

1.	Open Cursor
2.	Try to create a new chat
3.	The error appears immediately
4.	Network-level checks (ping, dig, nslookup) show that api.cursor.sh does not resolve from any DNS server

Expected Behavior

Cursor should resolve and connect to all required API endpoints, including api.cursor.sh, and allow creating new chats without SSL or DNS errors.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.39 (Universal)
VSCode Version: 1.105.1
Commit: 60d42bed27e5775c43ec0428d8c653c49e58e260
Date: 2025-11-27T02:30:49.286Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.1.0

Does this stop you from using Cursor

Yes - Cursor is unusable

9 Likes
38

Thank you for the detailed report. The DNS resolution failure for api.cursor.sh is unusual. Let’s check a few more things:

  1. Extensions check:
  • Run cursor --disable-extensions in Terminal
  • Try creating a chat in the new window
  • Similar network issues were caused by extensions
  1. Security software:
  • Are you running any firewall apps (Little Snitch, Lulu, etc.) or antivirus on your Mac?
  • Is this a work/managed device with MDM profiles? (Check System Settings → Profiles)
  • Try temporarily disabling firewall/security software
  1. Network diagnostics:
  • Go to Cursor Settings → Network → Run Diagnostics
  • Share a screenshot of the results
  1. ISP/location:
  • What’s your ISP and general location?
  • Some ISPs or regions may filter specific domains

If extensions/security software aren’t the issue, this looks like it may need engineering investigation since api.cursor.sh should resolve globally. Please share the info above and I’ll escalate if needed.

1 Like
39

Thanks for the suggestions!

Here are my results:

  1. Disabled extensions – didn’t help.

  2. No firewall / antivirus / security apps installed.

  3. Diagnostics – everything shows as OK (I’ll attach the screenshot below).

    image
    image772×1921 55.2 KB

  4. Location – I’m in Ukraine, but my teammates in Ukraine have no issues.

Additional note:

I opened Cursor in a fresh window, and the very first chat worked, but any subsequent new chats fail with the same error.

Let me know if I can run anything else to help debug this.

1 Like
40

Thanks for the detailed follow-up and diagnostics!

It’s unusual that api.cursor.sh doesn’t resolve for you while api2.cursor.sh works, combined with the “first chat works, subsequent fail” pattern, suggesting something specific to your environment or network path.

A few things to try:

  • HTTP/2 setting (sometimes helps with SSL/TLS issues):
    • Cursor Settings CMD+, → search “HTTP/2” → enable “Disable HTTP/2”
    • Restart Cursor and test

Check system proxy settings:

  • System Settings → Network → Advanced → Proxies
  • Share a screenshot if any proxies are configured

Test DNS resolution again and share the result:

dig api.cursor.sh
nslookup api.cursor.sh 1.1.1.1

Try with a VPN to a different country/location to rule out ISP-level filtering

Let me know what you find!

2 Likes
41

Disabled HTTP/2 - and this actually worked.

I’ve created several new chats in a row and everything works now.

That’s strange because I tried almost everything before, but this setting solved it.

Thanks for the help!

2 Likes
42

So I tested HTTP/2 manually via curl — it works fine:
curl --http2 -v https://api2.cursor.sh

HTTP/2 connects successfully, TLS is OK.

But inside Cursor the HTTP/2 handshake fails and causes SSL alert 40.

The workaround (Disable HTTP/2) fixes the issue inside the app, and now I can create multiple chats in a row without errors.

I assume the problem is inside the Electron/Node HTTP/2 stack or how Cursor negotiates ALPN, not on my system/network.

Should I just keep HTTP/2 disabled and check occasionally if it gets fixed in future releases? Or is there anything else I can try?

2 Likes
43

Thank you so much, Andrew and Dean, had similar issue, switching to http/1.1 from http/2 helped on my side

2 Likes
44

Same error, after update from 2 to 2.1
rollback to prev version does not take any affect
Change of internet provider does not take any affect
Enable/disable VPN does not take any affect

Using http/1.1 on regular basis is not ok, it is significantly slower.

4 Likes