TUN 模式与系统代理分别代表“捕获数据包”和“由应用配合”两种入口。TUN 接收操作系统路由选中的 IP 包；系统代理只是一项偏好设置，程序可以遵守、覆盖或忽略。当某个流量从未进入选定机制时，应用就会表现为绕过 VPN。［1］［2］［3］

完整 VPN 指南介绍一般隧道模型。本文把入口单独拆开，避免把浏览器成功、应用直连和路由排除误认成同一种故障。

关键要点

TUN 处理被路由的 IP 包，系统代理依赖支持代理的应用。

直接套接字、自带网络库、应用独立配置和不受支持的流量都可能绕过系统代理。

TUN 覆盖较广却不是绝对：路由、IPv4/IPv6、应用排除、DNS 与命名空间仍会限定范围。

公网 IP 检查应跨应用、跨地址族重复。

应定位失败层，而不是一次更换协议、服务器、DNS 与代理类型。

TUN 模式与系统代理如何进入路径？

TUN 是三层虚拟接口。操作系统根据当前路由策略，把选中的 IP 包交给它。Android 说明，VPN 程序会从接口读取外发包，经受保护的隧道套接字传送，再把解密后的入站包写回接口。［1］

系统代理则由软件读取。浏览器或网络框架可查询某个 URL 应使用的代理，进行认证并发送受支持请求。PAC 能返回代理链或 DIRECT，但不会在主机上强制拦截每一个套接字。［3］

问题	TUN 模式	系统代理
谁选择流量	路由与 VPN 策略	支持代理的应用或框架
入口单位	被选中的 IP 包	受支持请求或连接
直接套接字	通常仍服从路由	可以完全忽略代理
UDP	隧道实现支持时可承载	取决于代理与客户端
IPv6	需要相应路由与实现	取决于应用解析和代理路径
DNS	可单独路由或配置	可在本地、代理或应用内完成
排除	路由、应用、目的地或平台策略	PAC `DIRECT`、绕过清单或应用覆盖

应用为何绕过系统代理？

最常见原因是程序根本不读取系统设置。它可能直接创建 TCP/UDP 套接字，使用自带运行时，只读取环境变量或自身配置，也可能继续使用设置改变前已经建立的连接。浏览器页面成功不能证明另一个程序使用了同一入口。

应用也可以设置优先级更高的专用代理。企业软件可能接收受管配置，开发工具读取自己的配置文件，浏览器扩展只影响一个配置档。因此，扩展与桌面 VPN 显示不同地点可能正是两条独立路径的结果。

绕过清单也可能是有意设计。PAC 可为匹配 URL 返回 DIRECT，桌面代理通常还排除本地主机名或地址范围。PAC 缓存、配置档优先级和认证错误，会让显示相同代理地址的应用得到不同结果。［3］

哪些流量最容易暴露差异？

语音、游戏、设备发现与实时应用经常使用 UDP，基础 HTTP 代理不会自动承载它。部分 SOCKS 实现支持 UDP association，但客户端和服务器必须同时支持，DNS 也可能仍走另一条路。

非 HTTP 的 TCP 有时可通过 CONNECT，前提是应用主动请求，且代理允许相应目的地。只会使用原始套接字的程序，不会因为系统开关开启就自动支持代理。这是集成边界，并不表示加密本身失败。

TUN 模式为何仍可能遗漏流量？

TUN 捕获由路由决定。若配置只安装部分前缀，其他目的地仍走普通接口。Microsoft 文档说明，路由具体程度与 metric 会影响 VPN 路径，强制隧道和拆分隧道也会安装不同默认路由。［2］

地址族不完整很常见。IPv4 默认路由进入 TUN，并不会自动覆盖 IPv6。支持双栈的服务可能在不同应用或不同请求间选择不同路径，因此要同时核对两套路由表和实际连接地址。

平台还可能提供按应用纳入或排除、本地网络例外，以及供 VPN 自身使用的受保护套接字。容器、虚拟机和独立网络命名空间也可拥有自己的路由。TUN 应描述为“在声明上下文内进行路由级捕获”，不能写成无条件抓取整机所有包。

DNS 能绕过 TUN 吗？

能。解析器流量可能匹配排除路由，应用可能使用自带加密 DNS，平台也可能选择另一接口。反过来，DNS 查询进入隧道，也不代表连接到解析地址时一定走隧道。

应用受控域名进行检查，观察其解析结果，再核对目的连接与路由。一个解析器设置或缓存答案不足以证明完整路径。

如何诊断应用绕过？

先固定可重复的对照：一个看似受保护的应用和一个看似直连的应用，使用同一目的地、时间、网络与地址族。目的地不同就无法单独判断捕获机制。

