1. 系统代理与 TUN 接管的位置不同
浏览器可以访问目标网站，终端工具、游戏或更新程序却连接失败，首先要区分应用是否使用了代理。系统代理只是把代理地址写入操作系统设置；应用需要主动读取并遵守这些设置，才会把请求交给 Clash。程序自行建立 TCP 或 UDP 连接时，单独打开系统代理通常不会改变它的连接路径。
TUN 是三层虚拟网络接口，处理的是 IP 数据包。开启后，内核与客户端配合创建接口、调整路由，把符合条件的数据包送入代理内核。应用不必理解 HTTP 代理或 SOCKS 代理，但流量仍然需要满足路由、权限与内核支持条件。
| 方式 | 接入位置 | 适合验证的场景 |
|---|---|---|
| 系统代理 | 应用读取系统代理设置 | 浏览器、遵守系统设置的桌面应用 |
| 显式代理 | 应用指定本地代理地址 | curl --proxy、终端环境变量 |
| TUN 模式 | 虚拟网卡与系统路由 | 不读取系统代理的程序、受支持的 UDP 流量 |
本文的 YAML 字段以 mihomo 为基准。历史 Clash 内核、不同分支及移动端封装的能力并不完全相同。排查前先在客户端的「关于」或内核信息页面确认运行的内核名称，不要只看应用名称中是否包含 Clash。
2. 数据包、路由与 DNS 如何配合
从应用到出站连接
- 应用解析域名，并向目标 IP 发起连接。
- 操作系统查询路由表，符合 TUN 路由条件的数据包进入虚拟接口。
- mihomo 读取数据包，结合目标地址、域名映射及规则匹配结果选择策略。
- 内核通过物理网卡建立直连或代理出站连接，再把响应交回应用。
物理网卡仍负责连接路由器、无线网络或移动网络。TUN 不会代替实际网络链路，也不会凭空改善节点带宽。内核自身的出站流量必须避开再次进入 TUN 的循环；自动出口识别、接口绑定和路由处理都与此有关。同时运行另一个 VPN 时，两套程序可能竞争默认路由或策略路由。
为什么 DNS 常常决定是否可用
规则可能按域名匹配，但网络包本身主要携带 IP 地址。如果 DNS 请求绕过内核，域名映射信息可能不完整。启用内核 DNS 并把常规 DNS 请求引入它，有助于域名规则与连接记录对应起来。
fake-ip 模式可以向应用返回合成地址，例如从 198.18.0.1/16 范围分配地址，随后由内核通过映射恢复目标域名。这个地址不是目标站点真实地址，也不应被当成节点 IP。某些设备发现、局域网服务或强依赖真实解析结果的应用需要例外，应根据具体域名调整 fake-ip-filter。
dns-hijack接管的是匹配的 DNS 流量，不是所有加密 DNS。- 浏览器自带的 DoH 通常使用 HTTPS，不能仅靠接管
53端口来处理。 - 应用已经缓存的解析结果不会立即消失。调整 DNS 后应重启测试应用，必要时清理系统 DNS 缓存。
3. mihomo 配置与启动前检查
先关闭 TUN，使用本地混合端口验证订阅、节点和规则能够工作。下面以 127.0.0.1:7890 为本地代理地址；如果客户端显示的是其他端口，测试命令也要同步修改。节点本身不能连接时，应先修复节点或订阅，避免把问题误判为虚拟网卡故障。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.comWindows PowerShell 中可使用 curl.exe，避免旧版环境将 curl 解释成其他命令。得到 HTTP 响应说明这次代理请求已到达目标服务；它不代表所有站点、UDP 或 TUN 已经正常。
合并到现有配置的示例
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 1.1.1.1| 字段 | 实际用途 | 检查要点 |
|---|---|---|
stack: mixed | 在 mihomo 中组合使用系统与用户态协议栈 | 并非 mixed-port；两者不是同一概念 |
auto-route | 自动添加指向 TUN 的路由 | 需要系统权限，可能与已有 VPN 路由冲突 |
auto-detect-interface | 自动识别出站接口 | 多网卡、虚拟机和 VPN 环境仍需核对实际出口 |
dns.listen | 提供本地 DNS 监听 | 1053 不等于系统自动改用此端口，仍需 DNS 接管或其他转发安排 |
图形客户端往往会生成最终配置。直接修改订阅缓存文件可能在更新订阅后失效，优先使用客户端提供的覆写、合并配置或 TUN 设置入口。不要重复添加两个顶层 tun 或 dns 键；修改后检查运行配置和启动日志，而不只检查编辑器里的文本。
4. 各平台开启步骤与权限
Windows：先处理服务权限，再启用虚拟网卡
- 在所用客户端的设置中查找「服务模式」或服务安装入口，按提示完成管理员授权。部分客户端也支持直接以管理员身份运行，两种方式以客户端说明为准。
- 确认服务运行正常，再开启「TUN 模式」或「虚拟网卡模式」。Clash Verge Rev 的相关入口可在「设置」中查找「服务模式」及「虚拟网卡模式」；不同发行版的分组名称可能不同。
- 打开日志，检查是否出现权限不足、设备创建失败、路由添加失败。界面开关变亮只表示提交了操作，不等于内核成功接管。
- 用
Get-NetAdapter检查网络接口，用route print比较开启前后的路由。部分实现使用分段路由或策略处理，不一定直接替换可见的默认路由。
如果组织设备禁止安装虚拟网卡或后台服务，需要由设备管理员处理权限策略。不要为测试关闭整个系统防火墙。先检查客户端及内核的允许规则，并用日志定位具体失败步骤。
macOS：授权辅助服务并核对出口
桌面客户端通常需要安装或授权特权辅助服务，才能创建 TUN 接口、调整路由与 DNS。按应用提示完成系统授权，再开启 TUN。使用 ifconfig 可观察 utun 接口，但 macOS 自身和其他 VPN 也会创建同类接口，接口存在不能单独证明是当前客户端创建的。
ifconfig
route -n get 1.1.1.1
scutil --dns结合启动日志、路由查询与连接记录判断结果。若有企业 VPN、其他网络扩展或网络过滤工具，先记录原有状态，再做单变量对比；不要仅凭 utun 编号认定冲突对象。
Linux：检查 TUN 设备与网络管理权限
桌面图形客户端可能通过服务提供权限；命令行运行的 mihomo 则需要具备创建接口、设置路由所需的权限。以 root 服务运行是常见方式，也可按部署要求配置能力集，但不能认为只给二进制增加一个权限就适用于所有 DNS 与路由环境。
ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all
resolvectl statusresolvectl 仅适用于使用 systemd-resolved 的系统。容器除了进程权限，还需要暴露 TUN 设备并配置相应网络能力；单独在容器里写 enable: true 不够。远程服务器变更路由前保留第二条管理连接或控制台入口，避免 SSH 回程被新规则改变。
Android 与 iOS：使用系统 VPN 接入机制
Android 上，Clash 类客户端通常通过系统 VPN 授权接管设备流量，不需要套用桌面端的服务安装步骤。首次连接时确认系统 VPN 对话框，再检查应用的分应用代理名单：被排除的应用不会因为规则设为全局就自动进入客户端。另一个 VPN 应用正在连接时，也可能导致当前连接无法建立。
Android 的「始终开启 VPN」与「阻止未使用 VPN 的连接」会改变断线行为。开启阻断后，客户端退出可能造成设备暂时无法联网，应先确认恢复入口。iOS 则由支持相应功能的客户端通过 Network Extension 建立 VPN 配置，按系统提示授权；桌面 mihomo 的 TUN 字段不能直接视为所有 iOS 客户端的通用配置。
5. 验证接管，而不是只看开关
测试 TUN 时，临时关闭系统代理，并移除测试终端的代理环境变量，避免请求实际仍通过显式代理成功。测试完成后恢复原设置。下面的命令让本次 curl 请求跳过代理配置，但操作系统路由仍然可以把它送入 TUN。
curl --noproxy "*" --connect-timeout 10 -I https://example.com- 看连接记录：执行命令后，在客户端的「连接」页面查找目标域名或目标 IP，核对命中的规则与实际出站策略。
- 看路由变化：比较关闭、开启 TUN 时的路由与策略路由，确认没有误选另一张虚拟网卡作为出口。
- 测实际应用：启动原本不认系统代理的程序，观察其新连接。已经建立的长连接应先断开重建。
- 单独测 UDP：使用确实产生 UDP 的应用验证。HTTP 请求成功不能推导出游戏、语音或 QUIC 一定正常。
如果连接记录显示 DIRECT，表示流量可能已经进入内核，只是规则选择了直连，并非接管失败。反过来，浏览器能访问页面但连接记录中没有对应请求，应先排除浏览器扩展、自带代理、缓存或其他 VPN 的影响。
6. 常见故障按层处理
| 现象 | 优先检查 | 下一步操作 |
|---|---|---|
| 开启后全部断网 | 权限、出口接口、DNS 与路由循环 | 关闭 TUN 恢复网络，对照启动日志逐项开启 |
| 域名失败，部分 IP 连接正常 | DNS 监听、接管和上游可达性 | 核对内核 DNS 日志，检查浏览器安全 DNS 设置 |
| 网页正常，游戏或语音失败 | UDP 支持、规则出站与服务端 | 确认节点支持 UDP，并观察对应连接是否进入内核 |
| 局域网设备访问异常 | 私网规则、DNS 映射、路由排除 | 按实际网段配置直连；需要绕过接管时再设置路由排除 |
| 只有少数 IPv6 连接异常 | 系统 IPv6 路由与内核配置 | 对比 IPv4、IPv6 测试，检查是否存在绕过或出口不支持 |
直连规则与路由排除不是同一件事
例如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 表示匹配流量进入内核后选择直连；它不是操作系统层面的 TUN 排除。对于打印机发现、广播或组播需求，还要考虑应用发现机制及客户端的实际支持，不能只增加一条 TCP 直连规则就认为完整解决。
不要把 MTU 当成首个调整项
少数网站卡在加载、大文件传输中断，而小请求正常时，才值得在排除 DNS、节点和规则问题后检查路径 MTU。若当前值为 1500，可以记录原值后临时尝试 1400 做对照；这一数值只是诊断变量，不是所有网络的推荐值。确认没有改善就恢复，避免同时修改协议栈、DNS 和 MTU 导致无法归因。
关闭后的恢复顺序
- 先在客户端关闭 TUN，等待接口和自动路由清理完成。
- 恢复原来的系统代理、DNS 与其他 VPN 设置，重新建立测试连接。
- 若仍不通，检查残留路由和 DNS；优先正常重启客户端或其服务，不要直接删除不明系统路由。
稳定的配置应能说明三个问题：哪些流量进入虚拟网卡、DNS 在哪里解析、每条连接最终走哪个策略。把这三项与日志对应起来，比反复切换全局模式或更换节点更容易定位故障。只有需要覆盖不遵守系统代理的程序时，才有必要引入 TUN 所需的权限与路由变化；浏览器和显式代理已满足需求时，可以继续使用原有接入方式。