Grok Bot stays on “Can’t reach your computer” and keeps reconnecting. Cursor’s updater says the certificate is invalid and the server may be pretending to be api2[.]cursor[.]sh.
api2[.]cursor[.]sh CNAMEs to api2geo[.]cursor[.]sh, then api2direct[.]cursor[.]sh. Both 1.1.1.1 and 8.8.8.8 return 100.60.17.13 in that set. Connecting to 100.60.17.13 with that hostname presents a certificate for devapi[.]english[.]com (Pearson PLC / Sectigo), so TLS hostname verification fails.
From the same network, 34.235.15.195 in the same DNS set presents the correct certificate (CN=api2[.]cursor[.]sh, issuer Amazon RSA 2048 M01). Mobile hotspot works because it gets a different address list. No local proxy or antivirus HTTPS scanning. Changing DNS to 1.1.1.1 and 8.8.8.8 does not remove 100.60.17.13.
Steps to Reproduce
On this office network, resolve api2direct[.]cursor[.]sh with 1.1.1.1 or 8.8.8.8. 100.60.17.13 is in the answer.
Connect to 100.60.17.13 port 443 using the hostname api2[.]cursor[.]sh.
TLS fails: certificate subject is devapi[.]english[.]com, not api2[.]cursor[.]sh.
Open Grok Bot. It keeps reconnecting with “Can’t reach your computer”.
Same account on a phone hotspot connects normally.
Expected Behavior
Every address published for api2[.]cursor[.]sh should present a certificate for that hostname. Grok Bot should connect without a certificate warning.
Hey @dnz, this isn’t on our side and your computer is healthy, so don’t Reset or Recover. 100.60.17.13 is a real api2 address and serves the correct api2.cursor.sh certificate when we test from outside. The Pearson cert you get means your network is delivering that address to the wrong server, which is why only the 100.x addresses fail and the hotspot works.
To pin down where: run traceroute -n 100.60.17.13 and traceroute -n 34.235.15.195 from the office network. If they diverge, that’s your office or ISP redirecting the 100.x range. Ask your network team to check firewall, NAT, or routing rules covering 100.0.0.0/8 (often added by mistake near the 100.64.0.0/10 carrier-NAT range). The hotspot keeps you connected meanwhile.
Traceroute from the office network does not diverge in the first 8 hops. Both 100.60.17.13 and 34.235.15.195 go through 192.168.16.1, 192.168.100.3, 10.12.6.11, 10.12.6.30, 198.18.0.38, 10.12.0.188/189, 198.19.0.25, then 203.208.186.93.
It is not only 100.x. From this network, 100.60.17.13 presents devapi.english.com, 100.56.3.181 presents fiftyflowers.com, 34.203.148.79 presents an AWS internal metadata name, and 52.4.83.206 presents *.art.quidient-dev.com. 34.235.15.195 and 3.222.88.17 present api2.cursor.sh correctly. No local proxy on the Mac. Hotspot works.
The addresses your office network returns for api2.cursor.sh aren’t all ours. The failing ones (100.60.17.13, 100.56.3.181, 52.4.83.206) currently belong to unrelated services (I checked from a clean network, same result), which is why the certificate doesn’t match. The ones that work for you (34.235.15.195, 3.222.88.17) are our current addresses. So that network is resolving our domain to stale or wrong addresses, which we see more often on some regional networks, and it’s why your hotspot works. The fix is on that network’s DNS: whoever manages it should make sure *.cursor.sh resolves cleanly and isn’t cached to old addresses. Until then, the hotspot keeps Grok Bot connected.