检查系统代理的生效来源、应用覆盖项、PAC 结果、绕过清单、认证和是否需重启；检查 TUN 的接口状态、路由前缀、metric、应用排除、IPv4/IPv6，以及隧道套接字是否正确避免回环。

随后记录 TCP 或 UDP、目的 IP 与端口、DNS 路径、本地或远程范围，以及是否复用了旧连接。浏览器能连接而桌面应用不能连接只有在这些事实明确后，才适合归因。

每次只改变一个变量：固定地址族、只重启目标应用、移除一条已授权排除规则，或比较一条直连与一条代理请求。若同时更换协议、端点、DNS 和应用设置，就会失去定位依据。

怎样建立可靠测试矩阵？

可用浏览器、命令行客户端、受控后台服务和 UDP 工具作为行；以系统代理、TUN、断开状态、IPv4、IPv6、DNS 结果、出口地址和本地访问作为列。不受支持的组合应明确标记，不应当作故障。

测试前后记录路由、接口、代理来源、PAC 决策和脱敏日志。服务器日志能证明请求抵达；没有日志可能说明问题更早发生。

用策略语言定义通过条件，例如“除获准更新服务外，所有受管应用都使用隧道”。同时写明直连回退是否允许、本地服务是否保留，以及重连是否必须终止旧套接字。“VPN 正常”并不是可测试条件。

何时使用哪一种方式？

若需求涉及多应用、不支持代理的软件、UDP 或设备级网络策略，应优先考虑 TUN，并承担路由、DNS、接口生命周期、MTU 与失败安全管理。若范围明确限于兼容程序，其他软件允许直连，且需要按请求选择，则系统代理更合适。

两者也可以组合：TUN 捕获 IP 流，再把符合条件的连接转换到代理栈。诊断时仍要分层，TUN 决定“什么进入”，代理栈决定“怎样表示与传输”。

TUN 与系统代理模型能否描述 AethoVPN？

用 AethoVPN 做受控测试时，开启全局模式连接，然后分别检查三项：浏览器泄漏测试、DNS 泄漏测试显示的解析器，以及一个会忽略系统代理设置的命令行工具或应用。三项都从所选位置出口，说明你观察到了全系统覆盖，但 AethoVPN 的文档没有说明这是通过 TUN 接口、代理还是两者结合实现的，所以只记录结果，不要推定机制。开始 3 天免费试用，完成这三项检查。

总结

TUN 捕获被路由的 IP 包，系统代理依赖应用配合。
直接套接字、独立设置、UDP 限制与 DIRECT 规则常会造成代理绕过。
TUN 仍受路由、地址族、排除项、命名空间和 DNS 限制。
应在多个应用中比较同一目的地，并一次只改变一个变量。
测试前先写明覆盖与失败规则。

常见问题

TUN 能保证任何应用都无法绕过 VPN 吗？

不能。平台排除、路由缺口、其他命名空间、IPv6、本地路由或特权行为都可能形成不同路径。保证必须针对实际平台策略验证。

为什么浏览器走代理而游戏不走？

浏览器支持代理，游戏可能直接使用 TCP 或 UDP 套接字。应核对游戏支持的代理方式和实际流量类型。

系统代理就是拆分隧道吗？

不是。系统代理是一种入口机制，它可能造成部分应用代理、部分应用直连的拆分结果；拆分隧道还可按应用、路由、目的地或域名选择。

TUN 与代理能一起使用吗？

可以。客户端可用 TUN 捕获 IP 包，再转换到代理栈。捕获、代理协议、传输、路由与 DNS 仍是不同层。

为什么 IPv6 显示不同公网地址？

配置可能只捕获 IPv4，应用也可能用不同方式解析并连接 IPv6。应在同一个双栈目的地核对两套路由表。

改系统代理后要重启应用吗？

有时需要。应用可能缓存设置、PAC、DNS 或现有连接。重启是受控诊断动作，但不证明之后所有流量都会使用代理。

直连回退一定是泄漏吗？

只有违反书面策略时才是泄漏。排除应用或本地服务可能被允许直连；要求 fail closed 时必须明确禁止并测试回退。

免责声明：本文仅提供一般网络信息。请遵守所管理网络、设备与服务的规则。

来源：

Android Developers, “VpnService”: https://developer.android.com/reference/android/net/VpnService
Microsoft Learn, “VPN routing decisions”: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-routing
MDN Web Docs, “Proxy Auto-Configuration file”: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

Sources checked 2026 年 9 月 12 日。

延伸阅读：

TUN 模式与系统代理有何不同？直接连接、路由排除与应用范围