系统托盘里代理已经开启，可另一个程序内打开的目标网站却依然看到真实地址——这是很常见的抱怨，原因往往是按浏览器的方式配置了代理，却没考虑到该程序读取网络设置的方式完全不同。下面梳理代理生效的三个层级、哪些程序会绕过系统隧道、如何发现流量泄漏，以及什么时候一个统一隧道不够用。
三个层级：浏览器、应用、系统
浏览器代理通过浏览器本身或扩展程序配置，只影响浏览器自己发出的流量——标签页、内置下载，有时还包括拥有独立网络权限的扩展。这个设置完全不会影响到其他程序。
应用内代理是程序自身提供的地址与端口填写项：反检测浏览器、下载工具、账号管理器都属于此类。它只对该程序生效，不需要系统隧道，但前提是开发者在程序里确实提供了这个设置项。
系统级隧道通过修改操作系统路由表实现，或以独立的 TUN 虚拟网卡形式运行：它会一次性拦截所有程序的出站连接，无论具体某个应用是否支持代理设置。问题在于，不同程序读取系统代理的方式并不统一——有的走一种网络库，有的走另一种，还有的两者都不读。
哪些应用会无视系统设置
后台自动更新服务几乎总是直接连接固定写死的更新服务器地址，同时绕过系统代理和隧道。部分游戏客户端、模拟器，以及基于自有网络栈而非标准系统库构建的程序也是如此——它们根本不读取环境变量或托盘设置。
命令行工具通常需要在配置文件或环境变量中显式指定代理，系统隧道仍能拦截它们，但针对单个应用的定向设置做不到这一点。反检测浏览器和多账号管理工具的设计思路不同：它们为每个配置文件都提供独立的代理字段，这是优势而非缺陷，具体配置步骤见反检测浏览器代理配置分步指南。
绕过隧道的流量泄漏及其识别
DNS 泄漏是最常见的一种：应用通过系统 DNS 服务器解析域名，绕开了隧道，即便后续数据本身经由代理传输，这次域名查询也暴露了真实的网络运营商。IPv6 泄漏发生在隧道只处理 IPv4 流量、而应用另有一条独立 IPv6 路由的情况下——连接会直接发出，协议版本差异的实际影响详见IPv4 与 IPv6 的实践差异。
另一类情况是程序内部的后台进程与遥测数据：界面本身使用了配置好的代理，但程序自身的服务连接却是直连的。发现这类问题唯一可靠的方法是查看网络监控工具或防火墙日志——只要出站连接列表中出现代理地址以外的地址，就说明部分流量绕开了代理。
如何核实流量确实经过代理
在浏览器里做检测说明不了其他应用的情况——如果可行，应在被测程序内部运行 IP 检测服务，或者查看该程序所访问的目标网站实际看到的地址。第二种方法是查看任务管理器或防火墙里的出站连接列表：任何没有连到代理地址和端口的连接，都是绕过。
最可靠的方式是使用带唯一会话的独立端口：如果目标服务看到的地址与该端口本应分配的地址不一致，泄漏会立刻暴露，无需额外的检测工具。通用的通道质量核查指标同样适用于此，详见如何核实代理质量。
什么时候需要为单个应用单独分配端口
当多个相互隔离的配置文件或程序同时运行、且每个都需要独立 IP 时，一个共用地址的系统隧道就无法满足需求——这与同时运行多个反检测配置文件时面临的问题是同一个道理。本地代理管理工具的解决方式是为每个应用绑定独立的本地端口，各自对应不同的上游地址，让所有程序并行运行且互不干扰。
对于按计划或按需轮换地址的自动化任务，同样的思路可以通过 API 实现：每个脚本拥有自己的端口和会话管理，而不依赖整个系统隧道。API 轮换的具体配置见如何通过 API 配置 IP 轮换。
常见问题
系统级隧道与浏览器代理有什么区别？
浏览器代理只影响浏览器自身的流量。系统级隧道在操作系统层面修改路由，默认会拦截所有程序的出站连接——但那些使用自有网络栈、绕开系统路由的程序除外。
如何判断某个应用没有使用已配置的代理？
查看网络监控工具或防火墙日志：如果出现了连往代理地址和端口以外地址的连接，说明该程序部分流量是直连的。也可以对比程序或目标网站显示的 IP 与预期的代理地址是否一致。
更换代理后需要重启应用吗？
多数情况下需要。许多程序只在启动时读取一次代理设置——来自系统参数、配置文件或环境变量——之后不会实时感知变化。在程序重启之前，它可能继续沿用旧的连接路径。
按应用或配置文件单独分配的专属地址与独立端口，见代理专区。同一页面可按任务需求选择通道类型：从覆盖所有程序的系统隧道，到只服务单个应用的定向端口。