TUN 与系统代理：三种接管方式怎么选

三种方式，先分清

• 系统代理：只影响那些读取系统代理设置的应用，主要是浏览器。优点是改动小、关掉就恢复；缺点是有的应用根本不读系统代理设置，那些流量就不会进来。
• TUN：在系统里建一个虚拟网卡，把 IP 层的流量接进来，能覆盖更多应用，包括不读系统代理设置的应用。代价是需要系统权限、要处理路由，配错了容易出现全断网或路由环路。
• VPN 模式（手机）：手机图形客户端里的 VPN 形态，本质上也是 TUN 的一种实现方式，只是入口是系统 VPN 权限弹窗，而不是桌面上的 TUN 入站配置。Android 上点允许 VPN 权限，iOS 上点允许 VPN 配置，都是这一步。

三者不是“越高级越好”，而是“覆盖面和风险一起变大”。浏览器打不开，先用系统代理排查；确认是某个不走系统代理的应用有问题，再考虑 TUN。

TUN 入站的关键字段

TUN 入站只在 Linux、Windows、macOS 上支持，官方结构里新手先看这几个字段：

• interface_name：虚拟网卡名，空着由系统自动选。
• address：给 TUN 接口的 IP 前缀，例如官方示例里的 172.18.0.1/30，不要和局域网已有网段冲突。
• mtu：最大传输单元，官方示例用 9000，实际按网络情况调，不要照抄示例就当通用值。
• auto_route：是否把默认路由指到 TUN；开了它，才谈得上“全部流量走 TUN”。
• strict_route：开了自动路由后是否严格执行路由规则；Windows 上它还能防止多网卡 DNS 解析带来的泄漏，但也可能让个别应用（例如虚拟机类软件）在某些情况下不正常。
• route_exclude_address：排除的地址，例如局域网段 192.168.0.0/16，这些流量不进 TUN，避免连不上局域网设备。
• dns_mode / dns_address：TUN 上的 DNS 怎么处理，1.14.0 起的字段；开了自动路由时默认是 hijack，否则默认是 disabled。

Linux 上还建议同时看 auto_redirect：用 nftables 改善 TUN 路由和性能，也能避免 TUN 与 Docker 网桥网络冲突；但它和 route.default_mark、出站的 routing_mark 冲突，不能同时用。

什么时候用 TUN，什么时候不用

• 用系统代理就够的场景：只用浏览器、目标明确、想快速开关、怕影响其他应用。
• 考虑 TUN 的场景：有不读系统代理设置的应用、需要覆盖整台设备、已经确认系统代理排查不出问题。
• 不要用 TUN 的场景：还没搞清配置本身对不对、DNS 和路由规则还没验证、局域网设备还没排除。TUN 会把所有问题放大：配置错了，原来只是浏览器打不开，开了 TUN 可能变成全断网。

Android 上还有一条官方提醒：默认情况下 VPN 优先于 TUN；想让 TUN 走 VPN，要开 route.override_android_vpn，并且配合 auto_redirect 使用，不要只开一个就以为通了。

冲突与排查

• 不要同时开两个：不要同时开两个 VPN 应用、不要同时开系统代理和 TUN 又互相指来指去、不要在开了 TUN 的同时还开着另一个代理程序。冲突时先关掉其他代理程序，只留一个，再验证。
• 路由环路：开了自动路由后，出站连接本身也要能出去，不能让出站流量又绕回 TUN。官方做法是设 route.auto_detect_interface 或 route.default_interface，或在出站上绑接口，三者按文档选一种，不要全设。
• 全断网先关 TUN：开了 TUN 后全断网，先把 TUN 关掉、确认直连恢复，再回头查地址段冲突、排除地址、DNS 模式这三处；不要在断网状态下继续加规则。
• 图形客户端的 TUN 入口不一样：桌面图形客户端的 TUN 开关、手机上的 VPN 权限弹窗、命令行配置里的 tun 入站，是同一件事的不同入口，不要以为“图形客户端开了 TUN”就等于“命令行配置里也有 TUN”，改配置时要确认改的是当前在用的那一份。