进阶配置 预计阅读 12 分钟

Clash TUN 模式设置

从虚拟网卡与路由表讲起，说明 TUN 模式与系统代理的差别，以及 stack、auto-route、dns-hijack 的配置方式和各桌面平台的开启步骤。

TUN 接管流量的工作路径

Clash TUN 模式通过虚拟网络接口接收 IP 数据包，再由内核识别连接、匹配规则并选择出口。它适合不读取系统代理设置的程序，例如部分命令行工具、游戏和自行建立网络连接的桌面应用。开启前先确认客户端使用的内核支持 TUN；客户端名称相同，并不代表不同发行包具有相同的内核与权限配置。

本文配置以 Clash Meta 后续演进的 mihomo 为基准。原版 Clash、历史 Premium 内核以及其他分支的可用字段可能不同。应先在客户端的内核信息或启动日志中确认实际内核，再按对应文档检查配置；不能仅凭界面存在“TUN”开关判断所有字段都能生效。

  1. 应用发起连接：操作系统根据目标地址查询路由表。
  2. 路由导向虚拟接口：符合接管条件的数据包进入 TUN，而不是直接从物理网卡发出。
  3. 内核执行分流：根据域名、IP、进程等规则，选择代理、直连或拒绝。
  4. 连接抵达出口：代理连接仍需经过真实网络接口，内核必须避免把自己的出站连接再次送回 TUN。

TUN 与系统代理的区别

系统代理通常把 HTTP 或 SOCKS 入口告诉支持这些设置的应用。以本地 127.0.0.1:7890 为例，只有主动使用该入口的连接才会交给内核。TUN 则依靠网络接口和路由工作，应用不必认识这个代理端口。

检查项系统代理TUN 模式
接入方式应用连接本地代理监听端口系统路由把数据包送入虚拟接口
应用适配依赖应用支持系统代理或手动代理通常可以覆盖不读取代理设置的应用
UDP 流量普通 HTTP 系统代理不能直接覆盖可以接管，但出口协议与节点也必须支持
权限要求通常不需要创建网络接口的权限需要创建接口和调整路由的权限
常见冲突应用自带代理、代理环境变量其他 VPN、虚拟网卡、重叠路由和 DNS 接管

“全局流量”是便于理解的描述，不是覆盖保证。已有连接、未被接管的 IPv6 路径、其他 VPN 的优先路由以及特定平台限制，都可能改变实际覆盖范围。先明确要接管哪些应用，再通过连接日志验证，不能只看开关颜色。

首次排查建议关闭系统代理，只启用 TUN，以减少变量。两者可以共存，但同时开启后，浏览器访问成功并不能证明 TUN 正常，因为浏览器可能仍在通过系统代理端口连接。

启用前的三个检查

先确认代理出口可用

先用系统代理完成一次正常访问，确认订阅已导入、策略组有可用节点、规则没有引用不存在的策略名称。节点连接失败、订阅为空或认证错误，不会因为启用 TUN 自动修复。排查时保留原配置备份，每次只调整一类参数。

确认服务权限与网络环境

  • Windows：优先使用客户端提供的服务模式。管理员权限安装服务后，由服务管理内核运行；不必把所有日常应用都提升为管理员。
  • macOS：客户端可能通过辅助程序获得网络管理权限。按系统提示授权，并确认安全软件没有阻止接口创建。
  • Linux：创建 TUN 设备与修改路由通常需要 root 或适当的网络管理能力。容器还需要可访问 /dev/net/tun，仅提升进程权限并不一定足够。

暂时停止其他隧道

先断开其他 VPN、游戏加速器及同类代理客户端。企业 VPN 和虚拟机网络不一定必须关闭，但首次验证时应尽量简化环境。若必须共存，后续需要比较路由前缀与优先级，而不是让两个客户端反复覆盖默认路由。

mihomo TUN 配置示例

