系统代理与 TUN：流量入口不同

浏览器能联网，命令行工具、游戏或其他应用却没有出现在 Clash 连接列表中，首先要检查流量入口。系统代理只是向应用提供代理地址，例如 127.0.0.1:7890。应用采用该设置后，才会把请求发送给本地代理；自行直连、只读环境变量或使用独立网络配置的程序，不一定采用系统代理。

TUN 是三层虚拟网络设备。操作系统按路由表把 IP 数据包送入虚拟网卡，mihomo 再读取这些数据包，识别连接并执行分流策略。它不要求每个应用都理解 HTTP 或 SOCKS 代理，因此更适合接管普通直连应用的 TCP、UDP 流量。

对照项系统代理TUN 虚拟网卡
接入方式应用连接本地代理端口系统路由引导 IP 数据包
应用要求需要采用代理配置普通 IP 应用通常无需单独设置
UDP仅设 HTTP 系统代理通常不能覆盖可接管，仍要求节点与协议支持
权限通常不需要创建网络设备桌面端通常需要提权或后台服务
故障重点代理地址、端口、应用设置网卡、路由、DNS、权限与分流规则

开启前检查：内核、订阅与权限

Clash 是一类客户端与内核生态的常见统称，不代表每个安装包都支持同样的 TUN 参数。本文 YAML 示例面向 mihomo，即常说的 Clash Meta 内核。旧版 Clash、其他分支以及移动端客户端可能使用不同字段或配置入口，不能仅凭软件名称判断兼容性。

  1. 确认内核。在客户端的关于、内核信息或运行日志中查找 mihomo 标识。界面没有 TUN 开关时，先核对客户端能力，不要直接添加大量未知配置。
  2. 先验证订阅。在系统代理方式下确认至少一个节点可用，策略组已选中有效节点。TUN 解决流量入口问题，不能修复失效订阅或节点认证错误。
  3. 记录原设置。保存系统代理端口、当前 DNS、正在使用的 VPN 与局域网网段。首次配置保留本机操作入口，避免在远程 SSH 会话中直接修改默认路由。
  4. 准备系统授权。Windows 通常需要服务模式或管理员权限；macOS 需要按客户端提示安装特权辅助组件；Linux 需要访问 /dev/net/tun 并具备管理网络的权限。

先退出其他使用虚拟网卡的 VPN，再测试 Clash TUN。多个客户端同时添加默认路由或更改 DNS，容易造成路径反复切换。确有并行需求时，应在单独验证成功后，再逐项设计排除路由与出口接口。

gvisor、system 与 mixed 网络栈

tun.stack 控制虚拟网卡流量采用哪种协议栈处理，不是节点协议选项，也不会把 Trojan 节点改成 VLESS 节点。mihomo 的常见取值是 gvisor、system 和 mixed，实际支持情况以所用内核构建为准。

  • gvisor：使用用户态网络栈处理连接。适合作为排查兼容性时的对照选项，但不能据此保证所有系统上都更稳定。
  • system：利用系统网络栈处理连接。性能和兼容性受操作系统、驱动及网络环境影响，不宜直接认定它在所有设备上都更快。
  • mixed：在 mihomo 中组合两种处理方式，TCP 使用 system，UDP 使用 gvisor。它是网络栈组合，与同时接收 HTTP 和 SOCKS 请求的 mixed-port 无关。

切换网络栈的判断方法

每次只改一个参数，然后重启内核并重建测试连接。若网页正常但语音或游戏失败，先检查节点 UDP 能力与规则命中，再比较网络栈。若全部连接都不进入面板，应先看权限和路由；此时反复切换 gvisor、system 通常找不到根因。

mihomo TUN 配置：路由与 DNS 一起设置

下面是需要合并到现有配置的片段，不是完整订阅。它没有定义节点、策略组和分流规则，不能替代可用的完整配置。已有顶层 tun 或 dns 时，应合并字段，避免重复键被解析器覆盖。

config.yaml · TUN 与 DNS 配置片段
mixed-port: 7890
allow-lan: false
mode: rule

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

