# OpenAI/ChatGPT DNS Pollution Probe — 2026-05-08

Context: after BOSS updated PassWall2 AI/OpenAI分流规则, browser automation still could not proceed because the local macOS resolver was still returning polluted IPs for key ChatGPT/Auth domains.

## Observed failure pattern

System resolver results:

```text
chatgpt.com -> 199.59.150.40, 2a03:2880:f10c:83:face:b00c:0:25de
accounts.openai.com -> 128.121.146.109, 2001::80f2:f09b
auth.openai.com -> 104.18.41.241, 172.64.146.15, Cloudflare IPv6
openai.com -> 104.18.33.45, 172.64.154.211
```

`chatgpt.com` and `accounts.openai.com` above are polluted / wrong for the flow. Browser and curl failed before automation could start:

```text
curl https://chatgpt.com/ -> LibreSSL SSL_connect: SSL_ERROR_SYSCALL
curl https://accounts.openai.com/ -> LibreSSL SSL_connect: SSL_ERROR_SYSCALL
Chrome -> ERR_CONNECTION_CLOSED / net_error -100
```

Cloudflare DoH comparison showed `chatgpt.com` should resolve to Cloudflare-like IPs such as:

```text
chatgpt.com -> 104.18.32.47, 172.64.155.209
```

## Diagnostic commands

```bash
python3 - <<'PY'
import socket
for h in ['chatgpt.com','accounts.openai.com','auth.openai.com','openai.com']:
    try:
        print(h, sorted({x[4][0] for x in socket.getaddrinfo(h,443,proto=socket.IPPROTO_TCP)}))
    except Exception as e:
        print(h, 'ERR', e)
PY

curl -I -L --max-time 12 https://chatgpt.com/ 2>&1 | sed -n '1,45p'
curl -I -L --max-time 12 https://accounts.openai.com/ 2>&1 | sed -n '1,45p'
scutil --dns 2>/dev/null | sed -n '1,120p'
```

## Interpretation

If `openai.com` or `auth.openai.com` returns HTTP/2 403 Cloudflare challenge but `chatgpt.com` / `accounts.openai.com` still fail TLS or resolve to non-Cloudflare/polluted ranges, do **not** continue registration/OAuth automation. Fix PassWall2 DNS handling first.

For BOSS's PassWall2 setup, ensure these domains use proxy-side/remote DNS, not the local ISP resolver:

```text
chatgpt.com
accounts.openai.com
auth.openai.com
openai.com
```

macOS resolver in the failing run still had public/ISP DNS entries like `2400:3200::1`, `2402:4e00::`, `114.114.114.114`, and `8.8.8.8`; rules alone were insufficient because DNS was not cleanly hijacked/forwarded for these domains.

## Process hygiene

Old Chrome test processes can continue emitting noisy GCM/Crashpad errors. These are usually not the root cause:

```text
Failed to connect to MCS endpoint
ConnectionHandler failed
Crashpad settings.dat: No such file or directory
```

Kill stale test Chrome processes after a failed probe so they do not distract from the DNS/TLS issue.