下面是合并到现有配置的片段，不是包含节点的完整订阅。保留已有的 proxies、proxy-groups 和 rules。如果原文件已经有 tun 或 dns，应修改原段落，不要在同一层级重复添加同名键。

mixed-port: 7890
mode: rule
log-level: info

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

stack：选择数据包处理方式

mihomo 常见取值为 system、gvisor 和 mixed。system 使用系统网络栈相关实现；gvisor 使用用户态网络栈；mixed 通常将 TCP 交给 system、UDP 交给 gVisor。具体支持情况取决于平台和内核构建。

首次配置可以从客户端默认值开始，示例采用 mixed。只有在复现某类连接故障后再切换栈，并重启内核重测。不同栈不是性能排名，不能把某一种写成所有设备都更快的选择。

auto-route 与出口接口

auto-route: true 让内核自动建立接管所需的路由；它不会替代管理员授权。auto-detect-interface: true 用于自动识别对外连接的接口，帮助代理出站避开自身隧道。Wi-Fi、有线网卡和 VPN 同时存在时，仍应检查识别结果。

如果休眠恢复或切换 Wi-Fi 后才断网，先重启内核，让它重新识别出口，再检查路由。不要立即把物理网卡地址写死到配置里；固定接口名在网络切换后可能失效。

dns-hijack 与 DNS 监听端口

any:53 用于接管进入 TUN 的常规 UDP DNS 请求，tcp://any:53 覆盖对应的 TCP DNS 请求。两者将匹配请求交给内核 DNS 模块，不要求系统 DNS 服务器地址等于 127.0.0.1:1053。

listen: 127.0.0.1:1053 则是 DNS 模块额外提供的本地监听入口。它与 mixed-port: 7890 用途不同，不能把 7890 当作 DNS 端口。应用自带的 DoH、DoT 不属于普通 53 端口 DNS，不能靠这两条劫持规则直接拦下。

Windows、macOS 与 Linux 开启步骤

Windows：先启动服务，再开 TUN

  1. 在客户端设置中确认使用支持 TUN 的 mihomo 内核，并完成订阅连接测试。
  2. 找到服务模式或服务管理入口，按提示安装、启动服务。不同客户端的菜单名称有差异，以当前界面为准。
  3. 启用 TUN，查看日志是否出现权限、接口创建或路由添加错误。
  4. 打开「设置」→「网络和 Internet」→「代理」，暂时关闭手动代理，排除浏览器仍走系统代理的影响。
  5. 用 PowerShell 检查网络接口与 IPv4 路由，再发起一个新连接。
Get-NetAdapter -IncludeHidden
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric
curl.exe --noproxy "*" -I https://example.com/

--noproxy "*" 让这次 curl 请求不使用显式代理，但不会绕过 TUN 路由。示例地址仅用于连接检查；访问成功后，还要在客户端连接列表中确认该请求的规则与出口。部分隧道接口不一定完整显示在网卡列表中，应结合路由和日志判断。

macOS：完成授权并检查路由

  1. 通过客户端的设置入口安装或启用所需辅助程序，完成系统权限确认。
  2. 关闭其他 VPN 后开启 TUN。打开「系统设置」→「网络」，检查是否存在并行启用的网络隧道。
  3. 如果要排除系统代理，在当前网络服务的「详细信息」→「代理」中检查 HTTP、HTTPS 和 SOCKS 代理设置。
  4. 在终端检查接口与路由，再对照客户端连接日志测试。
ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
curl --noproxy '*' -I https://example.com/

macOS 常见虚拟接口名包含 utun，但其他系统服务也会创建这类接口。只看到一个 utun 不能证明它属于当前客户端。需要比较启用前后的变化，以及测试目标实际使用的路由。

Linux：检查设备、权限和策略路由

图形客户端通常会提供提权或服务安装流程。直接运行内核时，先检查配置语法，再通过已配置好的系统服务启动。不要为了快速测试，把普通应用或整个用户目录赋予过宽权限。

