开启结论：程序不走系统代理，再用 TUN
浏览器能连接，游戏、命令行或桌面应用不能连接时，先确认该程序是否遵循系统代理。系统代理主要向应用提供 HTTP 代理设置；应用可以采用，也可以忽略。TUN 则在网络层接收被路由到虚拟网卡的 IP 数据包，不要求每个程序单独填写代理地址。
本文配置以 Clash Meta 后续项目 mihomo 的字段为准。Clash 是一类内核与客户端生态的常用称呼，界面上出现“TUN”不代表不同内核、不同系统的实现完全相同。先在客户端的“关于”或内核信息中确认实际使用的内核，再应用对应配置。
- 只用浏览器：系统代理通常足够，排查链路也更短。
- 程序没有代理设置：TUN 更适合，但仍需验证该程序的 TCP、UDP 流量是否被接住。
- 游戏、语音或 QUIC：除了 TUN，还要确认代理协议及服务端支持 UDP 转发。
- 公司 VPN、远程桌面正在工作：先保存工作，记录原路由和 DNS；不要在远程连接是唯一入口时贸然改默认路由。
虚拟网卡原理：从 IP 包到规则分流
接管路径有四步
- 应用发起连接。程序准备访问域名或 IP，系统根据路由表决定从哪张网卡发送。
- 路由导向 TUN。客户端创建虚拟网卡，并安装相应路由；符合条件的数据包进入 TUN 设备。
- 内核处理连接。协议栈接收 IP 包，提取目标地址、端口及可获得的域名信息，交给规则引擎判断。
- 执行出站策略。直连流量从实际网络接口发出，代理流量通过所选代理连接发出，响应再沿对应路径返回应用。
这里的“虚拟网卡”不是新增一条物理网络。它是操作系统与用户态网络程序之间交换数据包的接口。客户端还必须避免自己的代理出站再次进入 TUN，否则会形成路由循环；这也是出口接口识别和权限配置重要的原因。
接管范围受路由和排除项约束
auto-route: true用于自动配置到 TUN 的路由，auto-detect-interface: true用于自动识别出站接口。它们不是“所有场景都能接管”的保证。其他 VPN 的路由、绑定特定网卡的程序、客户端排除项，以及 IPv6 配置，都可能改变实际路径。
如果只接管 IPv4，而应用优先使用 IPv6，部分连接就可能从另一条路径发出。不要仅凭“网页能打开”判断接管完整；应同时查看目标程序的连接记录、规则命中和实际出站策略。TUN 也不会自动代理同一局域网里的其他设备，网关共享需要另行配置转发与路由。
system 与 gvisor：先选协议栈，再做兼容测试
stack控制 TUN 数据包采用哪种协议栈处理，不是节点协议，也不是代理加密方式。性能受系统、内核版本、连接类型和设备能力影响，不能把某一种栈固定称为“最快”。
| 协议栈 | 处理方式 | 选择建议 |
|---|---|---|
system |
利用系统网络栈处理连接，具体实现随平台变化。 | 可作为初始选择；遇到特定程序或 UDP 兼容问题时再换栈验证。 |
gvisor |
使用基于 gVisor 的用户态网络栈处理数据包。 | 适合与 system 做对照测试；用户态处理可能增加 CPU 开销。 |
mixed |
在 mihomo 中，TCP 使用 system，UDP 使用 gvisor。 | 可用于分别兼顾 TCP 和 UDP；需确认当前内核与客户端支持此选项。 |
对照测试只改一个变量
- 固定同一代理策略、规则模式和网络环境，先用
system。 - 打开目标应用，观察约 60 秒，记录能否建立连接、是否中断、CPU 占用是否持续偏高。
- 只把协议栈改成
gvisor，重新启动内核后重复同一操作。 - 如果只有 UDP 应用异常，再检查代理端是否支持 UDP，不要把所有问题都归因于协议栈。
示例记录可以写成“system：网页正常、语音无法建立；gvisor：网页正常、语音可建立”。这是记录格式，不是本文实测结论。延迟测试显示 40 毫秒，也不能证明游戏 UDP 已被正确转发。
mihomo 配置：TUN、DNS 与路由一起检查
下面是合并到完整配置中的基础片段，不包含代理服务信息或策略组。现有订阅的 proxies、proxy-groups 和 rules应保留。优先使用客户端的覆写或合并功能，直接修改订阅生成文件可能在更新时被覆盖。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
nameserver:
- 1.1.1.1
- 8.8.8.8这些端口分别负责什么
7890：HTTP 与 SOCKS 共用的混合代理监听端口，供系统代理或应用显式连接；TUN 接管并不是把所有 IP 包送到这个端口。127.0.0.1:1053：本机 DNS 监听地址，避免直接占用系统的 53 端口；不代表系统 DNS 已自动改成该地址。any:53与tcp://any:53：匹配进入接管路径的普通 UDP、TCP 53 端口 DNS 请求，交给内置 DNS 处理。198.18.0.1/16：fake-ip 使用的地址池，帮助内核建立域名与虚拟地址的映射，不是代理服务器地址。
DNS 劫持的边界
应用自带的 DoH、DoT 不使用普通 53 端口查询，因此不能靠上述 dns-hijack直接改写其 DNS 内容。它们的连接仍可能经过 TUN，但内置 DNS 未必知道最终域名。域名规则能否命中，还取决于 fake-ip 映射、嗅探配置及实际协议。
fake-ip 模式下，看到某个外部域名返回类似 198.18.0.23的地址可以是正常现象；这是映射结果，不是目标网站真实 IP。局域网打印机、NAS 和内部域名如发生兼容问题，应结合实际域名配置过滤或 DNS 分流。不要为了修一个内部域名，把所有域名都排除出 fake-ip。
分平台开启：先授权，再启动内核
界面名称会随客户端版本变化。下面按常见入口说明操作目的；如果找不到同名菜单，按“服务、权限、TUN、虚拟网卡”查找对应功能，不要把其他客户端的路径当成当前版本的固定路径。客户端选择可先看客户端对比。
Windows：服务模式与虚拟网卡驱动
- 导入配置后，先用系统代理确认同一代理策略可以访问目标服务。混合端口例如为
7890，应与应用设置一致。 - 以 Clash Verge Rev 常见界面为例，进入“设置”→“服务模式”，按界面提示安装或启用服务；该过程可能触发管理员授权。
- 返回主页打开“TUN 模式”，或在版本对应的网络设置中启用 TUN。服务不可用时，先解决服务状态，不要反复切开关。
- 查看内核日志，确认虚拟网卡与路由初始化没有权限或驱动错误，再测试原先不走代理的程序。
Windows 客户端通常需要配套的虚拟网卡驱动，例如 Wintun；驱动获取与安装应走客户端支持的流程。不要从随机来源复制驱动文件。可以在 PowerShell 中读取当前网卡和 IPv4 路由：
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric虚拟网卡名称由客户端或配置决定，不一定叫 Clash。看到网卡存在只说明设备创建成功，还要检查路由和连接记录。若电脑同时运行其他 VPN，先退出其中一个再测试，避免两套接管机制争抢流量。
macOS：辅助服务权限与 utun 接口
- 确认客户端及其内核支持 TUN；只有系统代理功能的客户端不能靠添加 YAML 字段获得完整 TUN 能力。
- 在客户端的服务或权限设置中，按提示安装辅助服务并完成管理员授权。
- 启用 TUN，检查日志中的设备、路由和 DNS 初始化信息。
- 用终端读取接口与路由，随后启动目标程序验证。
ifconfig
netstat -rn -f inet
scutil --dnsmacOS 上常见的虚拟接口名为 utun加编号，但其他 VPN 或系统服务也可能创建 utun。不能只凭存在 utun3就判断它属于当前客户端。休眠唤醒或 Wi-Fi 切换后异常时，应重新检查出口接口，而不是只更换代理节点。
Linux：TUN 设备与网络管理权限
Linux 通常需要可用的 /dev/net/tun以及创建接口、修改路由所需的网络管理权限。桌面客户端可能通过服务取得权限；直接运行内核时，按发行版和服务部署方式配置权限。不要给来源不明的可执行文件授予高权限，也不要为省事给整个客户端目录递归授权。
ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all检查路由时要看所有表，因为自动接管可能使用策略路由，单独执行 ip route未必能看到完整规则。容器环境还需要宿主机提供 TUN 设备与必要权限；容器内开启开关不意味着能接管宿主机应用。
Android 与 iOS：使用系统 VPN 授权机制
Android 的常见 Clash 客户端通过 VpnService接管流量，首次启用会出现系统 VPN 连接授权，一般不需要 root。检查应用的 VPN 模式、绕过应用列表，以及系统电池后台限制。通常同一用户下只能有一个活动的普通 VPN 服务，另一个 VPN 启动时可能把当前连接替换掉。
iOS 需要客户端自身提供并获准使用 Network Extension 等系统能力，桌面配置中的 TUN 字段不能凭空创建这项能力。按客户端流程添加 VPN 配置并授权，再检查其支持的配置语法。不要把 mihomo 的完整 TUN 片段直接套给语法不同的 iOS 客户端。
验证接管：不要只看 TUN 开关
先做三项交叉检查
- 设备和路由：虚拟接口已创建，接管路由已安装，日志没有持续的权限或设备打开失败。
- 目标程序连接：打开原先忽略系统代理的程序，在客户端“连接”页面观察对应目标地址与端口。例如 HTTPS 常见为 TCP 443，QUIC 常见为 UDP 443，但端口本身不能证明应用类型。
- 规则与出站：确认连接命中预期规则和策略。需要代理的目标若命中 DIRECT，即使 TUN 正常，行为也不会符合预期。
为区分两条入口，可以暂时关闭系统代理，并清除目标程序自身手动设置的 HTTP、SOCKS 代理，只保留 TUN 做一次测试。浏览器仍能联网并不是充分证据：直连网络也可能访问该网站。应以连接记录和出站策略交叉确认，测试后恢复自己需要的设置。
按症状缩小范围
| 症状 | 优先检查 |
|---|---|
| 开启后所有程序断网 | 服务权限、出口接口识别、DNS 可达性、其他 VPN 的路由冲突。 |
| 网页正常，语音或游戏异常 | UDP 接管、代理端 UDP 能力、应用排除列表，再对照测试协议栈。 |
| 公网正常，NAS 或打印机不可用 | 局域网路由、内部 DNS、fake-ip 过滤以及当前网络的真实网段。 |
| 切换 Wi-Fi 后失效 | 出站接口是否更新、旧路由是否残留，重新启用 TUN 后再检查日志。 |
| 连接记录中没有目标程序 | 程序是否被排除、是否走未接管的 IPv6 或特定接口，以及日志是否过滤了记录。 |
排查时把日志临时调整为 debug，记录开启 TUN 和启动目标应用的准确时间。例如 14:32:10 开启、14:32:20 启动程序，就从这 10 秒前后找设备、路由、DNS 和连接错误。定位完成后恢复 info，分享日志前遮盖订阅地址、令牌和个人网络信息。
关闭与回退：先恢复网络，再继续定位
遇到整机断网，先关闭 TUN，让客户端撤销自动路由，再根据需要恢复系统代理。正常退出客户端比直接强制结束内核更有利于完成清理。退出后仍异常时，检查系统代理是否还指向已经停止监听的 127.0.0.1:7890，以及 DNS、虚拟接口和路由是否恢复。
- 不要随手删除整张路由表；企业网络、容器和其他 VPN 可能依赖其中的规则。
- 不要盲目禁用所有虚拟网卡；先通过客户端日志和接口变化识别属于当前客户端的设备。
- 如果 fake-ip 缓存仍让应用拿到虚拟地址，退出并重新打开该应用，必要时按系统方法刷新 DNS 缓存。
- 恢复网络后，按“权限与设备 → 路由与出口 → DNS → 规则与策略 → 应用协议”的顺序重试，每轮只改变一个设置。
最终保留的应是能解释、能验证、能回退的配置：TUN 负责入口，DNS 提供域名信息，规则决定出站，代理服务承载实际连接。更完整的字段说明可查配置进阶中的 TUN 配置；首次导入订阅则按快速上手先建立基础连接。