Clash Verge Rev 开启 TUN 后局域网无法访问
打开 TUN 模式，国际网站通了，但路由器后台打不开，NAS 映射盘掉线，局域网打印机在系统里“消失”。关掉 TUN 一切恢复正常。这个现象指向的不是节点或订阅，而是 TUN 虚拟网卡在接管全系统流量时，把原本该走物理网卡的私有地址流量也送进了 Mihomo 的路由决策流程。Clash Verge Rev 的 TUN 模式本身不区分“公网”和“私网”，区分要靠规则和排除配置来做。Clash Verge Rev TUN 局域网无法访问的排查，本质上就是在这几层里找到内网流量被误吞的位置。下面按规则层、路由层、DNS 层、协议栈层逐层拆开，每一层都有对应的验证方法和可落地的修改。
01. 先判定：是规则没直连，还是路由层就没放行
排查 Clash Verge Rev 开启 TUN 后局域网无法访问，第一步不是改配置，而是确认内网流量到底走到了哪一层。
用纯 IP 访问一个内网设备，比如在浏览器输入 192.168.1.1 或 NAS 的局域网 IP。如果能打开，说明路由层是通的，问题集中在规则层或 DNS 层；如果纯 IP 也打不开，问题更可能在路由排除或 TUN 栈本身。
再看日志。把日志级别切到 debug，在“连接”页面观察访问内网 IP 时命中的规则。如果命中 MATCH 或某个代理组，说明规则列表里缺少私有地址的直连条目；如果连接根本没有出现，说明流量在路由层就被 TUN 网卡吞掉了，没进入规则引擎。
这两条判断路径对应完全不同的修改位置，先分清再动手，比直接往 rules 里加一行更稳妥。
| 现象 | 更可能的位置 | 先验证什么 |
|---|---|---|
| 纯 IP 可访问，域名不可 | DNS / fake-ip-filter | nslookup 内网域名 |
| 纯 IP 也不可访问 | 规则或路由排除 | 连接页面是否出现该连接 |
| 仅特定网段失效 | IP-CIDR 覆盖不全 | 核对实际网段 |
| 2.4.0+ 才出现 | route-exclude-address | 查看当前版本 |
02. 规则层：IP-CIDR 要放在 MATCH 之前，并且带 no-resolve
Clash 的规则匹配是“命中即止”，从上往下走。如果 MATCH,Proxy 或 GEOIP,CN,DIRECT 出现在私有地址直连规则之前，发往 192.168.x.x 的流量会先被代理组或 GEOIP 捕获，后面的 IP-CIDR 就没有机会执行了。
标准的私有地址直连规则应该放在 rules 顶部：
rules:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
- DOMAIN-SUFFIX,local,DIRECT
- DOMAIN-SUFFIX,lan,DIRECT
# 后面再接 GEOIP、MATCH 等规则no-resolve 这个参数容易被漏掉。它的作用是让 IP-CIDR 规则在匹配 IP 时不再对域名发起 DNS 解析——内网地址本来就是 IP 形式访问，加 no-resolve 能避免一次无意义的 DNS 查询超时，也减少 DNS 流量被劫持的概率。
如果你的局域网使用了非标准网段，比如 192.168.50.0/24 或 10.10.0.0/16，把上面的 /16 或 /8 换成实际网段即可。GEOIP,private,DIRECT,no-resolve 也可以作为兜底，但部分规则集的 GEOIP 数据库对 private 分类的覆盖并不完整，显式写 IP-CIDR 更可靠。
03. 路由层：2.4.0+ 版本的 route-exclude-address
如果规则已经写对了，纯 IP 访问仍然失败，或者问题是在升级到 2.4.0+ 之后才出现的，需要看 TUN 自身的路由排除。Clash Verge Rev 的 TUN 模式通过 auto-route 把默认路由指向虚拟网卡，如果私有网段没有被排除在路由接管之外，发往内网的包会被送进 Mihomo，而不是直接走物理网卡。这类 TUN 局域网无法访问的特点是“部署 Verge 的机器能访问内网，同一局域网其他设备不行”，因为路由表只在本机生效。
Issue #5889 记录了这个现象：升级到 2.4.0+ 后，局域网内 IP 不可访问，降级到 2.3.1 则正常，部署 Verge 的机器本身可以访问内网，其他设备不行。维护者在讨论中给出的绕过方式是在全局扩展覆写中添加 route-exclude-address：
tun:
route-exclude-address:
- 192.168.0.0/16
- 10.0.0.0/8
- 172.16.0.0/12这段配置放在 Verge 的全局扩展覆写中，让 TUN 在安装路由时直接跳过这些网段。它和 rules 里的 IP-CIDR 直连是两层不同的机制：rules 决定“进入内核的流量怎么走”，route-exclude-address 决定“哪些流量根本不进入 TUN”。两层都配好，内网流量才能在路由层和规则层都得到豁免。
修改后需要重新加载 TUN，或者重启客户端让路由表重新安装。
04. DNS 层：fake-ip-filter 要把内网域名挡在劫持之外
纯 IP 能访问但域名不行，问题通常出在 DNS。TUN 模式下 Mihomo 会接管 53 端口的 DNS 查询，Fake-IP 模式对每个域名立即返回一个虚拟 IP。如果内网域名（.lan、.local、公司内网后缀、路由器管理域名）没有被排除，应用拿到的是 198.18.x.x 这样的假地址，连接自然到不了真实设备。
在 DNS 配置的 fake-ip-filter 中加入需要绕过的域名后缀：
dns:
enhanced-mode: fake-ip
fake-ip-filter:
- '*.lan'
- '*.local'
- '+.公司内网域名'
- 'router.asus.com'*.lan 和 *.local 覆盖常见的 mDNS/LLMNR 局域网域名；公司内网或特定路由器管理域名按实际情况追加。过滤规则不宜过宽，把大量公网域名也塞进去会让 Fake-IP 的分流能力退化。
验证方法：在开启 TUN 的状态下执行 nslookup 内网域名。如果返回 198.18.x.x，说明该域名仍被 Fake-IP 劫持，需要补进 filter；如果返回真实的 192.168.x.x，DNS 层就是通的。
05. 协议栈与浏览器 DoH：两个容易被忽略的变量
TUN 的 stack 选择会影响局域网兼容性。system 栈使用操作系统原生网络栈，性能更好，但在部分 Windows 环境下可能受防火墙或驱动交互影响；gvisor 栈在用户态实现 TCP/IP，兼容性更强，但处理大流量时 CPU 开销更高。如果规则和路由排除都正确，局域网仍然时通时断，可以尝试在 TUN 设置中切换 stack：Windows 优先试 system，出现异常时切到 gvisor 做对照。注意 Verge 界面中 TUN 旁边的齿轮按钮可能覆写配置中的 stack 字段，修改后到“当前配置”里确认实际生效值。
浏览器 DoH 是 TUN 局域网无法访问里另一个隐蔽来源。Chrome、Edge、Firefox 开启“安全 DNS”后，浏览器不再向系统 DNS 发查询，而是直接连接 DoH 解析器。Mihomo 的 fake-ip-filter 和 DNS 规则对这种绕行查询不起作用，内网域名可能被 DoH 解析到错误地址。排查时先关闭浏览器 DoH，确认局域网访问恢复；如果必须保留 DoH，需要把内网域名写入浏览器的排除列表，或者确保 DoH 解析器本身能正确返回内网记录。
如果以上几层都排查过仍然无解，可以到项目的 TUN 模式完全指南 核对 TUN 与 DNS 的启动顺序，或者在 FAQ 页面 搜索 no-resolve、route-exclude-address 等关键词，对照同版本用户的具体配置。