mihomo -t -f config.yaml
test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
curl --noproxy '*' -I https://example.com/

mihomo -t 主要验证配置是否能被解析，不会证明运行时已经获得路由权限。Linux 还可能使用策略路由表，仅查看主路由表可能漏掉接管规则，因此需要同时检查 ip rule 和全部路由表。

验证接管、DNS 与 UDP

有效验证需要分层进行。网页能打开，只能说明某一条访问路径可用；它不能证明 DNS、UDP、IPv6 以及所有应用都按预期工作。建议用以下顺序建立证据。

  1. 接口层：启用前后对比虚拟接口与路由，确认没有持续报错。不要要求所有平台都出现完全相同的接口名或默认路由条目。
  2. 连接层：关闭系统代理，用带 --noproxy 的 curl 建立新连接，在客户端连接列表中查到对应请求。
  3. 规则层：核对命中的规则与策略组。命中 DIRECT 是分流结果，不是 TUN 自动失效。
  4. DNS 层：查看 DNS 日志，区分常规 53 端口请求、应用加密 DNS 和已有缓存。
  5. UDP 层：用确实会发起 UDP 的应用测试，同时确认所选节点和协议支持 UDP 转发。TCP 测试成功不能代替 UDP 测试。

使用 Fake-IP 时，部分被接管的域名解析可能返回 198.18.0.0/16 范围中的映射地址。这属于该配置的预期行为，不是网站的真实公网地址。被过滤的域名、使用独立加密 DNS 的应用，以及缓存命中的请求，表现可能不同。

TUN 开启后断网的排查顺序

现象优先检查处理方向
开关立即回落服务状态、接口创建权限、配置解析日志先修复权限或语法错误，再重启内核
域名打不开DNS 上游可达性、DNS 模块与接管日志检查 53 端口请求是否进入内核，换用可达上游
浏览器正常，其他应用失败浏览器是否仍使用系统代理关闭系统代理后重测，核对目标应用连接记录
网页正常，游戏失败UDP 出口能力、策略组、应用错误码换用确认支持 UDP 的节点，逐项定位
连接反复超时其他 VPN 路由、出口接口、代理回环停止竞争隧道，重新识别出口并重启内核
休眠或换网后失效旧接口与旧路由是否仍被使用重启内核，比较恢复前后的路由与日志

遇到局域网打印机、NAS 或路由器管理页失联时，先查看目标私有地址命中的规则。如果被送往代理出口，应按实际网段添加直连规则；如果已经直连仍失败，再检查局域网路由和防火墙。不要直接把所有内网问题归因于 Fake-IP。

调整规则只能解决出口选择问题。若数据包根本没有进入内核，添加域名规则没有作用；若代理节点自身不可达，反复切换 stack 也不能修复节点。建议记录“具体应用、目标、命中规则、错误日志、是否启用其他 VPN”五项信息，再进行下一次修改。

订阅更新与退出恢复

部分客户端把 TUN 开关保存为本地设置，另一些客户端会把界面选项合并进运行配置。编辑订阅文件后，远程更新可能覆盖修改。应使用客户端支持的覆写、合并或持久化配置功能，并在更新后查看实际生效配置，而不是只看编辑器里保存的片段。

停止使用时先关闭 TUN，再正常退出客户端，让内核清理自动建立的路由。若进程异常退出后网络仍不正常，可重新启动客户端，再关闭 TUN 完成清理，同时检查系统代理是否遗留。避免在不清楚来源的情况下批量删除系统路由。

  • 只需要浏览器代理：系统代理通常更容易配置与排查。
  • 需要接管不支持代理的应用：启用 TUN，并验证路由与连接记录。
  • 需要多个 VPN 共存：先明确各自接管的地址范围，再设计规则与路由。
  • 需要进一步定位故障：查看故障排查；基础导入与模式设置见Clash 配置教程。
Clash 客户端下载