示例中的两个上游 DNS 地址是明确的配置示例，不是所有网络都适用的推荐。应选择所在网络能够访问、且符合使用要求的解析服务。如果订阅已有完整 DNS 策略，优先保留其上游与域名分流设计，仅补充必要的 TUN 字段。

auto-route 与 auto-detect-interface

auto-route: true 让内核自动设置将流量导入 TUN 的路由；auto-detect-interface: true 用于自动识别实际出口接口，帮助代理连接经物理网络发出，避免再次进入自身的 TUN。多网卡、虚拟机桥接、企业 VPN 或 Wi-Fi 与有线并行时，自动识别仍可能选错，需要结合日志核对。

不要只检查路由表里有没有 0.0.0.0/0。不同平台可能使用更具体的分段路由、不同表或策略路由完成接管。是否生效应同时结合路由查询结果和客户端连接记录判断。

dns-hijack、1053 与 fake-ip

dns-hijack 将匹配的 DNS 流量交给 mihomo 内置 DNS。示例 any:53 用于常见 UDP 53 查询；若确需处理 TCP 53，可按内核支持补充 tcp://any:53。它不是所有解析协议的总开关，不能直接识别并劫持浏览器通过 HTTPS 发送的 DoH 请求。

127.0.0.1:1053 是示例 DNS 监听地址，并不是要求把系统 DNS 填成带端口的字符串。多数系统 DNS 设置只接受 IP 地址；TUN 接管路径、监听端口与系统 DNS 设置需要分别理解。

fake-ip 会为域名分配虚拟地址，再由内核保存域名与连接之间的对应关系。示例地址池 198.18.0.1/16 属于保留测试地址范围，解析出这个范围内的地址不等于 DNS 出错。需要真实解析结果的局域网服务，应通过适当的 fake-ip-filter 和 DNS 分流处理，而不是把所有域名都排除。

Windows、macOS 与 Linux 开启步骤

不同客户端菜单命名并不统一，下列步骤按功能入口描述。若界面提供 TUN、网络栈和 DNS 接管选项，优先使用这些入口；不少客户端会在运行时重新生成配置，直接修改生成文件可能在下一次启动时失效。订阅更新也可能覆盖手工修改，应使用客户端提供的持久化覆写或合并功能。

Windows：服务权限与虚拟网卡

  1. 导入订阅并确认系统代理能够访问目标服务，再暂时关闭其他 VPN。
  2. 进入客户端设置中的服务模式入口，按提示安装并启动服务；若客户端采用其他提权机制，则按其说明完成管理员授权。
  3. 打开 TUN 开关，选择内核支持的网络栈，应用配置。遇到驱动安装或网络设备授权提示时，确认提示来自当前客户端。
  4. 打开 PowerShell，检查新增虚拟网卡与 IPv4 路由；同时查看客户端日志中是否存在权限不足、创建设备失败或路由添加失败。
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix,InterfaceAlias,NextHop,RouteMetric

网卡名称由客户端和配置决定，不必固定叫 Clash。网卡存在只能证明设备已创建，不能单独证明应用流量已经命中代理策略。

macOS：辅助组件与 utun 接口

  1. 确认所用客户端和内核支持 TUN，并完成其要求的特权辅助组件安装。
  2. 在客户端启用 TUN 或同等虚拟网卡功能，出现系统授权时按提示确认。
  3. 使用下面的命令查看接口、路由和系统 DNS，再与启用前的结果对照。
ifconfig
netstat -rn -f inet
scutil --dns

macOS 可能同时存在多个 utun 接口，其他 VPN 和系统功能也会创建它们。不要看到一个 utun 就认定属于 Clash，也不要手动删除所有同类接口。应通过启停前后差异、路由与日志确定归属。

Linux：TUN 设备与网络管理权限

桌面客户端通常通过服务进程完成提权。命令行部署时，进程至少需要满足创建 TUN 和管理路由的权限要求，常涉及 CAP_NET_ADMIN；还需结合内核功能、服务限制和运行方式检查其他权限。不要直接套用任意 capabilities 清单。

