TUN 模式与系统代理的本质区别
Clash 客户端里常见的「系统代理」和「TUN 模式」并不是两个强弱不同的开关，而是两条不同的流量接入路径。系统代理会把 HTTP 与 HTTPS 代理地址写入操作系统，常见监听地址是 127.0.0.1:7890。浏览器、聊天工具等主动读取系统代理设置的程序，会把连接交给 Clash；忽略系统代理的程序则继续直接联网。
TUN 模式会创建一张虚拟网卡，并在系统路由表中加入相应路由。符合路由条件的 IP 数据包先进入虚拟网卡，再由 mihomo 内核识别目标、匹配规则并决定走代理、直连还是拒绝。因此，TUN 接管的是网络层流量，而不是要求每个应用理解 HTTP 或 SOCKS 代理。
| 对比项 | 系统代理 | TUN 模式 |
|---|---|---|
| 接入位置 | 应用层代理设置 | 虚拟网卡与系统路由 |
| 典型端口 | 混合端口 7890 | 由虚拟网卡接收 IP 包，不依赖应用填写端口 |
| 适用程序 | 浏览器及遵循系统代理的应用 | 启动器、命令行工具、游戏及其他直连程序 |
| UDP 支持 | 取决于应用和代理协议 | 可接管 UDP，但节点与协议也必须支持 |
| 所需权限 | 通常为普通用户权限 | 需要安装服务、网络扩展或授予 VPN 权限 |
哪些情况值得开启 TUN
- 浏览器可以连接，但游戏启动器、商店客户端或桌面应用始终直连。
git、包管理器和其他命令行程序没有读取系统代理。- 应用使用 UDP、QUIC，单纯设置 HTTP 代理无法覆盖。
- 不希望逐个程序填写
HTTP_PROXY、HTTPS_PROXY或 SOCKS5 地址。 - 需要让同一套 Clash 规则统一处理更多本机连接。
如果只是浏览网页，系统代理通常更简单，出现问题时也更容易定位。TUN 会修改路由与 DNS 处理路径，适合确实存在接管需求的场景，不必把它当成安装后的必开项目。
开启前先完成权限与服务准备
以下操作以使用 mihomo 内核的 Clash Verge Rev 2.x 配置结构为例。不同客户端的文字位置会略有变化，但准备工作基本相同：内核需要足够权限创建虚拟网卡、写入路由，并在应用退出或重启后正确清理这些设置。
Windows：安装服务模式
- 退出其他正在运行的 VPN、网络加速器或虚拟网卡工具，避免第一次安装时争抢路由。
- 打开客户端，进入「设置」→「系统设置」→「服务模式」。
- 选择「安装」，在 Windows 用户账户控制窗口中确认管理员权限。
- 安装完成后确认服务状态显示为已运行，再进入「代理」页面开启「TUN 模式」。
- 首次开启后等待约 3 至 10 秒，让虚拟网卡和路由完成初始化。
服务模式让具有管理员权限的后台服务处理虚拟网卡和路由，而图形界面仍可按普通用户方式运行。若安装按钮点击后没有状态变化，先完全退出客户端，再使用「以管理员身份运行」启动一次并重新安装。企业电脑若限制服务安装，需要由设备管理员授权。
macOS：允许辅助程序或网络扩展
- 进入客户端的「设置」→「系统服务」或「服务模式」，选择安装辅助程序。
- 在系统密码或 Touch ID 提示中确认操作。
- 若系统阻止网络组件，打开「系统设置」→「隐私与安全性」，在页面下方允许对应组件。
- 返回客户端开启 TUN；若系统再次询问是否允许添加 VPN 配置，选择允许。
macOS 更新后，旧的辅助程序可能需要重新授权。出现反复要求输入密码、TUN 开关自动回落时，先卸载客户端里的服务模式，重启系统，再从当前版本客户端重新安装。不要同时保留两个 Clash 图形客户端的系统服务。
Android：确认 VPN 连接权限
Android 上的 Clash Meta 类客户端通常通过系统 VPNService 建立本地虚拟网卡。打开「设置」→「网络」→「TUN」后，系统会显示 VPN 连接确认框。确认后，状态栏出现钥匙或 VPN 图标。Android 同一时间只能保持一个 VPN 服务，已有的企业 VPN、WireGuard 或其他代理应用会被断开。
Clash TUN 推荐参数怎么设置
对多数桌面场景，起点可以设为 stack: mixed、auto-route: true、auto-detect-interface: true，并让 Clash DNS 接管 53 端口查询。下面是 mihomo 1.19 系列配置结构可识别的一组基础写法：
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
strict-route: true
dns-hijack:
- any:53
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 223.5.5.5
nameserver:
- https://dns.alidns.com/dns-query图形客户端通常会生成或覆盖其中一部分字段。若客户端已经提供「TUN 堆栈」「自动路由」「DNS 劫持」开关，优先在界面中修改，不要同时编辑订阅生成的只读配置。订阅更新可能覆盖配置正文，而客户端保存的全局覆写通常会继续生效。
堆栈选择：mixed 作为常规起点
| 堆栈 | 特点 | 适用建议 |
|---|---|---|
| mixed | 综合系统与用户态处理路径，兼顾兼容性和性能 | Windows、macOS 的常规首选 |
| system | 更多依赖系统网络栈，资源占用通常较低 | mixed 与特定程序冲突时测试 |
| gVisor | 使用用户态网络栈，隔离和兼容路径不同 | 特定 UDP 或系统栈异常时作为排查选项 |
不要因为某个堆栈名称看起来更高级就频繁切换。先用 mixed 运行，分别测试网页、DNS、下载和需要接管的应用。如果只有某一类连接失败，再依次测试 system 与 gVisor，每次修改后彻底断开并重新开启 TUN。
自动路由与自动识别出口
auto-route: true 会让内核自动写入接管流量所需的路由；auto-detect-interface: true 用于识别当前真实出口网卡。笔记本从有线网络切换到 Wi-Fi，或从家庭网络切到手机热点后，自动识别可以减少把代理连接再次送回 TUN 的概率。
strict-route: true 会加强路由约束，在 Windows 上也有助于减少部分 DNS 请求绕过接管路径。但严格路由可能影响局域网发现、虚拟机桥接或企业内网。若开启后打印机、NAS 或公司网段无法访问，可以先临时关闭 strict-route 对比，而不是关闭整套 TUN。
DNS 劫持为什么常用 any:53
dns-hijack: any:53 表示把被接管流量中的传统 UDP/TCP 53 端口查询交给 mihomo DNS 模块处理。这样域名解析结果与规则判断保持一致，也能减少应用绕过系统 DNS 设置的情况。它不会自动接管应用内置的 DoH，因为 DoH 本质上是发往特定服务器的 HTTPS 流量，需要通过域名或 IP 规则另行处理。
198.18.0.1/16 是 fake-ip 常用地址段。应用查询域名时先获得该范围内的映射地址，内核再根据映射恢复原始域名并匹配规则。局域网设备、打印机域名或少数依赖真实 IP 的应用出现异常时，应把对应域名加入 fake-ip 过滤列表，而不是随意更换为普通公网地址段。
从界面开启到确认接管的完整步骤
- 在「配置」页面更新并选中一份可用配置，确认至少有一个节点可正常连接。
- 将运行模式设为「规则」，避免测试时所有流量被全局策略干扰。
- 进入「设置」→「Clash 设置」→「TUN」，将堆栈设为 mixed。
- 开启「自动路由」「自动识别出口网卡」与「DNS 劫持」。
- 确认服务模式已经安装并运行，然后打开 TUN 主开关。
- 先测试一个遵循系统代理的浏览器，再测试原先无法被系统代理接管的应用。
- 打开客户端连接日志，检查目标域名是否出现，以及最终命中了哪条规则和策略组。
为了确认效果，可以暂时关闭「系统代理」，只保留 TUN。若浏览器和目标应用仍能按照 Clash 规则连接，说明虚拟网卡路径已经工作。测试结束后是否重新开启系统代理取决于客户端实现；mihomo 通常能够同时处理两种入口，但排查阶段一次只保留一种入口更清楚。
Windows 检查虚拟网卡与路由
在 PowerShell 中执行以下命令，可以查看当前网络适配器和 IPv4 路由。不同客户端创建的网卡名称可能包含 Mihomo、Clash 或 Meta：
Get-NetAdapter | Sort-Object Status, Name
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Select-Object -First 20虚拟网卡应处于 Up 状态，路由表中会出现由 TUN 管理的条目。不要仅凭默认路由是否变成虚拟网卡判断成败，因为不同系统和内核版本可能采用分段路由、策略路由或更具体的路由条目。
用日志确认规则而不是只看网页结果
进入「日志」页面，把级别设为 info。启动待测试应用后，应看到目标地址、网络类型和命中策略，例如 TCP、UDP、MATCH、DIRECT 或具体代理组。如果完全没有对应连接，说明流量未进入内核；如果日志存在但显示 DIRECT，则应检查规则顺序；如果已经选择代理却超时，则继续检查节点、UDP 支持或远端服务。
TUN 开启后无法联网的排查顺序
排查时不要同时改堆栈、DNS、节点和规则。按「服务权限 → 虚拟网卡 → DNS → 规则 → 节点」的顺序逐层确认，通常更快找到故障位置。
| 现象 | 优先检查 | 处理办法 |
|---|---|---|
| TUN 开关立即回落 | 服务模式或管理员权限 | 重新安装系统服务，重启客户端后再开启 |
| IP 可以连接，域名打不开 | DNS 模块与 53 端口劫持 | 确认 dns.enable、dns-hijack 和上游 DNS 可用 |
| 网页可用，游戏或语音失败 | UDP、QUIC 与节点能力 | 查看 UDP 日志，测试其他节点或堆栈 |
| 局域网设备无法访问 | strict-route 与私有网段规则 | 测试关闭严格路由，并为局域网网段添加 DIRECT |
| 休眠恢复后断网 | 出口网卡变化和残留路由 | 关闭再开启 TUN，必要时重启系统服务 |
| 只有某个应用失败 | 应用内置 DNS、IPv6 或证书策略 | 查看该应用连接日志，单独测试 IPv4 与 UDP |
第一步：确认基础配置和节点本身可用
关闭 TUN，开启系统代理，用浏览器测试当前节点。如果此时也无法连接，问题不在虚拟网卡，应先处理配置、策略组或节点状态。TUN 只改变流量进入内核的方式，不会修复失效节点。
第二步：区分 DNS 故障与路由故障
域名失败但已知 IP 可以访问，通常优先检查 DNS。客户端日志中如果没有 DNS 查询，检查 dns.enable 和 53 端口劫持；有查询但上游超时，则更换可达的上游 DNS，并确认用于解析代理服务器域名的引导 DNS 可以直连访问。
如果域名能解析，但 TCP 连接完全不出现在日志中，更可能是路由没有写入、虚拟网卡未启动，或流量被另一个 VPN 提前接管。此时先退出其他 VPN 和网络过滤工具，再关闭、开启一次 TUN。
第三步：处理局域网与虚拟机网络
常见私有地址包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。家庭路由器、NAS 和打印机通常应匹配 DIRECT。规则需要放在兜底 MATCH 之前，例如：
rules:
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,节点选择虚拟机和容器网络也可能使用这些地址段，因此不能机械地把全部私有地址排除在 TUN 之外。若需要代理虚拟机内部流量，应先确认流量实际经过宿主机哪张网卡，再决定使用 DIRECT 规则、路由排除还是在虚拟机内部单独配置代理。
性能、IPv6 与长期使用建议
TUN 增加了一层虚拟网卡与用户态处理，但日常网页和下载的速度通常更受节点延迟、线路拥塞、协议和远端服务器限制。评估性能时应使用同一个节点、同一个目标文件，分别测试关闭和开启 TUN 的结果，每组至少运行三次。只比较一次测速容易受到缓存和瞬时线路波动影响。
出现高 CPU 占用时，先把日志级别从 debug 调回 info，停止持续连接测试，再观察具体进程。大量 UDP 会话、P2P 软件和频繁 DNS 查询都可能明显增加连接数量。桌面客户端的连接页面可用于找到异常活跃的程序。
IPv6 不要在不确认网络条件时强开
如果本地网络、代理节点和规则集都已正确支持 IPv6，可以启用对应处理；如果运营商只提供不稳定的 IPv6，可能出现应用优先尝试 AAAA 地址后等待超时。排查时可暂时关闭 Clash 配置中的 IPv6，再比较相同目标的连接时间。不要为了修复单个站点直接在整个操作系统里永久禁用 IPv6。
保留一套可回退配置
- 记录当前可用的堆栈类型、DNS 模式和 strict-route 状态。
- 客户端或 mihomo 内核更新后，先确认服务模式仍处于运行状态。
- 订阅更新后检查策略组名称，避免本地规则指向已经不存在的组。
- 修改 YAML 前先使用客户端的配置检查功能，缩进统一使用空格。
- 遇到断网时先关闭 TUN；若网络立即恢复，再按本文顺序逐项排查。
TUN 的关键不是把更多开关全部打开，而是让权限、路由、DNS 和规则形成完整链路。先确认虚拟网卡成功建立，再通过日志判断流量有没有进入内核，最后检查命中的规则与出口。按照这条顺序处理，浏览器能用而桌面程序不通、开启后域名失效、局域网设备消失等问题都能被拆成明确的检查步骤。