为什么开了代理仍会「漏流」？
很多用户第一次接触 Clash 系客户端时，会自然地打开「系统代理」，然后发现：浏览器访问正常，某些软件却像没事发生一样直连出去。这并不是你的订阅突然失效，而是系统代理本质上是一种「约定」：操作系统把 HTTP 与 HTTPS 的代理参数告诉「愿意遵守」的应用。浏览器、部分 Electron 应用通常会读取；但游戏启动器、自研网络库、部分国产办公软件、以及大量命令行工具，可以完全不理会这些变量。
另一种常见情况是：应用表面上走了代理，但解析域名阶段仍使用系统 DNS，导致解析路径与连接路径不一致，表现为「时好时坏」「只有个别站点异常」。这类问题也不能单靠勾选系统代理解决。要理解 TUN 模式的价值，就要先接受一个事实：「端口监听 + 系统代理」覆盖的是「协作的应用子集」，而不是操作系统里所有 IP 报文。
TUN 模式在做什么？
TUN（网络隧道）在用户态与内核之间插入一个虚拟网卡。启用后，符合条件的 IP 数据包会先被路由到这张虚拟网卡，由 Clash / Mihomo 内核接收，再按你的规则决定直连、走某个策略组、或丢弃。对上层应用来说，它仍然像平常一样发起 TCP/UDP 连接；差异在于报文离开本机网卡之前，已经被内核路由层「截胡」并交给代理栈处理。
这与「应用自己把流量送到 7890 端口」完全不同：后者依赖应用实现；前者依赖操作系统路由表与防火墙策略（不同平台细节不同）。因此，在权限允许、路由未冲突的前提下，TUN 能覆盖到更多「不听话」的程序，显著减少漏流。需要强调的是，TUN 解决的是本机出站路径；若你关心的是 DNS 泄露、WebRTC、或浏览器指纹等议题，仍需要规则、DNS 模式与浏览器侧设置协同，而不是单靠一个开关。
TUN 与系统代理：要不要同时开？
实践上常见三种组合：仅系统代理（轻量、兼容性好，但漏流多）、仅 TUN（覆盖面大，需关注权限与路由）、两者都开（部分环境可避免个别应用异常）。没有放之四海皆准的答案。若你主要使用浏览器且不希望动系统路由，系统代理往往足够；若你玩游戏、用远程开发工具、或需要终端与图形程序行为一致，TUN 通常更值得打开。
同时开启时，若出现环路、双倍延迟或偶发断流，优先检查是否把代理进程自身或局域网段错误地送进了代理策略。合理的规则会在最前面放行本机、局域网与上游 DNS，再处理其余流量。关于规则维护，可参考本站《Rule Providers 规则集进阶教程》，用远程列表降低手写错误率。
DNS 与 TUN：缺一不可的搭档
只开 TUN、不处理 DNS，仍可能出现「连接走了代理，解析却在 ISP」的割裂。Mihomo 系内核通常提供 dns 段、fake-ip 与 redir-host 等模式，与 rules 中的 GEOSITE、DOMAIN-SUFFIX 等条目共同决定何时由内核代理解析、何时直连。若你使用 fake-ip，要确保规则中相关域名匹配顺序正确，避免把本应直连的 CDN 误送入代理。
建议在调整 TUN 的同时，打开客户端日志观察 DNS 查询是否按预期命中；若发现大量 NXDOMAIN 或异常回退，先核对你是否混用了第三方「优化 DNS」软件、公司安全客户端、或路由器上的强制 DNS。它们可能与 TUN 栈争抢解析路径。更系统的 DNS 与文档入口见使用文档中对应平台章节。
启用前：平台权限与心理准备
Windows 通常需要安装或授权虚拟网卡驱动（如 Wintun），并以管理员权限运行相关服务；企业版若开启严格组策略，可能拦截驱动安装。macOS 需在「隐私与安全性」中允许网络扩展或系统扩展，首次启用会弹窗说明。Linux 需具备创建 TUN 设备的能力（capabilities 或 root），不同发行版对 NetworkManager 与 iptables/nft 的集成程度不同，冲突时表现为能 ping 不能浏览、或仅部分网段异常。Android 上常见形态是 VPN 服务通道，与桌面 TUN 在实现上接近，但受系统省电与后台限制更大。
若你刚升级过内核或更换订阅格式，建议先阅读《Clash Meta（Mihomo）核心升级指南》，确认 tun 相关字段与当前版本一致，再开启虚拟网卡，避免「旧配置键被静默忽略」。
在客户端里如何打开 TUN？
具体菜单位置随版本变化，但思路一致：在「内核配置」或「高级设置」中找到 tun 或「虚拟网卡 / 增强模式」开关，启用后观察是否出现新接口（名称常含 utun、Meta、Wintun 等）。Clash Verge Rev 类桌面客户端一般在设置页提供 TUN 开关与堆栈选项；FlClash 在移动端与桌面端也可能以 VPN 或 TUN 形式呈现。无论哪一款，启用后都建议重启一次客户端，并清空系统里冲突的旧代理工具，避免多栈并存。
配置文件中，tun: 下常见字段包括 enable、stack、auto-route、strict-route、dns-hijack 等。GUI 勾选往往会写入等价 YAML；若你手写，请严格缩进并与官方模板对齐。错误缩进会导致整段被解析器跳过，表现为「界面显示已开，实际未创建网卡」。
stack 是什么？gVisor 与 system 怎么选？
Mihomo 系内核常见的 stack 取值包括 system、gvisor、mixed 等（以你当前版本文档为准）。简要理解：system 更依赖操作系统网络栈，性能往往更好，但与个别环境兼容性略挑剔；gvisor 在用户态实现较多网络逻辑，隔离性强，有时能解决奇怪的分片或 QUIC 问题，但 CPU 占用可能更高；mixed 试图在二者间折中。若你不确定，可先用客户端默认；遇到特定游戏或视频会议卡顿，再尝试切换 stack 并对比日志。
切换 stack 后若完全无网，优先回滚配置并检查路由是否残留；Windows 下可借助 route print，Unix 系可用 netstat -rn 观察默认路由是否指向异常接口。
排错清单：从「无网」到「部分漏流」
| 现象 | 优先检查 | 处理思路 |
|---|---|---|
| 开启 TUN 后整机无法上网 | 路由环路、DNS 劫持未放行、或 strict-route 与本地网段冲突 | 暂时关闭 TUN 恢复网络；核对 dns-hijack 与规则前几条是否放行局域网与本机 |
| 仅浏览器正常，其它仍直连 | 实际未创建 TUN 或权限不足 | 查看内核日志是否报错；Windows 确认 Wintun；macOS 确认扩展授权 |
| 能打开网页但游戏高延迟 | UDP 策略、stack 兼容性或节点本身不适合游戏 | 尝试切换 stack；为游戏进程或相关域名单独写规则；换低延迟节点 |
| 间歇性解析失败 | fake-ip 与规则顺序、或第三方 DNS 冲突 | 简化 DNS 链；对照日志调整 DOMAIN 规则优先级 |
哪些情况不必强开 TUN？
在公共电脑、无管理员权限、或公司明确禁止虚拟网卡的环境中，强行安装驱动可能违反策略。低配路由器上若运行 Clash 作为旁路由，TUN 的角色由网关改写承担，终端侧未必再需要重复开启。又如你仅做轻量网页浏览，系统代理已满足需求，则不必为了「心理安全感」额外增加一层路由复杂度——每多一层拦截，就多一层排错成本。
小结
TUN 模式的价值，在于把「谁走代理」从应用自觉升级为内核路由层面的统一调度，从而显著减少漏流与行为不一致。它与 DNS 模式、规则顺序、以及客户端权限密不可分：缺一环节，就可能出现「看似开了全局，实际仍有死角」的体验。相比单纯反复切换节点，先理顺 TUN、DNS 与规则三者的关系，往往更能从根本上改善稳定性。
若你希望客户端版本、下载来源与内核能力一一对应，减少「配置正确却加载失败」的折腾，可从本站客户端下载页获取适配当前系统的安装包，再按本文步骤开启 TUN 与核对 DNS。相比零散渠道，统一来源能降低版本错配带来的隐性成本。