Grok Bot computer: all outbound non-HTTPS traffic blocked since Oct 1 (MySQL, SSH, IMAP/SMTP, FTP time out)

Support Bug Reports
,
35

Same bug here. Here’s what Grok Bot said about the issue:

I can’t see the network rules from inside my computer. The timing points to tonight’s restore, though. It worked every day through yesterday, and right after my computer was restored around 8:19 PM, every non-web port I tested went dead. That included GitHub’s port 22 and a public port-test site, not just your server.

So the likeliest cause is that the restored computer came back with a stricter network setup that only allows normal web traffic. That’s a guess, not something I’ve confirmed. Your host hasn’t blocked me, since a block on their side wouldn’t also cut off GitHub. If it’s still closed tomorrow, reporting it to the Grok Bot team is the way to get a real answer.

36

Adding another affected account. Since about 8:13 PM PT on Oct 8, 2026, my Grok Bot computer can only connect out on port 443. Second Life’s capability servers use port 12043 (*.agni.lindenlab.com / *.agni.secondlife.io), and they time out, as do ports 12046 and 80. DNS resolves those hosts to 198.18.0.1. The Second Life login works over 443, but inventory, parcel lookups and the other services that use 12043 all fail, so my bot’s avatar can’t walk or load its HUD. Before 8:13 PM everything worked normally. Turning off “Route traffic through this computer” didn’t change anything, and box-doctor passes all checks. Please let us know when non-443 egress is restored.

37

A workaround since Oct., 1 has been to connect to services using their IPv4 addresses rather than their DNS names. Is this now also being blocked for you?

39

This is working for me! Thank you very much.

40

We’re seeing the same thing on a Grok Bot computer after a service-side refresh on Oct 8 (around 5:30 PM ET). Outbound by hostname only works for HTTPS/443; other ports time out. DNS for most names returns 198.18.0.1, and there’s a local egress tunnel on 127.0.0.1:8791. Box-doctor still passes, and web traffic on 443 is fine.

