mirror of https://github.com/garrytan/gstack.git
e695f7f586
When a transparent-proxy VPN (Shadowrocket, ClashX, Surge in "enhanced/TUN
mode") captures traffic at the routing layer via a utun interface, the
original opt-in patch (BROWSE_NO_PROXY=1 → --proxy-server=direct://)
becomes counter-productive: direct:// can't escape TUN, packets still get
MITM'd, and Chromium's own cert store rejects the VPN's MITM cert
resulting in SSL error code 1, net_error -100 on every HTTPS navigation.
The fix in HTTP-proxy-only mode (original scenario) and the fix in TUN
mode need opposite Chromium configs:
- HTTP-proxy-only: --proxy-server=direct:// bypasses the proxy.
- TUN mode: no flag — Chromium inherits system proxy, connects through
the VPN's HTTPS proxy explicitly, and accepts the MITM cert signed
by a keychain-trusted root.
Heuristic: look for a utun interface with an IP in 198.18.x.x (IANA
benchmark range, used by Shadowrocket/ClashX for TUN routing). When
found, skip direct:// and log an explanation so the user knows why.
Backward compatible:
- BROWSE_NO_PROXY unset (default): no change, no flag added.
- BROWSE_NO_PROXY=1 + no TUN: no change, direct:// applied as before.
- BROWSE_NO_PROXY=1 + TUN: NEW — auto-skip with informative log.
- BROWSE_NO_PROXY=force: always apply direct:// (escape hatch for
users who want the old strict opt-in behavior).
Verified on macOS with Shadowrocket TUN mode active (utun6 198.18.0.1):
before patch → SSL handshake failed / net_error -100 on all HTTPS.
After patch → example.com + authenticated fly.dev pages load correctly.
|
||
|---|---|---|
| .. | ||
| bin | ||
| scripts | ||
| src | ||
| test | ||
| PLAN-snapshot-dropdown-interactive.md | ||
| SKILL.md | ||
| SKILL.md.tmpl | ||