Clash TUN 模式开启教程:虚拟网卡接管全局流量的原理与设置

TUN 与系统代理：接管位置不同

浏览器可以访问，终端、游戏或某个桌面程序却连不上，常见原因是应用没有读取系统代理。系统代理主要告诉支持它的应用：把请求交给指定的 HTTP 或 SOCKS 入口。应用自行建立连接、忽略代理设置，或者使用不受该入口覆盖的 UDP 通信时，仅打开系统代理通常不够。

TUN 在系统中建立三层虚拟网络接口，再通过路由把符合条件的 IP 数据包送入内核。mihomo 接到数据后，根据目标地址、域名信息和规则决定直连或代理。因此，应用通常不需要单独填写代理地址，但内核必须具备创建接口和修改路由的权限。

对比项	系统代理	TUN 模式
接管入口	应用使用代理协议连接监听端口	系统路由把 IP 包送入虚拟接口
应用适配	需要应用支持或手动配置	通常不要求应用识别代理设置
权限	通常无需创建网卡权限	桌面端通常需要管理员、root 或受权服务
UDP	取决于应用与代理入口	可接管，但代理节点和协议也须支持
覆盖边界	未使用代理的连接可能绕过	受路由、排除项、IPv6 和其他 VPN 影响

开启前：先确认内核、节点与恢复方式

“Clash 客户端”是界面名称，不代表内置内核一定相同。本文 YAML 面向 mihomo，不应直接当作所有原版 Clash 或旧 Premium 内核的通用配置。先在客户端的“关于”或“内核信息”中确认实际内核；独立运行时可以查看版本输出：

mihomo -v
mihomo -t -f config.yaml

第二条命令检查配置能否被当前内核解析，不会证明节点可用或路由正确。若命令提示找不到程序，应使用实际可执行文件路径；Windows PowerShell 中，当前目录的程序通常写作 .\mihomo.exe。

保留当前可用配置和覆写文件。订阅更新可能覆盖直接写进订阅文件的修改，应优先使用客户端提供的合并或覆写功能。
先在系统代理模式下确认节点可用。至少测试一次网页访问；需要游戏、语音或 QUIC 时，再确认节点提供 UDP 能力。
暂停其他 VPN、加速器和旧代理内核。首次测试不要让两套工具同时修改默认路由。
记录关闭 TUN 的入口。远程管理服务器时，先准备控制台或其他恢复通道，避免路由变化中断唯一的 SSH 会话。

mihomo TUN 基础配置与字段含义

下面是添加到现有可用配置中的顶层片段，不是一份含节点和策略组的完整订阅。已有 tun 或 dns 段时应合并字段，不要重复添加同名顶层键。首次验证只处理 IPv4，确认链路后再单独检查 IPv6。

mode: rule
log-level: info
ipv6: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - 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

这里的两个 DNS 地址仅用于展示普通 DNS 上游写法，需根据所在网络可达性调整；普通 DNS 查询不是加密传输。已有成熟的 DNS 分流与节点域名解析配置时，应保留原有设计，不要整体替换成这个入门片段。

字段	作用与检查点
`enable`	请求启动 TUN；是否成功还要看权限、接口和日志。
`auto-route`	自动设置把流量送进 TUN 的路由，不代表所有排除路径都消失。
`auto-detect-interface`	自动识别实际出站网卡。多网卡或其他 VPN 存在时需核对结果。
`dns-hijack`	示例捕获进入 TUN 的目标端口 53 的 UDP DNS；不等于截获所有加密 DNS。
`listen`	本地 DNS 监听地址；1053 是示例端口，不是要求系统 DNS 填写的端口。
`fake-ip-range`	分配用于域名映射的地址，应用拿到这些地址后仍须经内核处理。

198.18.0.1/16 所在地址空间用于基准测试，不是远端网站真实 IP，也不是普通公网节点地址。若应用缓存了 Fake-IP，关闭内核后仍继续使用缓存，可能暂时无法访问；关闭相关应用并清理 DNS 缓存后再测。

stack 怎么选：system、gvisor、mixed

