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

Clash TUN 模式是什么:虚拟网卡接管全局流量的原理与开启步骤

从虚拟网卡与路由表讲起,说明 TUN 模式为何能接管不走系统代理的程序,并给出 stack、auto-route、dns-hijack 的开启与排错方法。

TUN 模式：在 IP 层接收应用流量

TUN 是一种虚拟网络接口。操作系统把符合路由条件的 IP 数据包交给这个接口，代理内核读取数据包，再根据目标地址、域名与规则决定直连或交给代理节点。它与系统代理的区别，首先在于接收流量的位置，而不是节点速度。

系统代理通常告诉应用：HTTP 或 SOCKS 代理位于某个地址，例如 127.0.0.1:7890。浏览器可能遵循此设置，命令行工具、游戏或自带网络栈的程序却不一定遵循。TUN 依靠系统路由引流，因而能接收一部分不读取系统代理设置的程序流量。

一条连接经过哪些环节

应用请求域名解析，取得真实 IP 或由内核分配的 Fake-IP。
应用建立 TCP 或 UDP 连接，系统查询路由表，选择虚拟接口。
TUN 协议栈处理数据包，内核恢复连接信息并执行规则匹配。
内核通过物理网卡建立直连或代理连接，返回数据再送回应用。

这里的“全局流量”应理解为系统级引流能力，不是覆盖所有网络空间的保证。显式绑定物理接口的程序、虚拟机内部网络、容器网络、被排除的网段，以及未被接管的 IPv6 路由，都可能走其他路径。局域网广播与二层发现协议也不能简单视为普通 TUN 代理流量。

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

下文配置以支持这些字段的 mihomo 内核为对象。Clash 原版、历史 Premium 内核与 mihomo 的 TUN 能力和字段并不完全一致；客户端名称也不能直接代表内核类型。先在客户端的内核信息、关于页面或启动日志中确认核心名称与实际版本，再查阅对应版本的字段说明。

Windows：创建虚拟接口和修改路由通常需要管理员权限。部分客户端通过已安装的服务执行这些操作，普通权限启动图形界面也能使用。
macOS：通常需要客户端提供的特权辅助程序或相应授权。不要把允许访问本地网络误当作已经获得路由修改权限。
Linux：需要可用的 /dev/net/tun 与相应网络管理权限；容器中的设备映射和权限还要单独配置。
Android：一般由客户端通过系统 VpnService 建立接口。桌面端的管理员或服务模式步骤不能原样套用；同时运行其他 VPN 往往会产生竞争。

先导出当前可用配置，并确认订阅更新会不会覆盖修改。客户端若支持覆写配置、合并配置或配置扩展，应在该机制中保存 TUN 设置。编辑订阅生成的临时文件，可能在下一次更新或重启后失效。相关通用字段可在配置参考中对照。

最小配置：先验证接管，再接入代理策略

下面是一份用于桌面环境排查的完整最小配置。它将所有连接设为直连，目的是验证虚拟接口、路由与 DNS 是否工作，不是提供可用代理节点。7890 是本例的混合代理端口，1053 是本地 DNS 监听端口；两者职责不同。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

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
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - MATCH,DIRECT

示例 DNS 上游使用普通 DNS，便于拆分故障，不提供加密传输；应按所在网络的可达性与隐私要求调整。ipv6: false 是缩小初次排查范围的设置，不等于关闭操作系统 IPv6，更不保证其他程序不会通过系统 IPv6 路径联网。

stack：协议栈选项不是速度档位

字段值	处理方式	选择要点
`system`	使用系统协议栈方案处理连接。	可作为兼容性对照，具体行为依平台实现而定。
`gvisor`	使用用户态网络协议栈。	遇到连接兼容问题时可与其他方案交叉测试。
`mixed`	TCP 使用 system，UDP 使用 gVisor。	适合作为支持该选项的 mihomo 版本的起点。

不要把某个 stack 理解为所有机器上都更快。操作系统、内核版本和业务流量会改变结果。测试时只修改 stack 一项，重启内核并重新建立连接；已有长连接不适合用来判断切换效果。

auto-route 与 auto-detect-interface

auto-route: true 让内核自动配置把流量导向 TUN 的路由；它不是代理规则开关。auto-detect-interface: true 用于自动选择出站接口，帮助代理连接从真实网络出口发出，避免重新进入 TUN 形成回环。

多网卡、其他 VPN、企业专线和虚拟交换机同时存在时，自动检测未必选中期望出口。先检查路由和接口，再考虑按当前内核支持的 interface-name 等字段指定出口。不要复制其他电脑上的接口名，Wi-Fi 与有线网络切换后接口也可能变化。

DNS 接管：dns-hijack 与 Fake-IP 的关系

dns-hijack 把进入 TUN 且匹配目标的 DNS 流量交给内核 DNS 模块。示例中的 any:53 对应 UDP 53，tcp://any:53 对应 TCP 53。它们不表示拦截一切名称解析方式，也不是把所有流量改到本地 1053 端口。

传统 DNS：通常使用 UDP 53，响应过大或某些场景会使用 TCP 53。
DoT：通常使用 TCP 853，不会因为匹配 53 端口而自动被解析接管。
DoH：通常通过 HTTPS 443，浏览器“安全 DNS”可能绕过传统 DNS 接管；连接本身仍可能进入 TUN。

