TUN 模式是什么：开启后无法访问网络怎么办

用过系统代理的用户大多遇到过这样的情况：浏览器走代理一切正常，某些桌面软件、命令行工具或游戏却完全不理会代理设置，流量依旧直连。TUN 模式正是为了解决这类问题而存在的。但它的接管方式也带来了新的复杂度——不少用户开启 TUN 之后，反而整台设备都无法上网了。这篇文章先讲清原理，再按顺序排查开启后断网的原因。

TUN 模式的工作原理

TUN 模式的核心动作，是在系统中创建一块虚拟网卡，并通过修改路由表，让操作系统把几乎全部网络流量都发往这块网卡。客户端从虚拟网卡读取原始 IP 数据包，解析之后按规则分流：该走代理的封装后发往节点，该直连的从物理网卡发出。因为接管发生在网络层，应用程序既不需要支持任何代理协议，也无法绕过它——只要流量进了系统协议栈，就会被路由到虚拟网卡。

从数据流向看，一个请求的完整路径是：应用发出数据包，系统路由表把它送入虚拟网卡，客户端读取后匹配分流规则，命中代理规则的经加密隧道发往节点，命中直连规则的从物理网卡原样发出。理解这条链路，后面的排查就有了地图——断网一定发生在其中某一环。

与系统代理的区别

系统代理本质上只是操作系统提供的一个”建议”：遵守与否由应用自行决定。浏览器一般会遵守，而很多原生程序、命令行工具会直接忽略。TUN 模式则在网络层强制接管，覆盖面完整，但代价也很明确：需要更高的系统权限（安装虚拟网卡驱动或以服务方式运行）、需要客户端自行处理 DNS 解析，并且与其他同样操作路由表的软件容易发生冲突。另一个实际差异在 DNS：系统代理模式下域名解析通常由浏览器或系统完成，而 TUN 模式下解析被客户端整体接管——这既是实现精确分流的前提，也是断网原因里 DNS 相关问题占比很高的根源。两种模式的适用场景与更完整的对比，可参考代理运行模式的区别。

开启 TUN 后断网的常见原因

服务模式或驱动未安装。 Clash Verge Rev、Mihomo Party 等客户端在 Windows 上需要先安装系统服务（或以管理员身份运行）才能创建虚拟网卡。服务未安装、安装失败或被安全软件清除时，TUN 开关可能显示已开启，虚拟网卡却根本没有建立，路由表处于半接管状态，表现为全网断开。客户端更新后服务与主程序版本不匹配，也会出现同样的现象，重装一次服务即可解决。

DNS 劫持配置不当，形成解析回环。 TUN 模式通常会劫持所有 DNS 请求，交由客户端内置的 DNS 模块处理。如果内置 DNS 的上游服务器又被规则指向代理，而代理连接本身还依赖域名解析，就形成了”解析需要代理、代理需要解析”的死循环，所有域名都无法解析。这是 TUN 断网中最隐蔽的一类，日志特征是大量 DNS 查询超时。相关基础概念可参考术语页对 DNS 的说明。

与其他 VPN 或虚拟网卡软件冲突。 游戏加速器、办公 VPN、虚拟机的网络组件都会创建自己的虚拟网卡并修改路由。两套软件同时操作路由表时，流量可能被来回转发或直接丢弃。

防火墙拦截虚拟网卡。 Windows 防火墙或第三方安全软件可能把新出现的虚拟网卡识别为”未知网络”，并对它应用最严格的策略：物理网卡的流量放行，TUN 网卡的流量全部拦截。

严格路由（strict route）设置。 sing-box 等内核提供 strict route 选项，开启后会更彻底地防止流量绕过 TUN，但在部分系统环境下会连带阻断局域网访问或某些本地回环流量，表现为断网或局域网设备全部失联。如果需要同时访问局域网内的打印机、NAS 等设备，开启这一选项前应先确认客户端提供了局域网绕过设置。

建议的排查顺序

1. 先回退，恢复网络。 关闭 TUN，切回系统代理模式，确认基本网络恢复。这一步同时验证了节点与订阅本身没有问题——如果系统代理模式下同样全部超时，应先处理 Clash 全部节点超时的问题，而不是纠结 TUN 配置。
2. 确认服务与驱动。 在客户端设置中重新安装或重启服务模式，然后在系统的网络连接列表里确认 TUN 虚拟网卡确实出现了。
3. 检查 DNS 配置。 确认 DNS 劫持后的上游服务器走直连，且填写的是可用地址；节点若以域名形式填写，确认解析这些域名的 DNS 请求不经过代理。一个稳妥的做法是为节点域名单独指定一台直连的公共 DNS 服务器，从源头上避免回环。
4. 排除软件冲突。 退出所有加速器、VPN 与虚拟网卡类软件，再单独开启 TUN 测试。
5. 检查防火墙。 在防火墙中放行客户端程序及虚拟网卡所在的网络，或临时关闭防火墙做一次对照测试。确认拦截来源之后，应针对性地添加放行规则，而不是长期停用防火墙。
6. 调整严格路由。 如果是开启 strict route 之后才断网，先关闭该选项验证。sing-box 中 TUN 相关配置项的位置与写法，可参考 sing-box 的入门指南。

每次只改一处并记录结果，是这类网络层问题定位的基本原则；同时改动多项设置，即使恢复了也无法确认原因。

无法解决时的回退策略

TUN 模式并不是必需品。如果日常需求只是浏览器与常规应用，系统代理已经足够；只有确实存在不走系统代理的应用时，才值得为 TUN 的额外复杂度买单。桌面端比较务实的做法是：日常使用系统代理，需要全局接管时临时开启 TUN，用完关闭。移动端的情况有所不同：iOS 与 Android 的客户端本身就以系统 VPN 隧道的方式工作，效果天然接近 TUN，通常不需要用户单独操心这一层；真正需要理解和排查 TUN 的，主要是 Windows、macOS 与 Linux 桌面环境。Clash Verge Rev 中两种模式的切换与服务安装步骤，可参考 Clash Verge Rev 的配置教程。如果反复排查后 TUN 在你的环境中始终不稳定，与其强行使用，不如回到系统代理模式，用分流规则覆盖大部分场景。