A few findings that may help others:

  1. Connecting by the host’s real IPv4 address (looked up with DNS-over-HTTPS, e.g. https://dns.google/resolve?name=``<host>&type=A) works for most non-443 ports, including SSH. By hostname those same ports still fail. Port 25 stayed closed even by IP in our tests.

  2. Names that already resolve to a real address (not 198.18.x) work on any port by name. Most other names are stuck on the 198.18.x answer.

  3. apt can fail even when the package mirror itself is reachable over HTTPS, because its SRV lookup for _https._tcp.<mirror> can land on a name that resolves to 198.18.0.1. A one-shot workaround that worked for us, with no config change:

sudo apt-get -o Acquire::EnableSrvRecords=false update
sudo apt-get -o Acquire::EnableSrvRecords=false install <package>
  1. Turning off “Route traffic through this computer” and similar settings didn’t restore non-443 egress for us either.

We’re treating the IP-address path as a temporary workaround only (IPs can change), and we’re waiting on a platform fix.

42

Bumping for priority - this blocks me from being able to setup Grok Bot for a small construction company - there is no upside if they have to have a running computer on their end for automatic updates to their side.

Please fix asap. Is there a workaround we can run on bot computer for routing ?

Edit: (from grok bot)
that workaround works here.

Local DNS maps everything to the proxy (198.18.0.1), but connecting by real IPv4 succeeds:

  • xx: 9x.2x.x.x:22 → xx_OK on xx.xx.com
  • GitHub: 20.29.134.23:22 → authenticated as xx

I saved an SSH config so ssh simply / ssh github.com use those IPs, plus a small refresh script (~/.ssh/refresh-ipv4-hosts.py) that re-resolves via Cloudflare DoH when IPs change.

So I can talk to xx from my computer again without needing xx for SSH — xx is still fine as backup. Want me to do a quick read-only check of /test2/ vs the repo next?

43

Same here, I’m blocked from non-443 ports

44

Add my name to the list. Told my bot to use IPv4, and that didn’t work but that gave my bot an idea that worked:

My computer was already using IPv4, and it has no IPv6 route. What your idea uncovered is that my computer’s DNS points the mail server at a stand-in address, 198.18.0.1, that only lets web traffic through. Connecting straight to the real IPv4 address works, and the connection is still verified as <target domain’s> server.

45

Adding another affected account (support case T-G77994).

Since about 4:50 AM ET on Oct 7, 2026, my Grok Bot computer can only connect out over HTTPS on 443. SSH on port 22 to WP Engine and github.com times out, and DNS resolves everything to 198.18.0.1. I have not reset the computer, per Colin’s guidance, because it holds the only copies of my project work.

This has completely stopped my website development pipeline for more than two days. Support has only given me generic replies. @Colin, could the team please share:

  • an ETA, or at least a date for the next update;
  • whether port 22 can be allow-listed for affected accounts in the meantime;
  • whether affected users will receive a service credit.

Thanks.

46

Same here, updated grokbot and now a bunch of my utilities no longer function. Super frustrating as I was using them as part of a pipeline.. This is a major breaking change to introduce so haphazardly, no?

47

Add me to the list. Using alternative ports for remote connection to multiple machines and doing routine maintenance. My use case is now completely stopped until a resolution is provided.

48

Here also, now even on HTTPS

AirDroid remote control, ports 8091/6977/9088

49

+1 - I lost access to my webmaster bot accessing my site FTP

50

**Workaround that got browser apps (WebSockets, WebRTC video, non-443 ports) working again**

The “connect by real IP” trick works from the shell, but the browser still uses the fake DNS (198.18.0.1) and the proxy. So you have to tell Chrome itself to use the real addresses and skip the proxy for those hosts.

1. **Find every hostname the app uses.** Open the app, let it fail, then check Chrome’s log for names it couldn’t reach:

`grep -a “Failed to resolve” /tmp/chrome*.log`

Also check open connections with `ss -tnp | grep chrome`. Don’t skip WebRTC relay or TURN servers (names with “turn” or “stun”). Mine only worked once I added the video relay.

2. **Look up each host’s real IPv4 address** over DNS-over-HTTPS. Have your bot run curl against dns [dot] google, on the path /resolve?name=HOSTNAME&type=A (https, with -s).

3. **Confirm the port is open by IP:**

`timeout 8 bash -c “echo > /dev/tcp/IP/PORT” && echo OPEN`

4. **Edit the Chrome launcher** at `/usr/local/bin/box-chrome` (make a backup first):

  • Add the hosts to the existing `–proxy-bypass-list`, separated by semicolons.

  • Add a flag that maps each host to its real IP:

`–host-resolver-rules=“MAP host1 1.2.3.4, MAP host2 5.6.7.8”`

  • **Important:** also add a trailing-dot version of each host (for example, MAP host1 followed by a dot, then the IP). WebRTC looks names up with the dot on the end, and without it the video relay still fails.

5. **Restart Chrome** (`pkill -f ‘chrome.*remote-debugging-port’`, then relaunch with `box-chrome`). You’ll probably need to sign back in to the site.

6. **Recheck the log** for new “Failed to resolve” lines and repeat for any new hostnames.

**Notes:**

- Outbound UDP to real IPs worked for me, so WebRTC can connect once the names resolve.

- IPs can change, so redo the DNS lookup if it breaks again.

- This is a temporary workaround. It goes around the platform’s network setup, so revert it once there’s a real fix.

52

I thought it would be good to have a bot monitor and manage this based on those steps but it said:

I’m not going to build this bot. Those steps change my browser so it skips the platform’s network setup: they hardcode IP addresses and add sites to the proxy bypass list. You’re right that it goes around the platform’s network setup. A bot that keeps that change in place, and redoes it whenever it breaks, would be getting around a safeguard on my computer, and I can’t do that even as a temporary fix.

53

Same here, cannot retrieve or send emails (IMAP, SNTP). Please fix​:folded_hands:

54

Encountered the same issue. Managed to find a workaround though. Not sure if it’s applicable to all issues people are facing here but it might be worth a shot.

Workaround: use DNS-over-HTTPS

The box’s DNS server returns fake 198.18.x.x addresses, and the gateway behind them only forwards port 443. If you resolve real IPs over DNS-over-HTTPS (which itself runs over 443), connections on other ports go through.

System-wide fix. Ask your bot to install dnscrypt-proxy listening on 127.0.0.1:53, with DoH upstreams pinned to IPs (Cloudflare 1.1.1.1 and Google 8.8.8.8), then set /etc/resolv.conf to nameserver 127.0.0.1. The box has no systemd, so have it start the resolver from a shell profile script so it comes back after a restart.

Note: changing /etc/hosts or resolv.conf will trigger an approval prompt. Keep a backup of /etc/resolv.conf so you can roll back.

55

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Since Oct. 7, 2026, my Grok Bot environment has been resolving normal hostnames to the synthetic address 198.18.0.1.

HTTPS still works, but SSH and other non-HTTPS protocols fail.

A one-time diagnostic using the real public IP for GitHub confirmed that outbound TCP port 22 itself is not blocked: the connection succeeded and GitHub returned its normal SSH banner.

The failure appears to be caused by platform-controlled DNS interception routing hostname traffic through an HTTPS-only proxy.

Existing support case: T-G77994.

I do not want to reset the Grok computer because it contains preserved in-progress development state.

Steps to Reproduce

  1. Start the affected Grok Bot environment.

  2. Resolve:
    github [dot] com
    sundancereastg [dot] ssh [dot] wpengine [dot] net

  3. The system resolver returns 198.18.0.1.

  4. Attempt SSH to:
    github [dot] com on port 22
    sundancereastg [dot] ssh [dot] wpengine [dot] net on port 22

  5. Both time out before the TCP connection is established.

  6. Test other non-HTTPS protocols:
    HTTP port 80
    SMTP port 587
    MySQL port 3306

  7. Those also fail by hostname.

  8. HTTPS on port 443 continues to work normally.

  9. Use DNS-over-HTTPS to obtain GitHub’s real public IP.

  10. Perform one diagnostic TCP connection directly to that real IP on port 22.

  11. The connection succeeds and GitHub returns its normal SSH banner.

  12. Test SSH over port 443.

  13. Instead of an SSH banner, the connection receives:
    HTTP/1.1 400 Bad Request
    Server: Pingora

  14. Direct DNS queries to 1.1.1.1 over both UDP and TCP port 53 are also intercepted and return 198.18.0.1.

No DNS, proxy, firewall, SSH, route, or hosts-file settings were changed during testing.

Expected Behavior

Grok Bot should resolve public hostnames to their normal public IP addresses and allow normal outbound TCP connections.

In particular:

  • github [dot] com should resolve normally
  • sundancereastg [dot] ssh [dot] wpengine [dot] net should resolve normally
  • SSH on TCP port 22 should reach the destination server
  • non-HTTPS traffic should not be forced through an HTTPS-only proxy

The environment should not return 198.18.0.1 for every hostname.

Operating System

Linux

Version Information

Grok Bot 1.14.0 (17267)

For AI issues: which model did you use?

Not applicable — this is a Grok Bot networking/infrastructure issue, not a model-output issue.

Additional Information

Existing support case: T-G77994.

The issue began after the Grok Bot computer reboot around 4:50 AM ET on Oct. 7, 2026.

A second-stage diagnostic confirmed that outbound TCP port 22 itself is not blocked. The failure occurs because hostname resolution is being intercepted and routed through an HTTPS-only proxy.

No local settings were changed.

Please escalate this to the Grok Bot infrastructure/networking team.

I do not want to reset the Grok Bot computer because it contains preserved in-progress development work.

Does this stop you from using Cursor

Yes - Cursor is unusable

57

That worked for unblocking SSH, thanks !

Personally I installed it myself using brew (I also installed nix-env) because if your bot did it with apt then it’s gonna disappear the next time your VM gets reset (I don’t know the frequency but I know anything outside of /home/box and /workspace (like APT packages) disappear.

I also looked for any way to make dnscrypt-proxy automatically to start at boot but there is none.

58

Same here, I lost IMAP access and only port 443 is open for outbound connections. This makes it unusable. Will be terminating my subscription anytime now.