一、TUN 在做什么，与系统代理有何不同
TUN 模式会在操作系统里创建一个虚拟网卡，由 Clash 内核（如 Mihomo）把符合规则的 IP 流量「接进」代理栈再送出。与仅设置系统 HTTP/SOCKS 代理相比，TUN 能覆盖不遵循系统代理的程序（部分游戏、命令行工具、UWP 应用等），因此是进阶用户常用能力，但也更容易碰到路由、驱动、防火墙等系统层问题。
若你关闭 TUN、改用系统代理或规则模式后一切正常，而一开 TUN 就异常，说明问题往往不在「节点质量」，而在本机网络栈与策略是否被正确接管。下文默认你已能使用同一订阅在非 TUN 模式下上网，仅讨论 TUN 开启后的异常。
tun 相关开关、堆栈选项（如 gVisor / system）与 DNS 模式是否与当前系统匹配；不同客户端把这些选项放在不同菜单位置，但内核行为一致。
二、先分清：全局断网、部分站点、还是 DNS 异常
排查前建议用三句话描述现象，避免把不同根因混在一起：
- 全局断网：浏览器、即时通讯、国内站点全部不可用，或仅内网可用。多与默认路由被错误接管、虚拟网卡未就绪、或所有流量被错误送到无效下一跳有关。
- 部分网站打不开：国内正常、个别境外站超时，或反之。多与规则分流、DNS 解析、节点线路有关，但也可能是防火墙仅拦截部分目标端口或协议。
- 能上 QQ / 微信但网页异常：常见于 DNS 被污染或 Fake-IP 与本地解析不一致，需单独核对 DNS 与
fake-ip配置。
记录「关闭 TUN 后是否立即恢复」与「是否同时开着其他 VPN」两条信息，能显著缩短定位时间。
三、内核与 Wintun：虚拟网卡是否真正起来
Windows 上 TUN 通常依赖 Wintun 驱动。若驱动未安装、被安全软件删除，或客户端未以足够权限创建适配器，会出现TUN 已勾选但无流量或瞬间断网。
建议检查项
- 在客户端日志中搜索报错关键词（如
wintun、create tun、permission），确认内核是否成功创建接口。 - 在「设备管理器」或「网络连接」中查看是否出现与 Clash / Mihomo 相关的虚拟网卡；若反复消失，可能是驱动被拦截或与其他虚拟网卡冲突。
- 尝试以管理员身份运行客户端后再开 TUN（部分环境需要），观察是否改善。
- 若客户端提供 TUN 堆栈选项（如 system / gVisor），可在排除其他问题后尝试切换，以规避个别环境下的兼容性问题。
若日志显示 TUN 创建失败，优先解决驱动与权限，不必先调整节点或订阅。
四、路由表：默认路由、metric 与冲突
TUN 往往会向系统添加更优先的默认路由或特定前缀路由，把流量导向虚拟网卡。若与现有物理网卡默认路由、公司 VPN、或 Zerotier 等叠加路由冲突，可能出现「全进代理隧道但隧道未通」的黑洞效应，表现即为全局断网。
如何用命令粗看路由（管理员命令提示符或 PowerShell）
执行 route print 或 Get-NetRoute（PowerShell）查看 0.0.0.0/0 的下一跳与 metric。开启 TUN 前后各导出一份对比，关注：
- 是否出现多条默认路由，metric 是否导致流量走错接口；
- 虚拟网卡接口索引是否与客户端显示一致；
- 是否存在残留路由（关闭客户端后仍指向无效接口）。
若怀疑路由残留，可在完全退出 Clash 客户端后再次查看路由表；若残留仍在，可尝试重启网卡或重启系统后再测。企业网络若强制静态路由，需与网管确认是否允许用户态程序改路由。
五、Windows 防火墙与安全软件
与「局域网共享代理端口」主要关心入站不同，TUN 场景下更常见的是本机进程出站被拦，或安全套件把虚拟网卡流量视为可疑而阻断。表现为：规则已命中、节点在线，但连接被重置或超时。
可操作步骤
- 在「Windows 安全中心 → 防火墙」中，确认 Clash 主程序对专用 / 公用网络均已允许；必要时为内核或 helper 进程单独放行（以实际安装路径为准）。
- 若使用第三方防火墙或「网络管控」类软件，将 Clash 加入信任列表或暂时关闭对比测试。
- 企业环境若启用应用白名单，虚拟网卡产生的连接可能被统一拦截，需 IT 侧放行。
与混合端口、局域网共享相关的入站放行思路，可参考本站 《Clash Windows 11 混合端口与局域网共享》 中的防火墙章节；TUN 用户通常仍需再确认本机出站未被重复拦截。
六、DNS、Fake-IP 与分流规则
开启 TUN 后，DNS 往往与内核 DNS 处理、Fake-IP 或 redir-host 模式强相关。若配置与规则不匹配，会出现「部分域名永远解析错」「国内站被送进代理」等现象，看起来像断网或无限加载。
- 确认 DNS 上游可达（公司网络可能屏蔽第三方 DNS）。
- 使用 Fake-IP 时，检查规则里是否对国内域名误分流，以及
fake-ip-filter是否覆盖常用国内域名与局域网域名。 - 若近期修改过
hosts或本地 DNS 加速器，先恢复默认再测。
这类问题在关闭 TUN、仅用系统代理时可能不明显，因为谁负责解析、谁负责建连的路径不同；因此 DNS 应作为独立一步排查，而不是只换节点。
七、与其他 VPN 或网卡抢占
若机器上同时运行其他商用 VPN、公司隧道、虚拟机桥接网卡，多个组件可能争抢默认路由或 Wintun 实例。典型做法是：只保留一条隧道逻辑——先完全退出其他 VPN，再启动 Clash TUN；或反过来测试，确认冲突对象。
部分「网络优化」或游戏加速器也会注入驱动级过滤，与 TUN 叠加后异常更难肉眼判断，建议暂时退出后做 A/B 对比。
八、现象与优先检查项速查表
| 现象 | 优先检查项 |
|---|---|
| 日志中报 TUN / Wintun 创建失败 | 驱动与管理员权限；与其他虚拟网卡冲突；尝试更换 TUN 堆栈选项 |
| 关 TUN 立刻正常，开 TUN 全局断网 | route print 对比默认路由与 metric；是否与其他 VPN 抢路由 |
| 国内正常，部分境外站不通 | 节点与规则；DNS / Fake-IP；防火墙是否拦特定协议 |
| 网页异常但即时通讯可用 | DNS 污染或解析链路；Fake-IP 与规则是否一致 |
建议始终先日志与路由，再节点，能避免无效地反复测速与更换订阅。
九、小结
Clash TUN 在 Windows 上把流量从网卡层接入代理，收益是覆盖面广，代价是更容易暴露路由表与防火墙问题。遇到断网或无法访问时，按「虚拟网卡与内核 → 路由 → 防火墙与套件 → DNS」的顺序排查，通常能快速区分是内核/驱动问题、路由冲突还是拦截与解析问题。
相比只在应用层切换系统代理，成熟的 Clash 生态在规则、内核与多客户端上选择更多；把 TUN 调通后，长期使用的稳定性往往更好。
若你尚未安装或希望使用维护积极的客户端与内核组合，可从本站获取安装包，再按上述顺序自检 TUN 相关选项。