问题背景

在 macOS 上配置了系统级 SOCKS5 代理后，夸克、Safari 等浏览器都可以正常访问外网，但 Chrome 始终无法连通。

这类问题非常容易被误判为“代理服务不可用”，但实际是 Chrome 网络栈与 IPv6 处理策略在特定环境下触发了不兼容。

现象复现与初步结论

  • 系统代理已开启，SOCKS5 地址与端口确认无误
  • 夸克等浏览器正常，说明代理服务本身可用
  • 仅 Chrome 失败，说明问题在 Chrome 侧而非网络基础设施

技术排障步骤

  1. 先做“横向对比”：同一台机器、同一代理、不同浏览器对比，快速排除代理服务端故障。
  2. 做“链路分层”：系统代理层可用，但应用层（Chrome）失败，判定为应用网络栈问题。
  3. 定位到 IPv6 兼容路径：Chrome 在特定 DNS/Happy Eyeballs 场景会优先走 IPv6 相关链路，导致 IPv4-only SOCKS 路径异常。
  4. 验证假设：给 Chrome 增加禁用 IPv6 启动参数后，代理立即恢复。

最终解决方案

使用命令行启动 Chrome 并强制禁用 IPv6：

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-ipv6

执行后，Chrome 即可正常通过 IPv4 SOCKS5 代理访问外网。

工程化建议

  • 将该启动参数写入专用启动脚本，避免每次手动输入
  • 保留一个“原生 Chrome”与一个“代理 Chrome”启动入口，便于切换
  • 如果后续代理节点支持 IPv6，可再评估恢复默认网络策略

总结

这个问题的关键不在“代理能不能用”，而在“Chrome 如何选择网络路径”。通过分层排障和最小变更验证（–disable-ipv6），可以快速收敛问题并稳定交付。