IP 检测台

开了 TUN，为什么还有流量没走代理？

TUN 开关已经打开，首页仍显示宽带 IP，或者浏览器能访问、另一个程序却连不上。先确认你看到的是规则直连、接管遗漏还是连接失败。下面以 Mihomo 为例，从启动和路由查到出站规则，逐层缩小范围，再用同一个目标复测。

更新于

先分清三种现象

TUN 是虚拟网络接口，负责把操作系统交来的网络流量送进客户端处理；规则模式、全局模式决定进入客户端之后怎样出站。两者作用不同。开启 TUN 后，命中直连策略的连接仍可以从本地网络出去，所以“国内一栏显示宽带 IP”本身不说明 TUN 失效。

先打开分流检测，记录国内、海外和谷歌三栏，以及你实际遇到问题的程序。不要只比较不同国家的标签：优先比较具体出口 IP，再结合客户端的连接记录看目标、规则和出站选择。首页反映的是这个浏览器对几个检测目标的访问，不能替其他应用做结论。

相似现象，排查方向不同
现象先确认什么排查方向
连接记录显示 DIRECT是不是你有意设置的直连核对规则与策略组
找不到目标连接记录显示是否完整、目标是否对应再查启动、系统路由与排除范围
显示走代理但连接超时目标、协议及代理出站是否正确查节点连通性和 UDP 支持

没有连接记录还不能直接证明绕过了 TUN：日志级别、显示筛选和观察时机也可能让你漏看。先在重新打开目标的同时观察记录，必要时临时提高日志级别，复测完恢复，避免仅凭一个空列表下结论。

第一步：确认 TUN 实际启动

打开客户端日志，查最近一次启用 TUN 时有没有创建接口、权限不足或启动失败的提示，再查看当前运行配置。按钮亮起只说明你发出了启用请求；配置文件里写了 enable: true，也不代表系统已经成功建立了对应接口。

例如，Clash Verge Rev 的服务模式用于以管理员权限启动内核，从而让普通权限启动的界面也能使用 TUN。不同客户端不一定使用相同的服务或权限机制，应按所用版本的说明检查，不要把某个客户端的安装步骤照搬到另一个软件。

下面是 Mihomo 中本轮需要对照的最小字段片段，不是完整配置，也不要求你覆盖现有订阅：

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true

先保存原配置，再确认修改进入了实际运行的配置，而不只是留在一个未启用的文件里。如果客户端提示配置错误，先修复错误并重新加载，再测网络；不要在 TUN 根本没有启动时反复更换规则或 DNS。

第二步：确认连接进入客户端

接下来检查系统是否把目标流量送入虚拟接口。以 Windows 为例，可以在 PowerShell 用下面两个只读命令分别查看 IPv4 接口和路由。它们不会修改网卡或路由，也不需要把整份输出当作固定答案照抄：

Get-NetIPInterface -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv4

对照客户端记录的接口名和开启前后的路由变化。看到虚拟接口不等于每个目标都走它；反过来，也不要只找一条默认路由就判定成功或失败。不同系统和接管方式生成的路由不同，应结合目标地址、接口和同一时刻的连接记录分析。

Mihomo 的 auto-route 用于自动设置路由；若配置里有 route-exclude-address，相应网段会从自动路由范围排除。检查这些排除是不是你有意保留的局域网或其他目标，不要为了让测试变色就删除所有例外。

如果同时开着别的 VPN、另一套 TUN 客户端，或同时连接多块网卡，先记录现状，在允许调整的环境里只保留这次要测的一套接管方式，再重试同一个目标。若结果随之改变，可继续对照双方的路由和日志，不能仅凭同时安装了两个软件就认定冲突。

也要核对测试程序有没有自己的网络设置。关闭系统代理后浏览器仍然显示节点出口，可能是 TUN 仍在接管，不能据此证明浏览器没有走代理。要建立直连对照，应明确记录系统代理、浏览器代理与 TUN 各自的状态；本轮只是在确认 TUN 时，不必为了凑齐对照而随意改变所有设置。

第三步：检查规则和实际出口

如果目标连接已出现在客户端记录里，再看它命中了什么。Mihomo 按从上到下的顺序匹配规则；运行模式还可能是规则、全局或直连。某条连接进入了 TUN，不代表它必须使用远端节点，更不代表它一定命中你以为的那一条规则。

例如，为了确认某个目标的规则优先级，可以对照下面的写法。这里使用保留的示例域名，策略组“代理”必须替换成现有组名；示例只解释顺序，不会替你的真实网站配置分流：

rules:
  - DOMAIN,example.com,代理
  # 其余现有规则保留在这里
  - MATCH,DIRECT

检查具体域名规则前面有没有已经命中的直连规则，再展开策略组确认实际选中的出站。如果组里最终选择的是 DIRECT，即使规则名字叫“代理”，也不能凭组名认为流量到了节点。规则与模式的详细说明见规则模式、全局模式和直连模式的区别。

可在同一套 TUN 与节点设置下，用规则模式和全局模式做一次临时对照，并记录全局策略组选中的出口。如果只有模式切换改变了目标结果，就优先查出站策略，而不是重装虚拟网卡。对照结束后恢复原模式，并确认国内访问仍符合你的预期。

第四步：单独检查 UDP 与解析

如果普通网页能访问，实时通信或某些程序却失败，接着看失败连接的协议。TUN 能接收流量，不代表选中的代理支持所需的 UDP 转发。以 Mihomo 为例，节点通用字段 udp 控制是否允许 UDP 经过代理，但启用字段不能凭空补足服务端或协议配置缺失的能力。

还要看规则的最终走向。Mihomo 文档说明，在规则匹配中如果 UDP 请求选到不支持 UDP 的节点，可能继续向下匹配。因此不能只看第一条看似匹配的规则，就认定 UDP 一定经过了它；应在新连接记录里确认最终策略与错误，而不是把超时都归因于未开 TUN。

DNS 和 WebRTC 也要分别核对。网页请求使用了节点，并不能证明解析链路和浏览器的实时通信走了相同路径。解析异常先看DNS 泄露的四步排查；WebRTC 结果结合WebRTC 泄露说明中的候选地址类型判断。空结果或超时只能说明没有取得有效结果，不能当作已经修好。

改完后怎样复验

  1. 固定网络、节点、目标程序和同一个目标地址，记录修改前的模式、TUN 状态及失败现象，每次只改一个相关设置。
  2. 重新加载配置，确认内核与虚拟接口正常启动；让目标程序重新建立连接，对照日志中的目标、协议、命中规则与实际出站。
  3. 回到首页复测三条线路，再检查 DNS 和 WebRTC。国内按预期直连时仍可显示宽带出口，不要求所有检测都变成同一个 IP。
  4. 最后回到原来出问题的程序操作一次。浏览器正常不代表该程序也正常；无法取得的结果和仍缺少的日志，继续标为未确认。

如果 IPv4 和 IPv6 的结果不一致，要分开记录地址族，不能拿一组 IPv4 路由证明 IPv6 也已接管。本篇先确认启动、接管与规则三个环节，不把关闭 IPv6 当作通用处理。出现新问题时恢复本轮配置，再依据前后记录继续排查，保留原本正常的分流。

相关文章