VPN 与代理：各自覆盖什么、不覆盖什么

VPN 和正向代理都会改变网站看到的地址，多数比较也止步于此。真正决定你配置方式的是覆盖范围：正向代理是应用自己选择使用的中间人，不同于立在网站前面的反向代理；而 VPN 会搬走操作系统路由进隧道的所有流量。加密、DNS 处理与故障行为都由这一分工决定。按顺序做完这五项检查，第一个不通过的就会告诉你真正需要哪种工具。

这个中间人覆盖哪些应用？

浏览器里的代理扩展只对那个浏览器配置生效。邮件客户端、包管理器和第二个浏览器仍用自己的设置，有些应用完全无视系统代理变量。VPN 覆盖路由表送进隧道的一切，既可能是所有应用，也可能是分流隧道下的一部分，取决于路由与客户端策略。

要测试真正重要的应用，而不是从一次页面加载外推。curl https://ifconfig.me会遵循环境中的代理变量，桌面应用未必。在 Windows 上，netsh winhttp show proxy打印服务所用的 WinHTTP 代理，那是与浏览器不同的设置。

这一跳加密了吗，TLS 又在哪里结束？

代理协议是碰面地点，不是保证。SOCKS5 转发 TCP 却不加密，普通 HTTP 代理以明文携带请求行和头部。经代理的 HTTPS 使用CONNECT，所以 TLS 会话仍在目标处结束，而不是在代理处。MDN 关于代理服务器与隧道的指南从协议一侧描述了这一区别。

VPN 加密你的设备与其端点之间的那一段。越过端点之后，规则和其他任何网络一样，这正是单靠隧道无法保护以明文 HTTP 发送凭据的应用的原因。两种设计都不隐藏已登录的账户、Cookie 或浏览器指纹。

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

详细输出会显示 curl 是向 443 端口发出了CONNECT，还是带完整 URL 的普通GET。使用socks5h://时，主机名在 SOCKS5 请求内部交给代理，随后代理转发它无法读取的 TLS，因此它只看到名字和字节数。经由http://代理时，https:// 地址是一个CONNECT，所以那个代理同样看到目标的名字和流量体积，但看不到请求或响应体。

哪个解析器看到名字？

域名解析可以在请求离开之前本地完成，也可以在代理处远程完成。用 curl 时，socks5h://把主机名交给代理，而socks5://先在本地解析。浏览器代理设置也提供类似的 DNS 选项，PAC 文件可以让不同主机走不同路径。

有两种协议完全不需要配置错误就能绕过代理：WebRTC 通过 STUN 收集候选，QUIC 在 UDP 上运行 HTTP/3，而 TCP 代理带不了它。若 UDP 443 被封锁，浏览器会退回 TCP。所以要可靠地让 HTTP/3 留在代理论径内，应当在主机防火墙（或整网路由器）上封锁 UDP 443，而不是靠浏览器开关。

要从目标的角度检查解析器，而不是从你的笔记本。一个带着代理出口地址、却由本地解析名字的请求，仍然向本地解析器暴露了你访问哪些站点。

中间人失效时会发生什么？

显式代理是关闭式失败：停掉代理进程，浏览器或应用就会返回连接错误，而不是直连。PAC 与 WPAD 才是开放式失败的：脚本取不到时，客户端退回到 DIRECT，站点又看到你的真实地址。VPN 可能开放式也可能关闭式失败，取决于客户端以及 kill switch 或防火墙规则是否生效。

故意测试失效情形：停掉代理服务再重载；如果得到错误页而不是直接加载，就把 PAC 地址指向不可达主机以观察回退。若页面仍走你平时的路径加载，那么代理对自己的中断毫无保护，这是依赖它之前应当知道的特性。

顺序决定站点看到什么。出口流量走 VPN 的代理，会让站点看到 VPN 端点的地址；把代理放到隧道之外（VPN 连到远程主机上的代理），站点看到的则是那个代理的出口地址。无论哪种，两跳都可能记录不同的东西。

五项检查，按顺序

下面的清单把整个判断放在一处。覆盖范围排第一，因为它能排除大部分错配：必须被覆盖的应用若不遵守设置，清单后面任何一步都救不了它。

然后用促使你做出改动的那个应用确认结果。在配置好的浏览器里加载页面，用 curl 取同一页面，比较两者报告的地址。若不一致，说明仍有扩展、PAC 规则或应用级覆盖在起作用，调隧道是修不好的。

把配置记录下来：哪些应用走代理、DNS 是本地的还是远程的、UDP 是否被封、故障行为如何。正是这份小清单让下一次比较成为可能，因为“IP 变了”从来没有告诉你这五项检查中哪一项通过了。