浏览器 VPN 扩展还是桌面应用：到底哪个在运行

浏览器显示的是境外地址，邮件客户端却仍从家里直连，下载工具更是完全不理会 VPN。什么都没坏，只是三个不同的产品在做三件不同的事。图标上的产品名并不会告诉你手里是哪一个。

读懂图标无法告诉你的事

如果有配套客户端，先关掉它，再看扩展的表现。它是继续走代理、直接停止工作，还是提示你启动桌面客户端？如果隧道归配套客户端所有，两个指示灯报告的可能不是同一类状态：一个是浏览器设置，另一个是隧道。在下任何关于覆盖范围的结论前，两者都要看。

Chrome 和 Firefox 的扩展用的是浏览器代理 API。这些 API 配置的是浏览器，而不是操作系统。打开扩展的代理设置页，留意模式是固定、自动，还是由配套客户端控制。

因此邮件客户端、游戏或独立的下载器，除非自己有相应设置，否则不会走那个代理。从服务商网站下载的 OpenVPN 配置文件，仍然需要兼容的客户端。

代理不是加密隧道

代理只是一条中间路径，而到它这一段是否加密，取决于协议本身及其配置。单凭 SOCKS 这个标签什么也保证不了。正确验证的 HTTPS 会另行保护浏览器到网站之间的内容，而这种保护无论有没有 VPN 都重要。

桌面应用也可以排除特定程序或目标，所以设备级安装并不等于每个请求都会走它。把你需要的应用列出来逐个测试，不要凭安装包去推断覆盖范围。

DNS 走的是另一条路

查询可能经浏览器的安全 DNS、代理或操作系统解析器发出，这是三条不同的路径。某次浏览器请求里公网地址变了，并不等于做过 DNS 测试。去查询一个只应由 VPN 解析器回答的名字，再把答案与浏览器之外操作系统返回的结果对比。

如果内部域名在浏览器里失败、在终端里却能解析，说明扩展没有承载这次查询。如果两者都失败，问题在解析路径上，代理只是干扰项。

切断连接再观察

在获准的测试里切断连接，观察浏览器是停住、报错，还是退回直连路径。再把它与桌面客户端在隧道断开时的承诺对照，因为自动重连和隧道外阻断是两种不同的保证。

另外要独立于它对传输方式的宣称去审查扩展权限，并从发布方的已验证渠道安装。记录故障测试期间扩展报告的模式，因为这个值才解释了回退行为。

然后再选覆盖任务的那种方案。设备级访问需要具备路由策略的客户端；单个浏览器标签页也许只需要代理。守住一条能讲清楚的策略，好过堆叠一堆扩展并指望总和就是保护。