Files
codex-oauth-plus-onboarding…/references/passwall2-socks5-gateway-reachability-2026-05-08.md
T

2.9 KiB

PassWall2 / SOCKS5 Gateway Reachability Probe — 2026-05-08

Session context: after BOSS updated PassWall2 split rules for OpenAI/ChatGPT/Codex OAuth testing, macOS still could not open chatgpt.com and Chrome showed ERR_CONNECTION_CLOSED.

Observed commands and results

Low-risk macOS network refresh was performed:

dscacheutil -flushcache
killall -HUP mDNSResponder 2>/dev/null || true

DNS stayed polluted after the cache flush:

chatgpt.com -> 202.160.128.16 / 2a03:2880:f10e:83:face:b00c:0:25de
accounts.openai.com -> 192.133.77.189 / 2a03:2880:f117:83:face:b00c:0:25de
auth.openai.com -> 104.18.41.241 / 172.64.146.15
openai.com -> 104.18.33.45 / 172.64.154.211

Testing the intended SOCKS5 gateway:

nc -vz -w 3 192.168.2.8 1085
curl --proxy socks5h://192.168.2.8:1085 -I -L --max-time 25 https://chatgpt.com/
curl --proxy socks5h://192.168.2.8:1085 --max-time 15 https://api.ipify.org
ping -c 3 -W 1000 192.168.2.8
arp -n 192.168.2.8
route -n get 192.168.2.8

Results:

nc: connectx to 192.168.2.8 port 1085 (tcp) failed: No route to host
curl: (7) Failed to connect to 192.168.2.8 port 1085: Couldn't connect to server
ping: sendto: No route to host / 100% packet loss
arp: 192.168.2.8 had a MAC entry on en0
route: interface en0, host route present

Browser screenshot after refresh still showed:

无法访问此网站
chatgpt.com 意外终止了连接。
ERR_CONNECTION_CLOSED

Reusable lesson

For Codex/OpenAI onboarding tests, distinguish three layers before touching extension automation:

  1. Local DNS pollutionchatgpt.com / accounts.openai.com resolving to suspicious non-Cloudflare/Facebook-like ranges means domain rules alone are not enough.
  2. Proxy gateway reachability — even socks5h://... cannot help if the Mac cannot reach the gateway/port. Test nc, curl --proxy socks5h://, ping, arp, and route.
  3. Browser page result — only after gateway and DNS/proxy are healthy should Chrome/extension/OAuth be tested.

Use socks5h:// rather than socks5:// in curl probes when the goal is to force DNS resolution through the SOCKS proxy. If socks5h fails to connect to the proxy itself, stop and report gateway/port reachability first.

Suggested probe block

PROXY='socks5h://192.168.2.8:1085'

printf '== DNS ==\n'
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

printf '\n== gateway/port ==\n'
route -n get 192.168.2.8 2>/dev/null || true
arp -n 192.168.2.8 || true
ping -c 3 -W 1000 192.168.2.8 || true
nc -vz -w 3 192.168.2.8 1085 || true

printf '\n== through socks5h ==\n'
curl --proxy "$PROXY" -I -L --max-time 25 https://chatgpt.com/ 2>&1 | sed -n '1,80p'
curl --proxy "$PROXY" --max-time 15 https://api.ipify.org 2>&1 || true