On Grok Bot’s cloud computer, HTTPS through the shared SAND CONNECT proxy (127.0.0.1:8791, fastly-prod-xai-1) fails when CONNECT uses my public hostname, but succeeds when CONNECT uses that host’s literal public IP

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Product / platform

  • Product: Grok Bot
  • Platform: macOS desktop + Grok Bot cloud computer
  • Proxy: SAND HTTP CONNECT on 127.0.0.1:8791 (SAND_HTTP_PROXY_NAME=fastly-prod-xai-1)
  • Date: 2026-10-01 ~21:40–21:54 Europe/Zurich
  • Account email / Grok Bot version / request ID: (fill from About + Copy request ID)

Summary

Via shared SAND egress, HTTPS to my own public origin fails when CONNECT uses the hostname, but succeeds when CONNECT uses the literal public VIP for that same host. CONNECT returns 200, then TLS unexpected EOF. Origin is healthy (TLS + HTTP 401 by IP). Not Local Egress / not split-horizon private IP.

Steps to Reproduce

  1. On Grok Bot cloud computer, confirm SAND proxy on loopback port 8791.
  2. Pick a public hostname with one A to a public VIP (no AAAA, no hosts-file override). Labels: HOSTNAME and VIP.
  3. With HTTPS_PROXY pointing at that loopback proxy, curl -vk --max-time 20 to https on HOSTNAME path /mcp
  4. See CONNECT HOSTNAME port 443 → 200, then TLS EOF (OpenSSL unexpected eof while reading). VIP edge counters flat.
  5. Same proxy: curl -vk to https on VIP path /mcp with Host header set to HOSTNAME → TLS OK + HTTP 401; counters move.
  6. Optional: curl --resolve HOSTNAME:443:VIP still CONNECTs the hostname → same EOF.
  7. Same proxy: HTTPS to well-known public sites succeeds.

Expected Behavior

Hostname CONNECT completes TLS for HOSTNAME and returns HTTP 401 without bearer, same as the VIP control. Hostname and IP CONNECT to the same public VIP behave the same. Packets hit the VIP after hostname CONNECT.

Actual behavior

Hostname CONNECT → 200 + TLS EOF; counters flat. VIP CONNECT → TLS OK + 401. --resolve does not help. Nonsense hostnames also get CONNECT 200 in my checks.

Operating System

MacOS

Version Information

grok bot 0.63.0

Additional Information

Impact

A custom MCP attach URL has to be a hostname; the connector fails_to_load even though the origin works over SAND-by-IP.

Additional ask

Please publish or privately share the current Grok Bot shared static egress source CIDRs (and update cadence), and clarify whether SAND CONNECT uses those ranges, Fastly edges, or both — so I can delimit firewall ACLs for this MCP/HTTPS host.

Notes

Real HOSTNAME / VIP / traces privately on request. Distinct from Local Egress private-IP rejection; this VIP is public and IP CONNECT works on shared SAND.

Does this stop you from using Cursor

No - Cursor works, but with this issue

8

Hey @captMick, thanks for the report and for the careful controls.

Two separate things are going on here.

The proxy on 127.0.0.1:8791 is the “Route traffic through this computer” relay (Settings → Computer → Network), not the computer’s shared egress. This setting can be on even if you don’t remember turning it on, so please check it. While the relay is attached, a CONNECT by hostname is answered with 200 right away, and the name is then resolved and dialed from your own desktop. If your desktop can’t resolve it, resolves it to a private or VPN fake-IP address, or can’t connect, the stream closes, which looks exactly like “200, then TLS EOF”. IP-literal CONNECTs stay on the computer’s normal path, which is why the VIP test works. Made-up hostnames getting a 200 is the giveaway.

To confirm:

  1. In Grok Bot on every computer you use, open Settings → Computer → Network and turn off “Route traffic through this computer”.
  2. Wait about a minute, then rerun your hostname curl through 127.0.0.1:8791.
  3. Also rerun it with a made-up hostname. You should now get a 502 instead of a 200.
  4. On your desktop, run dig HOSTNAME and check whether it returns the public VIP.

Custom MCP connectors are a different path: they connect from Cursor’s servers, not from your cloud computer, so the relay and 8791 don’t affect them. Every connection attempt we see to your connector is timing out before it reaches your server, which usually means a firewall is dropping our traffic. We don’t publish a fixed IP list for that path right now. The connector needs to accept inbound HTTPS from the public internet (with your bearer auth still in place).