浏览器可以连接为什么终端、Git 或 Docker 仍可能直连？

先把网络路径拆成四层

为什么浏览器正常，终端仍可能不同

很多浏览器会读取操作系统代理设置。命令行工具是否读取同一设置，则取决于工具、调用环境、参数与环境变量。如果终端请求没有进入 Verstro，切换智能路由或全局模式也不会自动把它纳入入口。

边界：“网页能打开”只证明当时那次浏览器请求成功。它不能单独证明同一终端命令、Git、Docker 或其他应用采用相同路径。

Git 要检查自己的配置和协议

Git 的 HTTP 访问可以使用自己的 http.proxy 配置，也可能读取常见代理环境变量；配置还可按远端 URL 细分。检查时至少区分：

• 当前 shell 是否设置了代理环境变量；
• Git 的 system、global、local 与按远端配置是否存在代理；
• 目标操作使用 HTTPS、SSH 还是其他传输方式；
• 实际 Git 进程和目标主机是否出现在同一时间窗的逐连接记录中。

不要只运行 curl 后就宣布 Git 已验证。需要验证时，应对公开目标使用 Git 自身的只读命令，并把结论限制到该协议、远端与时间点。配置细节可参考 Git 官方 http.proxy 文档。

Docker 不是一个单一网络路径

Docker Desktop 自身、Docker Engine 拉取镜像、构建过程、新容器内应用和已经运行的容器并非同一配置层。保存一个代理设置，不能证明这些路径全部按预期生效。

• 先说明观察的是 Desktop、Engine、build 还是容器内请求；
• 新建容器与已经运行的容器不要混在同一个结论中；
• 不要把宿主机浏览器或 curl 的结果外推给容器；
• 代理值可能包含敏感信息，只记录配置来源与是否存在。

当前配置边界可参考 Docker Desktop 代理设置和 Docker CLI 与容器代理配置。

跨应用排查清单

1. 1
   记录基线

   记录系统、Verstro 版本、系统代理、TUN、出站模式、目标应用与协议。

2. 2
   检查应用显式代理

   只记录设置是否存在及来源，不复制代理地址、凭据、Token 或完整日志。

3. 3
   判断入口还是出站

   请求没有进入时先查应用与入口；已经进入但链路不符时再查出站规则。

4. 4
   用目标应用发起只读请求

   浏览器、终端、Git 与 Docker 都应使用各自真实路径；一次只改变一个设置。

5. 5
   匹配逐连接记录

   核对目标进程、主机、上传 / 下载字节与实际链路，不用累计流量替代。

6. 6
   限制结论并恢复基线

   只对本次应用、协议、配置和时间窗下结论，测试完成后恢复日常设置。

本次脱敏实测说明了什么

测试时版本：arm64 Mac · macOS 26.5.2 · Verstro 1.4.13+20000 · 2026-08-21（之后已升级，不以本页版本号下载）

在系统代理开启、TUN 关闭、全局模式下，Safari WebKit 与 Google Chrome Helper 到同一公开下载域名的 TCP/HTTPS 请求均出现在逐连接页，并显示传输字节和代理链路。

同一设置下，一条没有显式代理环境变量、持续 90 秒并传输约 23.4 MB 的 curl 请求，在正确筛选和请求进行中的观察窗口内没有匹配连接。另一次系统代理关闭、TUN 开启、全局模式的实验则捕获了该类 curl 请求。

这只支持“本机本次入口覆盖因应用而异”。逐连接记录缺失并不自动等于直连，还要排除筛选、观察窗口、缓存、已有连接、QUIC / UDP 和日志保留。本文没有直接执行 Git 或 Docker 网络请求，因此不对它们的实际结果作结论。

隐私边界：本文仅发布经批准的脱敏文字说明，不发布原始截图、完整公网 IP、内部节点标识、账号、订阅链接、代理凭据或交易信息。

五个常见误判