system：主要利用系统网络栈处理连接。适合先按客户端推荐值测试，但具体表现取决于操作系统和网络环境。
gvisor：使用用户态网络栈。遇到特定应用兼容问题时可作为对照方案，但不能直接推导出更快或更稳定。
mixed：TCP 使用 system 路径，UDP 使用 gVisor 路径。它是混合处理方式，不是同时运行两份代理配置。

不同平台和内核版本对 stack 的支持与限制可能不同。修改后先做配置检查，再看启动日志。不要一次同时切换 stack、DNS 上游和节点，否则即使恢复访问，也很难判断是哪项变更生效。

Windows：先让内核获得创建网卡的权限

退出其他代理客户端，确认当前节点在普通系统代理下可以使用。
若客户端提供服务模式，按其界面安装并启动服务；若没有服务模式，可在信任程序来源的前提下，以管理员身份启动客户端进行一次验证。
在客户端的 TUN 设置中启用虚拟网卡接管，再查看日志是否出现接口创建成功、路由设置成功或明确的失败原因。不同客户端菜单命名并不统一，不要仅凭开关颜色判断成功。
按 Win + R，运行 ncpa.cpl 查看网络适配器；接口名称由客户端或配置决定，不一定叫 Clash。

验证时先关闭客户端的系统代理开关，只保留 TUN，以免浏览器仍经系统代理访问而掩盖 TUN 故障。可到 Windows 11「设置」→「网络和 Internet」→「代理」核对手动代理状态；受单位管理的设备不要擅自更改组织策略。

route print
ipconfig /all
curl.exe --noproxy "*" -I https://example.com

route print 用于观察路由，不要求一定出现一条指向 TUN 的传统默认路由：实现也可能通过更具体的网段完成接管。测试时同时看客户端连接列表，确认该请求进入内核并命中预期策略。单独收到 HTTP 响应只能证明目标可达，不能证明它走了代理节点。

macOS 与 Linux：检查授权、路由和 DNS

macOS 开启步骤

使用支持 mihomo TUN 的客户端，按界面提示安装或授权其辅助服务。普通用户进程通常不能直接完成所有网络配置操作。
启用 TUN 后查看日志，再在终端执行 ifconfig 和 netstat -rn。系统中可能已有多个 utun 接口，看到一个 utun 并不能单独证明它属于当前客户端。
到「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」，核对是否还保留旧的手动代理。具体入口文字会随系统版本变化。
关闭系统代理，使用未设置显式代理的应用发起新连接，在内核连接列表中交叉确认。

若网页正常、局域网设备却无法访问，先检查局域网流量命中的规则和路由，再判断是否需要调整排除网段。不要把整个内网代理失败误判成 DNS 故障。

Linux 开启步骤

Linux 通常需要 root 或相应网络管理能力，并要求系统提供 TUN 设备。先检查 /dev/net/tun 是否存在；容器和精简系统还可能限制设备访问，即便进程以 root 运行也不一定能创建接口。

ls -l /dev/net/tun
mihomo -t -f config.yaml
sudo mihomo -f config.yaml

# 在另一个终端检查
ip link
ip rule
ip route show table all
resolvectl status

前台启动便于观察第一次失败发生在哪一步。长期运行应使用受控的服务配置；不要为了排障给整个目录中的程序批量赋予权限。resolvectl 适用于使用 systemd-resolved 的系统，其他发行版需检查实际 DNS 管理方式。

Android 与 iOS：使用系统 VPN 授权

Android 客户端通常通过系统 VPN 接口实现接管。首次连接时确认 VPN 授权，再检查客户端的应用排除或分应用代理设置。被排除的应用不会因为 TUN 开关已打开就自动进入规则流程。Android「设置」→「网络和互联网」→「VPN」可查看当前连接，厂商系统的入口可能位于“连接与共享”。

Android 在同一用户或资料空间中通常只能维持一个活动的 VPN 服务，本地防火墙、广告过滤工具和其他 VPN 可能争用这个入口。若配置“始终开启 VPN”或“阻止未使用 VPN 的连接”，关闭客户端前先了解其断网行为。Android 的私人 DNS 使用加密通道，也不能假定已被端口 53 劫持规则覆盖。

