TUN 到底改了哪三层？

层级系统里发生了什么出错后的表现看哪里
虚拟网卡新增一个 TUN 网络接口TUN 打不开或一开就报错权限、驱动、系统网络授权
路由表把默认路由或分流路由指向 TUN 接口全局断网、本地网关也异常默认路由、局域网路由、接口顺序
DNSDNS 查询进入客户端或指定解析器IP 能通，域名打不开客户端 DNS 日志、系统 DNS、Fake-IP 设置
规则引擎根据域名、IP、进程或规则集选出站只有部分网站异常命中规则、最终出站、日志级别

它和系统代理有什么不同？

系统代理像给应用递一张纸条：HTTP、HTTPS 或 SOCKS 代理地址在这里，愿意读设置的应用自己去用。

TUN 更靠近网卡层。客户端创建一个虚拟接口，把系统流量先收进代理核心，再让规则决定直连、代理或拦截。命令行工具、游戏和不读取系统代理的软件，因此更可能被 TUN 覆盖。

这也是 TUN 更容易出问题的原因：它动的是系统网络路径，不只是某个应用的代理端口。

为什么开 TUN 后反而全局断网？

最常见的不是「节点坏了」，而是链路在进入节点前就断了。

第一层是权限。虚拟网卡没创建成功，后面的路由和 DNS 都没有落点。

第二层是路由。默认路由被改到 TUN 接口后，如果客户端核心没有正常转发，所有连接都会被送进黑洞；如果局域网路由也被覆盖，连路由器后台、NAS、打印机都可能打不开。

第三层是 DNS。IP 地址能 ping 通、域名打不开时，优先看 DNS 查询有没有进入客户端日志，而不是继续切换出站。

桌面端、手机端、软路由分别看什么？

场景重点位置判断方式
Windows / macOS 桌面端虚拟网卡和默认路由系统网络设置里能看到新接口，路由表出现对应接口
Android / iOS 客户端VPN 权限系统状态栏出现 VPN 标识，客户端日志有连接记录
OpenWrt / 旁路由防火墙、转发表、DNS 劫持终端设备网关正确，路由器日志能看到转发和解析
Docker / NAS容器网络与宿主机路由容器出站和宿主机默认路由不要互相覆盖

Mihomo、sing-box、Clash Verge Rev、Hiddify、NekoBox 等客户端都可能提供 TUN 或 VPN 模式，但平台差异很大。桌面端多看路由表，手机端先看系统 VPN 权限，软路由优先看防火墙和 DNS 转发。

怎么确认 TUN 已经正常工作？

确认虚拟网卡存在。桌面系统里能看到新增接口，客户端日志里没有创建接口失败、权限不足或驱动异常。

再确认路由表变化。默认路由或指定网段路由应该指向 TUN 接口；局域网网段如果要保留直连，不能被错误送进 TUN。

最后确认 DNS。打开一个域名时，客户端日志应该能看到 DNS 查询或规则命中记录。关闭 TUN 后，虚拟网卡、路由和 DNS 都应该恢复到原状态。

排查时按什么顺序来？

  1. 先关掉 TUN，确认普通系统网络能恢复。
  2. 开 TUN 后看虚拟网卡是否出现，日志是否报权限或驱动错误。
  3. 看默认路由和局域网路由，确认本地网关没有被错误接管。
  4. 用 IP 和域名分别测试：IP 通但域名不通，优先查 DNS。
  5. 只剩单个网站异常时，再看规则命中和出站选择。

这个顺序的好处是少走弯路。虚拟网卡都没起来时，调整规则没有意义；DNS 没接好时，换节点也不一定改善。

相关阅读