TUN 模式解决什么问题
普通的系统代理依赖应用主动读取操作系统中的代理设置。浏览器、部分下载工具和常见桌面应用通常可以按此方式把 HTTP 或 HTTPS 请求交给 Clash，但游戏启动器、命令行程序、独立更新器以及自行实现网络栈的应用可能直接连接目标地址。此时，即使系统代理开关已经打开，这些连接也不会经过 Clash。
TUN 模式会创建一个虚拟网络接口，并向操作系统写入相应路由。符合路由条件的 IP 数据包先进入虚拟接口，再由 Clash 或 mihomo 内核识别连接目标、执行规则匹配并选择直连或代理出口。它处理的是网络层流量入口，因此覆盖范围通常比系统代理更广。
“TUN 接管”和 Clash 的“全局模式”不是同一个设置。TUN 决定流量能否进入内核；规则、全局、直连等运行模式决定进入内核之后怎样选择出口。开启 TUN 后仍然可以使用规则模式，让国内地址直连、指定域名走代理，也可以临时切换全局模式进行排查。
虚拟网卡接管流量的实际路径
应用发起连接后，操作系统先查询本机路由表。TUN 启用且自动路由生效时，客户端会增加指向虚拟接口的路由，同时保留局域网、默认网关和必要系统地址的可达路径。数据包到达 TUN 接口后，内核恢复连接信息，并把目标交给规则引擎处理。
- 应用请求域名解析，DNS 查询进入系统解析器或 Clash DNS 模块。
- 操作系统根据路由表把目标连接发送到虚拟网卡。
- Clash 根据域名、目标 IP、端口、进程信息或规则集进行匹配。
- 命中的策略组选择具体代理节点或直连出口。
- 出站连接通过真实网卡发送，返回数据再沿虚拟接口交还应用。
这条路径中，DNS 与路由必须保持一致。如果域名由外部 DNS 直接解析，而规则又依赖域名分类，内核可能只能看到解析后的 IP，导致预期的域名规则未命中。使用 mihomo 的 Fake-IP 增强模式时，DNS 模块会为域名返回一个受控的虚拟地址，并在内部保存域名与连接的映射。应用连接该地址时，内核能够恢复原始域名，再执行域名规则。
Fake-IP 不是所有环境的固定选择。局域网设备发现、某些游戏、企业内网域名和依赖真实地址判断的程序可能需要加入排除列表，也可以在客户端支持时改用 Redir-Host。选择方式应以域名规则识别是否稳定、局域网服务是否可达为准。
开启前检查内核、订阅与权限
先确认客户端使用的内核支持 TUN。当前常见的 mihomo 内核提供 TUN、自动路由、接口自动检测和多种协议处理能力，但不同图形客户端暴露的开关名称不完全一致。有些客户端把 TUN 放在“设置”或“服务模式”中，有些则要求先安装系统服务。已经停止更新的旧客户端可能携带较早内核，配置字段和操作系统兼容性也会不同。
一、更新并加载有效订阅
TUN 只改变流量入口，不会修复失效节点。开启前先手动更新订阅，确认当前配置已经加载，并在策略组中选择可连接的节点。可以先用系统代理测试浏览器访问：若普通代理也无法建立连接，应先检查订阅地址、节点状态、策略组选择和本机网络。
二、准备系统权限
创建虚拟网卡和修改路由通常需要较高权限。Windows 客户端可能要求安装服务组件或以管理员权限完成首次设置；macOS 会显示网络扩展或 VPN 配置授权；Android 客户端通常通过系统 VPN 接口接管流量，并弹出 VPN 连接确认。授权完成后，应回到客户端检查 TUN 状态，而不是只依据系统弹窗判断。
三、记录原有网络设置
开启前记录正在使用的 VPN、虚拟机网卡、公司安全客户端、DNS 工具和默认网关。多个程序同时修改默认路由或 DNS 时，后启动的一方可能覆盖前一方。排查时需要一次只保留一个流量接管工具，确认基础链路后再逐项恢复其他程序。
Clash TUN 模式开启步骤
不同客户端的界面名称存在差异，但执行逻辑基本一致。以下顺序适用于使用 mihomo 内核的常见桌面客户端。若客户端提供图形开关，优先通过界面修改；直接编辑 YAML 前应确认客户端不会在保存设置时覆盖该段配置。
- 启动客户端并更新当前订阅，确认配置文件没有解析错误。
- 在代理或策略组页面选择一个可连接节点，保持运行模式为“规则”。
- 进入设置页，找到 TUN、虚拟网卡或流量接管相关选项。
- 若界面要求安装服务模式、辅助服务或网络扩展，先完成安装和系统授权。
- 开启 TUN，并启用自动路由；支持接口自动检测时可以一并开启。
- 检查客户端状态区，确认 TUN 已运行，而不是停留在“等待授权”或“启动失败”。
- 关闭系统代理进行一次覆盖测试，观察原本不读取代理的应用是否仍能按规则连接。
用于说明字段关系的 mihomo 配置片段如下。实际可用字段取决于客户端内置内核版本，图形客户端生成的配置应以其界面和日志为准。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 8.8.8.8enable 控制 TUN 是否启动；auto-route 让内核自动添加所需路由；auto-detect-interface 用于识别当前真实出站接口；stack 决定 TUN 数据包使用的网络栈实现。部分客户端会提供 system、gVisor 或 mixed 等选项，支持情况随平台和内核版本变化。通常先使用客户端默认值，只有遇到特定 UDP、性能或兼容问题时再切换。
示例中的公共 DNS 仅用于展示字段结构。实际环境可使用本地网络允许访问的解析服务，或按订阅与客户端说明配置 DoH、DoT。关键点是 DNS 请求应能稳定到达解析器，并与规则匹配链路保持一致。
按 DNS、路由和规则验证接管结果
开关显示为启用不代表所有链路都已经正常。验证应分层进行，先看客户端日志，再看 DNS 和路由，最后检查具体应用。这样可以区分是虚拟网卡没有启动、规则选错出口，还是目标应用自身限制。
检查客户端日志
启动 TUN 后查看日志中是否出现权限不足、接口创建失败、路由写入失败或端口占用。随后打开目标应用，日志应出现对应连接记录。完全没有记录，通常表示流量没有进入 TUN；有记录但连接失败，则继续检查规则命中、节点状态和 DNS。
检查域名解析
执行一次系统 DNS 查询，观察是否能够返回结果。Fake-IP 模式下，部分普通域名可能返回配置范围内的虚拟地址，这是映射流程的一部分，不代表目标服务器的真实地址发生变化。如果所有域名都超时，应检查 DNS 监听、上游解析器、防火墙以及其他 DNS 软件。
检查规则命中
在连接列表或日志中找到测试域名，确认它命中了预期规则和策略组。规则模式下，最终规则通常会承担未被前面规则匹配的连接。如果最终规则指向直连，那么即使 TUN 已接管，相关连接仍会从本地网络直接发出。
分别测试 TCP、UDP 与局域网
浏览器访问主要验证 TCP 和 DNS，不能覆盖所有场景。还应测试需要 UDP 的应用，并访问路由器管理地址、打印机或局域网服务。若外部连接正常但局域网不可达，应检查局域网地址是否被自动路由错误接管，以及客户端是否提供绕过私有地址的设置。
| 观察结果 | 优先检查 | 处理方向 |
|---|---|---|
| TUN 启动后立即关闭 | 权限、服务组件、虚拟网卡 | 重新授权并检查启动日志 |
| 应用连接没有日志 | 自动路由、默认接口、其他 VPN | 恢复单一接管工具后重建路由 |
| 日志有连接但域名超时 | DNS 监听与上游解析 | 检查 DNS 配置及防火墙规则 |
| 浏览器正常，游戏失败 | UDP、网络栈、游戏进程规则 | 查看 UDP 日志并测试其他栈 |
| 外部网络正常，局域网失联 | 私有地址路由、接口选择 | 调整局域网绕过与自动路由 |
常见冲突与恢复顺序
TUN 异常多发生在权限、DNS、路由和应用冲突四个层面。处理时应保持固定顺序，不要直接重装客户端。每完成一步就重新测试，并观察日志是否发生变化。
TUN 已开启但设备无法联网
先关闭 TUN，确认基础网络能够恢复。随后检查所选代理节点和最终规则。如果直连与代理都失败，再查看 DNS 是否被设置为当前不可达的地址。基础网络恢复后，重新启动客户端并启用自动路由；若仍失败，暂时退出其他 VPN、虚拟机网络管理工具和独立 DNS 程序。
重启或切换网络后失效
从有线网络切换到 Wi-Fi、连接热点或唤醒设备后，默认出口接口可能变化。启用接口自动检测可以减少手动配置，但客户端仍可能需要重建 TUN。先关闭再开启 TUN，确认新默认网关已被识别。频繁切换网络的设备还应避免在配置中固定已经不存在的接口名称。
局域网设备无法访问
打印机、NAS、路由器管理页通常使用私有地址或本地域名。检查规则中是否允许这些地址直连，并确认路由没有把局域网流量错误送到代理出口。域名类局域网服务还可能依赖本地 DNS 或组播发现，必要时将对应域名加入 Fake-IP 排除项，并保留本地解析链路。
部分应用循环连接或登录异常
先从连接日志确认目标域名和出口。如果应用依赖真实 IP、局域网回环或特殊 UDP 行为，可以针对该域名或进程建立更精确的直连规则。规则应放在宽泛规则之前，避免被较早的域名后缀或规则集提前匹配。调整后重新建立连接，旧连接不会总是自动应用新策略。
关闭客户端后网络没有恢复
先确认客户端进程和服务均已退出，再关闭系统代理或 VPN 配置。操作系统通常会清理由客户端创建的临时路由；若异常退出后仍有问题，可以禁用再启用真实网卡，或重启系统以重建网络状态。恢复基础网络后再启动客户端，不要在残留状态下连续切换多个接管工具。
TUN、系统代理与运行模式怎样组合
只使用浏览器和明确支持代理设置的桌面程序时，系统代理配置简单，排查范围也较小。需要接管游戏、终端工具、商店应用或其他不读取系统代理的软件时，再启用 TUN。某些客户端允许系统代理与 TUN 同时开启，但这不意味着必须同时使用；测试阶段可以关闭系统代理，仅通过 TUN 判断覆盖效果。
日常使用通常选择“TUN 接管 + 规则模式”。TUN 负责把流量送入内核，规则模式负责按域名、地址和规则集分流。全局模式适合短时间判断某个失败是否由规则造成，但长期保持全局模式会跳过精细分流逻辑。直连模式则可以用于确认应用在本地网络下是否能够访问目标。
移动设备上的 TUN 往往通过系统 VPN 接口实现，同一时间通常只能保持一个系统级 VPN 连接。因此，开启 Clash 类客户端后，另一个 VPN 应用可能被断开。桌面系统虽然可能同时存在多个虚拟接口，但默认路由、DNS 和接口优先级仍会互相影响，稳定方案通常是明确一个主要接管工具。
启用后的完整检查清单
- 订阅已更新，当前配置能够正常加载。
- 策略组已选择可用节点，规则模式下最终规则符合预期。
- 系统服务、网络扩展或 VPN 权限已经完成授权。
- TUN 状态显示运行中，日志没有接口创建或路由写入错误。
- DNS 查询能够完成，域名规则可以识别并命中。
- 关闭系统代理后，不读取代理设置的应用仍能产生连接日志。
- TCP、UDP、局域网访问分别完成测试。
- 网络切换或设备唤醒后，默认出口接口仍能被正确识别。
- 其他 VPN、虚拟机和 DNS 工具不会重复修改当前路由。
- 关闭 TUN 与退出客户端后，基础网络能够恢复。
完成以上检查后，TUN 链路可以拆成清晰的四段：系统权限负责创建虚拟接口，路由负责把数据包送入内核，DNS 提供可供规则识别的目标信息，策略组决定最终出口。出现问题时按这四段逐项定位，比反复重装配置或连续切换节点更有效。