Fake-IP 模式下，内核可向应用返回映射地址，例如 198.18.0.2，并在后续连接中利用映射找回域名。这有助于域名规则匹配，但不意味着该地址是网站服务器的真实 IP。示例使用的 198.18.0.1/16 是映射地址池，不应作为普通公网目的地址去测试可达性。

部分局域网服务或应用会自行校验解析结果，这时可能需要按实际问题配置 fake-ip-filter，让特定域名返回真实地址。不要直接排除所有域名，否则会改变整个 DNS 工作方式。切换 Fake-IP 与真实 IP 解析后，重启测试应用并清理旧 DNS 缓存，避免应用继续使用旧映射。

开启步骤：按依赖顺序验证

先验证基础网络：关闭 TUN，确认当前网络可用；如已有代理配置，先通过系统代理验证节点和策略组可用，避免把节点故障误判成虚拟网卡问题。
处理权限：按客户端提供的方式启用服务或完成系统授权。Linux 先确认 /dev/net/tun 存在；不要只观察界面的开关颜色。
保存配置并重载：先通过配置检查，再启动内核。查看启动日志是否出现虚拟接口创建失败、权限不足或字段解析错误。
临时关闭系统代理：排除浏览器依靠旧代理设置联网的干扰。TUN 与系统代理可以并用，但首次验证应把路径分开。
建立新连接：退出并重新打开测试应用，观察客户端连接列表中的目标域名、目标 IP、网络类型与命中规则。
恢复业务规则：最小直连配置验证后，再使用原有代理组与规则，分别检查直连和代理连接的出口。

如果客户端启动时会自动重新开启系统代理，应再次核对开关。应用自己保存的 SOCKS 设置、终端环境变量 HTTP_PROXY 与 ALL_PROXY 也会改变测试路径，不能仅凭系统代理已关闭就认定连接一定来自 TUN。

查看路由与解析结果

以下命令用于读取状态，不能直接修复问题。观察开启前后的接口与路由差异，路由可能由多条分段规则或策略路由组成，不一定表现为一条默认路由被替换。

# Windows：在 PowerShell 中执行
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Resolve-DnsName example.com

# macOS：在终端中执行
ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

# Linux：同时查看主路由与策略路由
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

解析测试返回 Fake-IP，只能证明某次解析进入了相应 DNS 路径，不能证明应用连接已正确代理。完整验证应同时观察连接记录和出口：确认新连接进入内核、命中期望规则、使用期望策略，再用目标服务的实际访问结果核对。

常见故障：按接口、路由、DNS、出口排查

开关已启用，但没有虚拟接口

优先检查服务是否运行、授权是否完成、启动日志是否报错，以及实际运行配置里是否包含 tun.enable: true。图形界面的开关可能被配置覆写，也可能因为核心启动失败而没有落实。此时更换 DNS 通常无助于解决问题。

开启后所有应用断网

先关闭 TUN 恢复网络，再检查其他 VPN、出站接口选择和 DNS 上游可达性。若日志反复出现相同目标的连接，需警惕路由回环。不要同时调整 stack、DNS、MTU 和规则；保留一份可复现配置，每次只改变一个因素。

如果域名访问失败但已知 IP 的连接正常，重点检查解析路径。反过来，DNS 能返回结果而连接超时，应检查路由、策略与节点。直接用 IP 打开 HTTPS 网站可能因证书或虚拟主机机制失败，不能把这种失败单独当作网络断开的证据。

浏览器正常，游戏或语音仍失败

先看失败连接是否进入内核。若已进入且属于 UDP，再确认代理协议、所选节点和服务端是否支持 UDP 转发。TUN 能接收 UDP，并不意味着每个代理出口都支持 UDP。浏览器可能回退到 TCP，所以网页可用不能证明游戏链路可用。

局域网设备、打印机或企业资源不可访问

检查目标是否为私网地址，以及是否与其他 VPN 或路由网段重叠。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 是策略层的直连规则示例，但直连仍可能经过 TUN 接收流程。若需要从路由层排除某网段，应核对当前内核的路由排除字段；这与增加一条 DIRECT 规则不是同一操作。

关闭后仍无法恢复网络

优先正常退出客户端，让内核清理虚拟接口和路由，再检查系统代理是否仍指向已经停止监听的 127.0.0.1:7890。必要时重新连接网络或重启系统。不要在不了解企业路由用途时批量删除路由表条目。

何时需要 TUN，何时只用系统代理

如果只是浏览器访问，系统代理通常更容易观察和排查。遇到不遵循系统代理的应用、需要统一处理更多 TCP 与 UDP 连接，或希望按系统级路径应用规则时，再考虑 TUN。它增加的是接管能力，同时也引入权限、路由和 DNS 的配置责任。

保留 mode: rule，让本地与代理流量按规则分开处理。
用连接记录确认接管，用命中策略确认分流，不以开关状态代替验证。
升级核心、更换网络或新增 VPN 后，重新检查接口、DNS 与路由。
只有确认存在分片或路径 MTU 问题时才调整 MTU，不把固定数值当作通用优化。

TUN 配置的检查顺序可以固定为：接口存在、路由生效、解析正常、规则正确、出口可达。按这个顺序逐层验证，比在多个开关之间反复切换更容易定位故障。