iOS 应使用支持相应配置的客户端，并通过系统 VPN 授权建立隧道。在「设置」→「通用」→「VPN 与设备管理」中核对状态。iOS 客户端未必使用 mihomo，也未必接受上述 YAML 字段；应以该应用的配置格式为准，不能把桌面配置原样导入当作通用步骤。

DNS、IPv6 与 UDP：三个容易漏掉的验证点

端口 53 劫持不覆盖 DoH、DoT

示例中的 any:53 处理普通 UDP DNS。DNS over TLS 通常使用 TCP 853，DNS over HTTPS 通常走 HTTPS 的 443 端口，两者都不会仅因这条配置就自动变成内核 DNS 查询。排障时可暂时关闭浏览器的安全 DNS进行对照，确认后再决定最终解析方案。

测试时应分别检查“域名能否解析”和“连接是否进入内核”。例如 nslookup example.com 可以帮助观察解析结果，但不能证明某个浏览器采用相同的解析路径。域名规则是否匹配，还取决于内核能否获得该连接对应的域名信息。

关闭 AAAA 返回不等于禁用系统 IPv6

示例中的 IPv6 设置用于简化初次诊断，不是系统级防绕过保证。应用仍可能使用缓存的 IPv6 地址、IP 字面量或其他解析器。需要 IPv6 时，应一起核对内核 IPv6 设置、TUN 路由、DNS 返回以及节点能力；不需要时，也应检查系统是否仍有未覆盖的 IPv6 路径。

UDP 接管成功也需要可用的出站

语音或游戏失败时，先看连接列表是否出现对应 UDP 会话，再检查规则选中的节点是否支持 UDP。浏览器的 QUIC 也使用 UDP，网页能通过 TCP 回退打开，不代表 UDP 链路正常。不要用一次网页测速替代游戏、语音应用本身的验证。

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

现象	优先检查	下一步
打开后立即关闭	配置解析错误、服务未启动、权限不足	运行配置检查，查看首条接口创建错误。
开启后全部断网	出站接口误选、其他 VPN 冲突、节点不可达	关闭 TUN 恢复网络，再仅保留一个接管工具。
IP 可达但域名失败	DNS 上游不可达、监听冲突、解析路径未接管	核对 1053 监听和 DNS 日志，不要先更换所有规则。
网页正常但游戏失败	UDP 出站、规则策略、应用排除项	检查 UDP 会话及其实际选中的节点。
切换 Wi-Fi 后失败	出站接口和路由未随网络变化更新	重启 TUN 会话并查看重新识别的物理网卡。
关闭后仍无法上网	残留系统代理、路由、Fake-IP 缓存	先退出客户端，再核对代理与路由，最后清缓存。

怀疑 MTU 时再单独调整。典型表现是小请求正常、大响应或特定网站卡住，但这也可能来自节点或链路问题。可记录原值后对照测试 mtu: 1400；这个数字只是诊断起点，不是所有宽带、移动网络和 VPN 叠加场景的最优值。

确认为 DNS 缓存问题后，Windows 可执行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可执行 sudo resolvectl flush-caches。清缓存不能替代恢复错误路由，也不能解决节点失效。排查结束后把临时调试日志恢复到 info，分享日志前移除订阅地址、令牌和其他敏感信息。

完成标准：用一条连接串起验证链

关闭系统代理和应用内显式代理，发起一个全新的连接。
在内核中找到该连接，核对目标、TCP 或 UDP 类型、命中规则及出站策略。
分别测试一个应直连的目标和一个应代理的目标，避免只测单一网页。
检查局域网访问、网络切换与关闭 TUN 后的恢复情况。

这四步通过后，才能说明接管、规则和出站基本连通。后续再增加 IPv6、应用排除或更细的路由设置，每次只改一项并保留回退记录。字段的延伸说明可查看配置大全中的 TUN 配置与DNS 配置。