HTTPS-only outbound traffic on some Bot computers
Use HTTPS endpoints and clone git over HTTPS for now, because database, mail, SSH, and FTP connections time out.
Update, Oct 9: Still open. At 7:12 PM ET on Oct 8, staff said the computer's network "only lets HTTPS traffic (port 443) out" and that the team is tracking it. New reports came in overnight from users whose computers were restored on Oct 8. In our test this morning, connecting by IP address instead of hostname got through on ports 22 and 587. Details below.
Update, Oct 8: Still no fix as of 7:30 PM ET. Staff merged a new report of blocked MQTT and SMTP ports into the main forum thread at 9:32 AM ET, and users kept reporting the problem into the evening.
- Status: Open. Staff confirmed it on Oct 2 and again at 7:12 PM ET on Oct 8. No fix or timeline has been posted as of 8:45 AM ET on Oct 9.
- First seen: Oct 1, in a forum report posted at 10:17 AM ET.
- Symptoms: Outbound connections from the Bot's computer time out on every port except HTTPS on 443. HTTPS sites and APIs still load. Hostnames may resolve to 198.18.0.1 instead of their real address.
- Workaround: Use HTTPS endpoints, and clone and push git repos over HTTPS instead of SSH.
Since Oct 1, some Grok Bot computers can only make outbound HTTPS connections on port 443. Connections for databases, mail (IMAP and SMTP), SSH, FTP, and plain HTTP time out.
Colin, a Cursor community support engineer, confirmed it on the forum on Oct 2. He said it "isn't a restriction on your plan or account, and it isn't intended," and that the team is tracking it.
We checked on a Grok Bot computer at 7:30 PM ET on Oct 8. HTTPS to github.com returned 200, while connections to github.com on port 22 and smtp.gmail.com on port 587 timed out, and a plain HTTP request failed.
Why it matters#
Bots that check a mailbox over IMAP, push code over SSH, or query your own database stop working until this is fixed.
How to use it#
Staff gave these workarounds.
- Use HTTPS endpoints where the service offers one.
- Clone and push git repos over HTTPS instead of SSH.
- Don't reset the computer. Staff said there's no need, and on Oct 8 added that Reset or Update "won't change the network behavior."
- For mail, use something that talks to your provider over HTTPS, "for example the Gmail connector, or your provider's web API," staff said.
What we tested#
On our own Bot's computer at 8:40 AM ET on Oct 9, smtp.gmail.com, github.com, and portquiz.net all resolved to 198.18.0.1. By hostname, ports 22, 80, 465, 587, and 8080 timed out, and 443 connected.
Then we looked up the real addresses over HTTPS with Google's DNS over HTTPS API and connected to those IPs directly. Port 587 on a Gmail server answered "220 smtp.gmail.com ESMTP" and completed STARTTLS with the certificate checked against smtp.gmail.com. Port 22 on a GitHub server returned an SSH banner. A user reported the same IP trick on Oct 9.
This isn't a staff workaround. It worked on one computer this morning, may not work on yours, and could stop if the block changes. Addresses change, so look them up fresh each time. A prompt you can give your Bot:
Look up the current IPv4 address for <host> with https://dns.google/resolve?name=<host>&type=A, then connect to that IP on port <port>. Keep TLS certificate checks on, using <host> as the server name.
Good to know#
- "Route traffic through this computer" won't help, because it only covers the browser.
- Staff haven't given a workaround on the computer itself. The IP trick above is ours and one user's, not theirs.
- Services that only listen on a non-HTTPS port, such as SSH on port 22, have no HTTPS fallback. One user said that's the case for their Render SSH access.
- One user in the thread said off-computer connectors kept working. For mail, the Gmail plugin connects to your mailbox without IMAP. That's from the help center, not a staff workaround.
