2026-10-14 进阶配置预计阅读 12 分钟

Clash TUN 模式原理与开启步骤:让全局流量走内核

解释虚拟网卡接管流量的原理,对比系统代理与 TUN 的覆盖范围差异,并给出各平台开启 TUN、配合 Fake-IP 与 auto-route 的具体设置。

TUN 接管流量，不等于所有连接都走代理

Clash TUN 模式在系统中建立虚拟三层网络接口，并通过路由把符合条件的 IP 数据包交给内核。内核读取目标地址、端口及可用的域名信息，再按规则选择 DIRECT、代理节点或其他策略。浏览器之外，不读取系统代理设置的命令行工具、游戏和部分桌面应用，也能进入同一套规则处理流程。

标题中的“全局流量”指接管范围，不是客户端的 Global 模式。开启 TUN 后仍可使用 Rule 模式：局域网连接直连，指定域名走代理，其余连接由末尾的 MATCH 决定。路由排除项、应用自带的 VPN、其他网络命名空间和部分系统流量，都可能处于接管范围之外。

系统代理与 TUN 的覆盖差异

检查项	系统代理	TUN
流量入口	应用主动连接 HTTP 或 SOCKS 代理端口	系统路由把 IP 数据包送入虚拟网卡
应用支持	依赖应用读取设置或手动配置代理	通常不要求应用支持代理协议
UDP 流量	常见系统 HTTP 代理设置不能覆盖	可接管，但代理节点和协议也必须支持 UDP
权限要求	通常只需修改用户代理设置	需要创建网卡、设置路由或调用系统 VPN 接口
DNS 路径	可能仍由应用或系统自行解析	可配合 DNS 劫持和内核 DNS，但需单独验证

TUN 也不是网络加速开关。节点拥塞、UDP 不通或规则命中错误，不会因为换成虚拟网卡而消失。先确认同一节点通过普通代理可以连接，再扩大接管范围，更容易区分节点问题与本机路由问题。

开启前：确认内核、权限与配置来源

下文 YAML 面向支持这些字段的 mihomo，也就是 Clash Meta 后续使用的内核名称。不同年代的 Clash 内核、移动端封装和图形客户端，配置能力并不完全相同。不能只看到客户端名称里有 Clash，就认定整段参数都能直接使用。

记录当前内核。在客户端的“关于”或“内核”信息页保存版本字符串；遇到 unknown field、unsupported stack 等报错时，先对照该版本支持的字段，不要反复切换节点。
备份有效配置。保留当前配置文件以及规则模式、DNS、TUN 设置的截图。需要回滚时先关 TUN，再恢复原设置。
确认修改入口。订阅配置可能在更新时被覆盖。优先使用客户端提供的覆写、合并配置或 TUN 设置面板；直接编辑订阅缓存文件往往只能临时生效。
暂时退出其他 VPN。先建立单一接管路径。企业 VPN、加速器和另一款 TUN 客户端同时改默认路由，会让故障位置变得不明确。

首次测试可关闭系统代理，仅保留 TUN，减少浏览器仍经由旧代理端口连接的干扰。这是为了验证接管效果，并不是说系统代理和 TUN 必然不能同时使用。测试完成后，再按客户端建议决定是否同时开启。

mihomo 配置：TUN、Fake-IP 与 auto-route

下面是合并到现有配置的顶层片段，不是完整订阅。保留已有的 proxies、proxy-groups 与 rules；如果原文件已有 dns 或 tun，应合并对应内容，不要重复创建同名顶层键。示例使用 mixed-port 7890，DNS 监听 127.0.0.1:1053；两者用途不同。

mixed-port: 7890
mode: rule

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:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

每个字段解决什么问题

stack: mixed：在支持该值的 mihomo 中组合使用系统与用户态网络栈。若当前客户端不支持，按其内核文档选用 system 或 gvisor，不要把切换栈当成通用修复。
auto-route: true：由内核自动设置流量进入 TUN 所需的路由。它不替代管理员权限，也不能保证覆盖所有外部 VPN 路由。
auto-detect-interface: true：尝试识别实际出站接口，避免代理出站再次进入 TUN。双网卡、热点和企业 VPN 环境仍需检查识别结果。
dns-hijack：把进入 TUN 且命中目标的普通 53 端口 DNS 请求交给内核 DNS。示例分别覆盖 UDP 与 TCP 的 53 端口请求。
enhanced-mode: fake-ip：返回虚拟地址，并在内核中保存域名映射。连接这些地址时，内核可恢复域名并进行分流。

198.18.0.1/16 属于基准测试用途地址空间，不是真实网站出口。查询得到这类地址是 Fake-IP 的预期表现。若所在网络也使用这一网段，应先排查地址冲突；不能把虚拟地址当作普通公网 IP 写入固定直连路由。

Fake-IP 过滤与加密 DNS 的边界

fake-ip-filter 中的域名采用真实地址应答，但这并不自动把连接改成 DIRECT。局域网服务仍需在规则中正确分流。示例中的 *.local 也不会替代 mDNS 的多播发现机制；打印机或投屏发现失败，还要检查本地网络权限和多播路径。

浏览器自带的 DoH 通常通过 443 端口发送，DoT 常用 853 端口，两者不会被上述 53 端口劫持直接接管。诊断时可暂时关闭浏览器“安全 DNS”和 Android“私人 DNS”，先测试系统 DNS 路径，再决定长期使用哪一套解析策略。

各平台开启 TUN 的操作顺序

Windows：先安装服务，再开启虚拟网卡

