2.5 KiB
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:
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:
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:
chatgpt.com -> 104.18.32.47, 172.64.155.209
Diagnostic commands
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:
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:
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.