Files

73 lines
2.5 KiB
Markdown

# 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.