test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
resolvectl status

resolvectl 适用于使用 systemd-resolved 的系统，命令不存在不代表 TUN 故障。容器内运行还需要宿主机提供 TUN 设备及相应网络权限，仅在容器里改为 root 不一定足够。首次测试应在本机完成，避免路由变化中断远程管理连接。

Android 与 iOS：系统 VPN 授权

Android 客户端通常通过系统 VPN 接口接管流量，不需要照搬桌面端的网卡驱动安装步骤。导入兼容配置后，选择 VPN 或虚拟网卡运行方式，首次连接时允许系统 VPN 授权。如果启用了按应用代理，检查目标应用是否在接管范围内；被排除的应用不会因为桌面示例开启了 auto-route 就自动纳入。

iOS 客户端通常使用系统提供的网络扩展能力。应先确认应用支持相应的配置格式，再添加系统 VPN 配置并授权连接。不能把桌面 mihomo 的全部 TUN 字段直接视为 iOS 通用配置，也不能假设每个支持 Clash 订阅的应用都运行 mihomo 内核。

移动端一般不能同时启用两个同类的普通 VPN 隧道。若连接后立即断开，先检查其他 VPN、按需连接规则以及系统后台限制，而不是反复更换节点协议。

验证接管：连接记录、DNS 与 UDP

先排除系统代理造成的误判

临时关闭客户端的系统代理开关，保留 TUN。使用原本不配置代理的程序发起新请求，并查看连接面板的进程、目标、规则和出站策略。也可运行下面的命令，明确让 curl 不使用显式代理；这只能排除该请求采用显式代理的情况，不能单独证明 TUN 已接管。

curl --noproxy '*' -I https://example.com

若页面可访问且连接记录中能找到对应请求，再核对命中的策略。命中 DIRECT 是正常的规则结果，不是 TUN 失效。节点切换后已建立的长连接也可能继续使用原路径，验证时应重新建立连接。

分别验证 DNS 与 UDP

  • DNS：使用系统解析工具查询一个未缓存域名，观察内核日志。浏览器开启安全 DNS 时，结果不一定经过系统的 UDP 53 路径。
  • UDP：用实际的语音、游戏或 QUIC 应用检查连接列表。网页通过 TCP 443 打开，并不能证明 UDP 443 可用。
  • IPv6：双栈网络要分别检查 IPv4 与 IPv6。仅配置 IPv4 接管时，部分应用可能优先使用另一条 IPv6 路径。
  • 局域网：测试路由器管理页、打印机和内网域名。需要直连的目的地址应有明确规则，特殊网络还可能需要路由排除。

TUN 开启后断网：按层排查与恢复

现象优先检查处理方向
没有生成虚拟网卡服务、授权、设备访问修复权限后重启内核，查看首条启动错误
有网卡但连接列表为空路由、按应用排除、IPv6核对实际请求是否进入接管路径
域名访问失败DNS 上游、接管、缓存确认解析服务可达，再检查 fake-ip 配置
网页正常，游戏失败节点 UDP 能力与分流检查目标规则，再对比网络栈
切换网络后断网出口接口与旧路由重建 TUN，让内核重新识别出口
局域网设备不可达私网规则、路由冲突、内网 DNS明确直连与排除范围，保留内网解析

恢复时，先在客户端关闭 TUN，再正常退出客户端，检查系统代理是否仍指向 127.0.0.1:7890。如果代理进程已经停止而系统代理仍开启，浏览器可能继续报连接失败，这与残留 TUN 路由是两类问题。

随后恢复此前记录的 DNS，断开再连接当前网络。若路由仍异常，再检查后台服务是否还在运行，必要时重启系统恢复网络状态。不要批量删除不认识的路由或网卡，企业网络、虚拟机和其他 VPN 可能正在使用它们。

需要继续整理配置结构，可查看Clash 配置说明；尚未确定客户端时，可先阅读客户端选型指南，按平台和内核能力选择。