Windows 下 Clash Verge Rev TUN 模式断网排查
简答：Windows 开启 Clash Verge Rev TUN 后断网，先关闭 TUN 恢复网络，然后依次执行 ping 公网 IP、nslookup 域名、ipconfig 和 route print。没有虚拟网卡多看权限与 Service Mode；IP 能通但域名不通多看 DNS；多网卡或虚拟网卡环境则重点检查 auto-detect-interface、auto-route 与路由表。
定义：TUN 模式是客户端在系统中创建一块工作在网络层的虚拟网卡，并通过路由把流量导入代理内核处理。
先做 30 秒自检：把“完全断网”和“只有 DNS 失败”分开
本文只讲 Windows。Clash Verge Rev 的设置页面将 TUN 描述为虚拟网卡模式，启用后会捕获系统流量；TUN 通常需要 Service Mode 或管理员模式，具体按钮名称以当前版本界面为准。github.com
- 先关闭 TUN：打开 Clash Verge Rev 的设置或首页，找到
TUN Mode，关闭后确认普通网络恢复。若仍无法上网，退出客户端，并在 Windows“设置 > 网络和 Internet > 代理”中关闭不需要的“手动代理设置”。 - 测试公网 IP：打开 PowerShell 或 CMD，执行
ping 1.1.1.1。能收到回复不等于网页一定能打开，但可作为路由层的初步对照。 - 测试域名解析：执行
nslookup example.com。如果公网 IP 测试有结果、域名查询失败，优先检查 DNS 配置、dns-hijack和客户端的 DNS 覆写设置，不要先反复切换节点。 - 检查虚拟网卡：执行
ipconfig /all，观察是否出现由 TUN 创建的虚拟网络适配器及其地址。没有虚拟网卡或客户端提示权限、服务不可用，优先处理 Service Mode、管理员权限或驱动问题。 - 检查路由：执行
route print，记录开启和关闭 TUN 前默认路由及相关接口是否变化。若开启后默认流量进入异常接口，或者多块网卡之间反复切换，转到“出口网卡和路由”一节。
| 现象 | 优先判断 | 下一步 |
|---|---|---|
| 没有虚拟网卡，TUN 无法启用 | 权限、Service Mode 或驱动未生效 | 检查 Service Mode 或以管理员身份运行，并查看客户端日志 |
| 公网 IP 和域名都不通 | 路由、出口网卡、Stack 或防火墙 | 检查 route print、auto-detect-interface 和安全软件拦截 |
| 公网 IP 可通，域名不通 | DNS 配置或 DNS 请求未进入内核 | 检查 dns-hijack、strict-route 和 DNS 覆写 |
| TUN 关闭后网络立即恢复 | 故障集中在 TUN 接口、路由或 DNS 接管 | 保留关闭状态，逐项修改后重新测试 |
权限、Service Mode 与防火墙：先确认 TUN 是否真正创建
如果开启 TUN 后客户端没有建立虚拟网卡，或者日志出现类似“创建 TUN 接口失败”“服务不可用”的提示，不要把它当成节点故障。先按下面顺序检查：
- 确认权限路径：在 Clash Verge Rev 设置中寻找
Service Mode、Install Service、Switch to service mode或相近名称。公开界面文案显示，TUN 需要 Service Mode 或 Admin Mode；当前版本的中文翻译和入口可能不同。github.com - 重新授权：完全退出客户端，确认任务管理器中没有残留的 Clash Verge Rev 或 Mihomo 内核进程，再右键以管理员身份启动，重新启用 TUN。若使用服务模式，检查服务是否已安装且内核确实由该服务运行。
- 检查防火墙和安全软件：在 Windows 安全中心或第三方安全软件中查看是否拦截了客户端主程序、Mihomo 内核或 TUN 虚拟网卡。先记录原有规则，再只做临时放行测试；测试无效后恢复原规则。
- 回滚：如果管理员启动后仍无法创建网卡，关闭 TUN，卸载或重新安装服务模式前先备份客户端配置，不要直接删除配置目录。
Clash Verge Rev 的公开 Issue 中有 Windows 用户报告开启 TUN 后整机断网、关闭 TUN 后恢复的现象，但 Issue 只能证明该现象被反馈，不能据此断定你的电脑一定是同一原因。github.com
Stack、auto-route 与 strict-route：三项不要同时盲改
Mihomo 的 TUN 配置包含 stack、auto-route、strict-route、auto-detect-interface 和 dns-hijack 等参数。官方文档列出了 gvisor、system、mixed 等 Stack 选项，但本文不预设你的版本默认值；应先查看当前值，再逐项做对照测试。github.com
- 记录当前值：在 Clash Verge Rev 的 TUN 设置或配置编辑入口中，记录
stack、auto-route、strict-route、auto-detect-interface和dns-hijack。界面没有直接显示时，以当前配置文件为准，字段路径可能因版本和配置方式不同而变化。 - 只切换 Stack：保持其他参数不变，依次用当前值、另一个可选值进行测试。可选值包括
gvisor、system、mixed，不要把“默认值”当作固定结论。每次切换后关闭再开启 TUN，并重复第一节的四项测试。 - 检查 auto-route：如果目标是让系统流量进入 TUN，确认
auto-route的状态符合你的配置意图。关闭它后，系统可能不会自动把流量导入 TUN；开启后则要结合route print查看实际路由。 - 检查 strict-route：
strict-route会强化路由规则。Mihomo 文档说明，在 Windows 上它还用于增加防止普通多宿主 DNS 解析造成泄漏的防火墙规则，但特定虚拟化软件等场景可能受影响。若开启后虚拟机、局域网或本地工具异常，可记录现象后暂时关闭对照。github.com - 回滚：如果切换后问题更严重，恢复原来的 Stack 与路由参数，再关闭 TUN。不要一次同时修改 Stack、DNS、MTU 和路由排除项，否则无法判断是哪一项产生影响。
出口网卡与多网卡：检查 auto-detect-interface 是否选错
电脑同时连接 Wi-Fi、网线、虚拟机网卡、移动热点或其他隧道网卡时，TUN 可能需要明确出口接口。Mihomo 文档说明，auto-detect-interface 用于自动识别出站接口；当设备同时存在多个出站接口时，可以手动指定出口网卡。github.com
- 列出接口：执行
ipconfig /all，记下当前真正能访问互联网的物理网卡名称；再执行route print，确认默认路由对应的接口。 - 先做自动识别对照：确认
auto-detect-interface当前状态，然后只改变这一项并重新开启 TUN。若电脑只使用一块物理网卡，可先保持自动识别；若同时连接多块网卡，记录哪一块负责默认路由。 - 需要时指定接口：如果当前版本配置支持
interface-name，按 Mihomo 配置格式填写实际出口网卡名称；不要照抄示例名称。修改后重新执行route print，确认默认流量没有指向已断开的接口。 - 排除干扰：暂时断开不使用的 Wi-Fi、网线、移动热点，退出其他 VPN、WireGuard、虚拟机网络软件，再测试一次。公开 Issue 中有多网卡导致 TUN 路由在适配器之间切换并伴随 DNS 失败的反馈，这属于可参考的排查线索，不是对所有设备的定论。github.com
- 回滚：如果指定接口后网络更差，恢复自动识别，重新连接原来的网络，并关闭 TUN 验证基础网络是否恢复。
DNS 覆写、dns-hijack 与 MTU：不要混为一谈
“DNS 覆写”和 dns-hijack 不是同一个设置：前者通常指客户端界面对 DNS 配置的覆盖或替换，后者指把匹配到的 DNS 请求导入内部 DNS 模块。Mihomo 文档明确列出 dns-hijack 的作用，并说明 Windows 下使用相关劫持能力时与 strict-route 有关联。github.com
- 确认是否只是 DNS 故障：开启 TUN 后执行
ping 1.1.1.1与nslookup example.com。前者有结果、后者失败时，优先看 DNS；两者都失败时，回到路由和出口网卡排查。 - 检查 dns-hijack：在 TUN 配置中查看是否存在类似
any:53或tcp://any:53的 DNS 劫持项。不要把整段配置直接照抄到不支持该字段的客户端界面，字段格式以当前版本和 Mihomo 文档为准。 - 检查 DNS 覆写：如果客户端有“DNS 覆写”开关，记录原状态后做一次单变量测试。改变后重新开启 TUN，执行
nslookup example.com，并查看客户端日志中是否出现持续的 DNS 超时或解析失败提示。 - 不要先改 MTU：Mihomo 文档说明 MTU 会影响极端条件下的传输速率，一般用户可以保持默认值。除非你有明确的分片、特定链路或抓包证据，否则先不要把 MTU 当作断网的第一原因。github.com
- 回滚：恢复原 DNS 覆写、
dns-hijack与 MTU 设置，关闭 TUN 后确认普通网络，再逐项重新测试。
局域网、虚拟机和配置重置：最后再做，并先备份
如果公网访问正常，但打印机、NAS、虚拟机或局域网设备无法访问，不能直接说 TUN 一定“接管了全部局域网流量”。在 auto-route 开启时，相关地址可能被导入 TUN，实际结果要结合路由表和配置判断。
- 确认地址范围：例如局域网常见私有地址段可写成完整的
192.168.0.0/16，不能把192.168.x.x直接当作规则格式。 - 检查排除方式：根据当前配置格式选择
route-exclude-address，或在规则中使用类似IP-CIDR,192.168.0.0/16,DIRECT,no-resolve的完整写法。应用前先备份配置，并确认客户端支持该字段。 - 查看日志：在客户端设置的高级区域寻找
Open Logs Dir或日志目录入口。Clash Verge Rev 的设置文案显示，客户端提供打开日志目录、配置目录和核心目录的入口；具体路径以当前版本为准。github.com - 重置前备份：先导出或复制订阅链接，备份 profiles、配置文件和自定义规则；再完全退出客户端和服务，确认后台进程已结束。配置目录清理可能丢失订阅、规则和全部设置，不应作为第一步。
- 何时停止排查：如果关闭 TUN 后基础网络正常、开启 TUN 始终断网，并且权限、网卡、路由和 DNS 对照均无效，应保留日志、客户端版本、Windows 版本、
ipconfig /all与route print的关键信息，再向客户端项目或配置提供方反馈。
参考资料
- MetaCubeX Mihomo TUN 配置文档：auto-route、strict-route、dns-hijack、auto-detect-interface 与 MTU
- Clash Verge Rev 设置文案：TUN、Service Mode、配置目录与日志目录入口
- Clash Verge Rev Issue #7743：Windows 开启 TUN 后本地网络断开反馈
- Clash Verge Rev Issue #6562：多网卡环境下 TUN 路由与 DNS 异常反馈
常见问题
Clash Verge Rev 开 TUN 后完全断网，应该先改 Stack 吗？
不建议第一步就改 Stack。先关闭 TUN恢复网络，执行 ipconfig、route print、ping 1.1.1.1 和 nslookup example.com，判断是没有虚拟网卡、路由失败还是 DNS 失败。确认网卡和权限正常后，再只切换 gvisor、system、mixed 中的一个值做对照。不同版本的默认 Stack 需以当前设置为准。
TUN 开启后公网 IP 能通，但网页打不开，怎么判断是不是 DNS？
执行 ping 1.1.1.1 和 nslookup example.com。如果前者有结果、后者失败，优先检查 DNS 覆写、dns-hijack 和 strict-route；同时查看客户端日志是否持续出现 DNS 超时或解析失败。不要把这种现象直接归因于节点失效。
TUN 模式会不会导致 192.168.x.x 的局域网设备无法访问？
在 auto-route 开启时，相关局域网地址可能被导入 TUN，但不能仅凭开启 TUN 就断定一定会断。先用 route print 查看目标网段走向，再按客户端支持的格式配置 route-exclude-address，或使用完整规则 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve，并保留回滚副本。
是否应该把 MTU 改小来解决 Windows TUN 断网？
一般不应把 MTU作为第一步。Mihomo 文档说明 MTU主要影响极端条件下的传输速率，一般用户可以保持默认值。只有在确认存在分片、特定链路兼容性或相关日志证据时，才适合单独测试 MTU。