导入配置并选择 Rule 模式，先通过系统代理确认节点可用。
在客户端设置中寻找“服务模式”入口；如提供安装服务按钮，按提示完成管理员授权。没有服务模式的客户端可能需要以管理员身份运行。
开启标为“TUN 模式”或“虚拟网卡”的开关。菜单名称由客户端决定，不要把“系统代理”开关当作 TUN。
查看日志中是否出现虚拟网卡创建、路由设置成功的信息；随后关闭系统代理进行单独验证。

可运行 route print 检查路由。接口名和路由前缀会随内核及系统版本变化，不必强求出现某个固定网卡名称。若日志提示 access denied 或 operation not permitted，应先修复权限或服务状态，而不是修改 DNS 地址。

macOS：确认辅助服务和路由权限

在支持 TUN 的客户端中安装其要求的辅助服务，再开启 TUN。若系统弹出网络扩展或后台服务授权提示，应核对应用名称后批准；并非所有客户端都使用相同授权机制。切换 Wi-Fi、以太网或热点后，需要重新确认出站接口是否正确。

终端可用 netstat -rn 查看路由，用 scutil --dns 查看系统解析器。系统可能同时存在多个 utun 接口，看到 utun 本身不能证明 Clash 接管成功，仍需结合客户端连接记录判断。

Linux：区分网卡设备与网络管理权限

确认 /dev/net/tun 存在；自动设置路由通常需要相应网络管理权限，例如通过受控服务获得 CAP_NET_ADMIN。不要为了启动成功而给整个桌面客户端长期开放不必要的高权限。容器环境还需要显式开放 TUN 设备和相关权限，宿主机能使用不代表容器内也能使用。

使用 ip rule、ip route show table all 和 resolvectl status 分别检查策略路由、各路由表与解析状态。只看主路由表可能漏掉内核创建的策略路由。

Android 与 iOS：使用系统 VPN 授权

Android 上支持此能力的客户端通常通过 VpnService 接管流量。点击连接后批准系统 VPN 请求，并检查“分应用代理”是否排除了待测应用。电池后台限制可能导致锁屏后连接中断；始终开启 VPN 与“阻止不使用 VPN 的连接”则属于额外系统策略，应在基础连接稳定后再启用。

iOS 与 iPadOS 上应选择支持相应配置格式的客户端，通过系统 VPN 配置授权启动网络扩展。不能照搬桌面端安装驱动或获取管理员权限的步骤。移动端应用可能自行管理路由和 DNS，甚至忽略桌面 tun 字段，应以其配置支持范围为准；系统 VPN 已连接，也不代表订阅里的所有规则都兼容。

验证接管：分别检查入口、DNS 与出口

一次打开网页只能证明某条连接可用，不能证明 TUN、DNS 和规则都按预期工作。按下面的顺序测试，每次只改变一个条件，记录应用、目标域名、命中规则和实际出口。

测试不带代理参数的应用。关闭系统代理，清除终端的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量，再运行下面的命令。连接应出现在客户端记录中。
测试内核 DNS。查询本地 1053 端口，确认返回结果。未被过滤的普通域名在 Fake-IP 模式下通常得到 198.18 网段地址。
测试系统 DNS。直接运行系统默认解析查询，并结合日志观察是否经过内核。直接查询 1053 成功，只能证明 DNS 监听器工作，不能证明系统请求已被劫持。
检查规则出口。分别访问预期直连和预期代理的目标，核对连接记录中的规则与策略组。不要把“进入内核”误判为“使用代理节点”。

# Windows PowerShell：先确认当前会话没有代理环境变量
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
curl.exe --noproxy "*" -I https://example.com
nslookup example.com

# macOS / Linux：curl 的 --noproxy 绕过显式代理，不绕过 TUN
curl --noproxy '*' -I https://example.com
dig @127.0.0.1 -p 1053 example.com A
nslookup example.com

若工具没有安装，不必为完成命令而改动系统，可用客户端 DNS 查询功能替代。测试 UDP 时，应选择已确认支持 UDP 的节点和应用场景；普通 HTTPS 网页成功不能说明游戏 UDP 或 QUIC 已经可用。

常见故障：按权限、路由、DNS 顺序排查

现象	优先检查	处理方向
开启后立即断网	服务权限、出站接口、其他 VPN	先关闭 TUN 恢复网络，再查看启动日志及路由错误
IP 可连，域名失败	DNS 上游可达性、53 端口接管	分别测试本地 1053 和系统 DNS，定位失败环节
浏览器可用，游戏不通	UDP 支持、分应用排除、规则命中	核对连接记录，再测试节点 UDP 能力
局域网设备无法访问	私网路由、DIRECT 规则、地址冲突	先对实际局域网网段配置直连，确认是否还需路由排除
睡眠或切网后失效	默认接口是否改变、后台服务状态	重新连接 TUN，并检查接口识别与 DNS 状态

strict-route 不适合一开始就盲目叠加

部分 mihomo 配置支持 strict-route，用于加强路由约束，在某些平台也会影响 DNS 路径。它可能改变局域网、虚拟机或其他 VPN 的可达性。先用最小配置验证，再根据当前内核文档和实际需求添加；不能把它理解为“代理更彻底”的通用选项。

退出后仍无法联网时怎样恢复

先在客户端内关闭 TUN，让内核正常撤销路由，再退出客户端。检查系统代理是否仍指向已经停止监听的 127.0.0.1:7890，同时检查 DNS 是否残留手动设置。随后重连网络；必要时通过客户端的服务修复入口恢复。企业设备上不要直接清空整张路由表，以免删除办公网络所需配置。