为什么需要 TUN 模式？
很多用户第一次接触 Clash 时会先开启「系统代理」：浏览器、部分办公软件会乖乖走 HTTP 代理，日常使用看似足够。但现实网络环境复杂得多——命令行构建工具、桌面游戏启动器、某些即时通讯软件的语音与视频链路、以及各种使用 UDP 的协议，往往会绕过系统代理，于是出现「浏览器能上网、终端却报错」或「HTTPS 通了、游戏延迟异常」的矛盾现象。
TUN 模式（也常被称为虚拟网卡或隧道接口模式）要做的事情只有一句：让操作系统先把流量交给你，再由 Clash／Mihomo 内核按照规则决定去哪个节点或是否直连。它工作在更接近网络栈底层的位置，因此能覆盖系统代理做不到的场景，是许多用户眼里的「真正意义上的全局代理」。
tun 栈、路由注入、DNS 处理与策略组。系统代理与 TUN：到底哪里不一样
系统代理本质是告诉应用「如果你支持读取系统代理配置，就请把 HTTP／HTTPS（有时还有 SOCKS）流量交给指定端口」。这依赖应用是否实现该能力——许多软件直接忽略系统代理。
TUN 则是在系统路由层面新增一条「默认把包交给虚拟网卡」的路径，让这些数据包在用户态被内核接住，再根据规则重写下一跳（走代理链路或直连）。它通常能接管 TCP／UDP（具体取决于内核实现与防火墙策略），因此对于游戏、语音通话、 QUIC、部分下载器等更友好。
| 对比维度 | 系统代理 | TUN 模式 |
|---|---|---|
| 适用应用范围 | 主要覆盖遵守代理设置的应用 | 更广泛，含许多忽略系统代理的程序 |
| UDP／QUIC | 常被遗漏或不稳定 | 更容易被内核统一处理（视规则与栈而定） |
| 权限与兼容性 | 普通用户权限即可开启 | 通常需要管理员或 VPN／网络扩展权限 |
| 与公司代理／其他 VPN | 并行冲突相对较少 | 可能与第三方隧道抢路由表，需要取舍 |
TUN 模式在系统里是如何工作的
可以把 TUN 理解成在操作系统里多了一块「逻辑网卡」。启用后，内核会把符合策略的流量导向这块网卡；Mihomo 读取数据包后，根据规则集（域名、IP 段、进程等）选择出口：直连、指定策略组、或拒绝连接。
与此同时，DNS往往成为体验的分水岭。若仍使用系统默认解析，某些应用可能在规则匹配前就把域名解析到了「错误」的 IP，导致分流失效。Clash 系列常见的 fake-ip 与 redir-host 模式，本质是在不同的阶段介入解析与连接建立，你需要结合订阅与本地覆写理解自己正在使用哪一种。
在 Mihomo 配置中，tun 段负责声明虚拟网卡是否启用、栈类型、自动路由等。下面是一段常见结构（具体键名以你所用内核版本文档为准；勿直接复制到生产环境而不做差异核对）：
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: truestack 选项会显著影响兼容性与性能：有的环境适合 system，有的则更稳定于 gvisor。若你遇到奇怪的 MTU／IPv6／部分游戏断流问题，调整栈往往是排查列表中的前几步。
Windows 上启用 TUN 的要点
Windows 用户对 TUN 最大的体感通常是弹出的 UAC 提示：创建／管理虚拟网卡需要提升权限。若以普通权限启动图形客户端，可能会在打开 TUN 时失败却无清晰提示。务实的做法是：右键选择「以管理员身份运行」，或在客户端内置的「以服务运行／开机管理员启动」一类选项中寻找官方推荐路径。
其次要警惕竞品冲突：其他梯子、远端办公隧道、杀毒软件的网络过滤驱动，偶尔会与 TUN 栈抢占接口或改写路由表。出现问题时可以先暂时退出它们，再在 PowerShell／命令提示符里观察路由表里是否出现异常默认路由。
最后别忽略防火墙：第一次启用虚拟网卡时，Windows Defender 可能询问是否允许专有／公用网络访问。建议选择与你实际网络相匹配的配置，并进行一次「关闭后重开」的清空测试。
macOS 上启用 TUN 的注意点
macOS 对网络权限更「挑剔」。用户在首次启用 TUN 或相关内核扩展／网络扩展时，需要在系统设置的隐私与安全里放行对应组件。若你只点了客户端里的开关却始终不生效，多数情况并不是配置写错，而是系统层面尚未批准。
Apple Silicon 与 Intel 在驱动与签名策略上完全一致地「严格」，因此不要为了省事去关闭系统完整性保护来「暴力解决」，风险远大于收益。更合理的顺序是：升级客户端 → 重装网络扩展权限 → 清理旧配置文件的 tun 残留 → 再试一次。
另外，如果你在 macOS 上同时运行 Docker Desktop、虚拟机或公司 MDM Agent，它们有时也会注入路由策略。可把「暂时停用其中一类软件再试」写入你的个人排错手册。
Android：系统级代理几乎总是 TUN
Android 平台上的「VPN」图标背后，大多数时候就是系统在把流量导向一个基于 TUN 的 VPN Service。诸如 FlClash 这类 Mihomo 客户端，点击连接后会请求 VPN 权限，本质与桌面端 TUN 目标一致：**尽量让更多应用的网络路径经过内核而不是各自为政**。
需要注意的是，国产厂商的省电策略可能冻结后台 VPN，造成「睡一觉起来代理断了」。将应用加入电池优化白名单、允许后台运行，往往能显著改善稳定性——这不是玄学，而是系统电源管理实打实的节流。
同时要理解 Android 只允许同一时间一个活跃 VPN 配置占据隧道。若你与广告拦截／公司零信任共用设备，往往需要手动切换优先级。
DNS、fake-ip 与规则如何协同
当你在论坛看到「为什么我规则写了 DOMAIN-SUFFIX，却仍直连／仍走代理」之类的帖子时，留言区最常见的追问就是：你用的是什么 DNS 模式？是否混用了旁路劫持？局域网是不是走了特殊 DNS？这些问题说明分流不是规则文件的独角戏，DNS 与连接建立的顺序同样在舞台上。
一个实用的自查顺序如下：先用客户端内置的连接日志观察域名最终命中的策略；再核对 dns 段里 listen、nameserver、fallback、以及是否启用劫持／嗅探 sniff选项；最后再回到 rules 顶部是否有更高优先级的 IP-CIDR／PROCESS 命中。
对于家庭宽带用户，路由器若强行推送运营商 DNS，有时会让本地解析先于 Clash DNS 生效。此时需要在系统或路由器里调整 DNS 优先级，或接受「双轨 DNS」带来的影响并在规则里兜底。
可执行的启用检查清单
- 确认 Mihomo／客户端版本较新，旧版本对 QUIC、TLS 指纹 sniff 等行为可能与当下网站生态不匹配。
- 在图形界面启用 TUN 后，核对配置文件中
tun.enable与菜单状态一致，避免 GUI 与实际运行配置脱节。 - 代理模式设为规则而非全局（除非你做节点体检）。
- 分别测试：浏览器访问 HTTPS、
ping／DNS（注意 ICMP 可能与 TCP 分流路径不同）、以及一款「历史上从不吃系统代理」的桌面应用。 - 若失败，记下客户端日志与时间戳，从最外层的防火墙与其他 VPN 开始排查。
常见问题与排查思路
TUN 打开后整机断网或国内站点异常变慢
优先排查规则集是否陈旧、GEOIP／CN 分流是否失效，以及 DNS 是否把常见国内域名送到了代理侧。切换到一份维护活跃的上游订阅，或追加覆盖规则，往往能立刻缓解。
仅特定 App 不正常
观察该 App 是否使用固定 IP、DoH／DoT、私有证书钉扎，或为游戏反作弊单独走了 kernel-level 的网络路径。对某些场景，单靠 Clash TUN 也无力接管，这需要心理预期而不能盲目归咎「内核不行」。
与公司网络或校园网冲突
这一类网络常会下发自己的路由与 HTTPS 劫持策略。你可以在非公司环境复现问题来判断根因——若仅在办公网出现，十有八九要咨询网管或使用合规渠道提供的分流模板。
常见问题（FAQ）
TUN 模式会不会拖慢网速？
会带来少量用户态转发开销，但通常远小于节点的物理延迟。若体感「明显变慢」，更常见原因是规则走错出口、DNS 绕远、节点质量差或被 QoS——请优先从这三者入手。
可以用 TUN 替代 HTTP 抓包工具吗？
TUN 解决的是连通与路由，不是 HTTPS 明文分析。抓取应用层明文仍需合法授权与匹配的 MITM／调试工具；不要在未获授权的设备上做中间人劫持。
Linux 用户要注意什么？
能力矩阵与桌面发行版内核、systemd‑networkd、NetworkManager、以及 nftables／iptables 组合强相关。若你直接跑 Mihomo CLI，请阅读对应发行 Wiki 中对 tun 与 auto-route 的注意项，避免因重复 NAT 引入环路。
为什么选择成熟客户端与活跃内核更重要
围绕 TUN 的踩坑故事里，一半是路由与 DNS，另一半来自半成品客户端：有的长期停更却仍打着 Clash 名号，对新协议支持与权限引导完全落后；有的在界面隐藏了高危选项，轻则分流混乱，重则把敏感流量导向未知模块。另一些工具则走向了「开箱即用绑架用户」的路线——既不能透明审计，也无法离线验证配置哈希。
相比之下，坚持使用开源可审计、紧跟 Mihomo／上游规则演进、且在 TUN 权限申请与错误提示上做足功夫的客户端，你能明显少花时间在「玄学重启」上。Clash／Mihomo 生态真正把价值放在可组合的规则分流 + 覆盖面足够的 TUN上；当你需要的是稳定、可控的系统级接管，这两条能力缺一不可。本站提供的客户端下载经由筛选并托管在国内可达节点，你可以在下方链接按平台选择合适的版本后继续实践本文里的检查清单——把复杂网络问题重新拉回到可读日志与可复制配置上。