TUN 模式是什么？
在 Clash 系客户端里，TUN 模式指的是内核创建一个虚拟网卡（TUN 设备），由操作系统把本机发出的 IP 数据包交给这张「网卡」，再由内核（如 mihomo）按规则引擎决定走代理、直连还是拒绝。与「系统代理」依赖应用主动读取系统 HTTP/HTTPS 代理设置不同，TUN 工作在更底层：只要流量进了路由表、指向 TUN，应用不必支持代理也能被接管——这就是常说的透明代理与系统级流量接管。
实际使用中，TUN 常与 auto-route、auto-detect-interface 等选项配合，由内核自动维护路由，让「需要分流的网段」走虚拟网卡，其余仍走物理网卡。这样你可以在保留局域网与内网直连的同时，对公网访问做精细化分流。若你尚未熟悉策略组与规则写法，可先阅读本站 使用文档 中的基础概念，再回到本文做 TUN 专项加固。
TUN 与系统代理、Mixed Port 有何不同？
系统代理（System Proxy）：操作系统或浏览器把 HTTP(S) 请求交给本地 SOCKS5/HTTP 端口。优点是配置简单、兼容多数桌面浏览器；缺点是许多命令行工具、游戏、UWP/沙箱应用不读系统代理，容易出现「浏览器能上、终端不能上」的分裂体验。
Mixed Port（混合端口）：在同一端口上同时提供 HTTP 与 SOCKS5，便于客户端统一连接，但本质上仍是「应用主动连本地端口」，并未解决「应用不支持代理」的问题。
TUN 模式：在 IP 层拦截或引流，配合策略路由后，更接近「整机会话按规则走 Clash」。适合需要全局一致性的场景：终端、游戏、部分 IDE 与后台服务、以及希望减少逐应用配置成本的用户。代价是需要虚拟网卡权限、路由与 DNS 配置更复杂，排查问题时要同时看「路由表、DNS、规则」三条线。
工作原理简述
开启 TUN 后，内核会在系统中注册一块逻辑网卡，并通常分配一个虚拟网段地址。Clash 从 TUN 读出 IP 包，解析五元组后匹配规则：命中代理则封装后发往上游节点；命中直连则通过指定接口发出；若开启 dns-hijack，DNS 查询也会被导入内核 DNS 模块，与 fake-ip 等模式协同，避免应用绕过代理做「明文 DNS」导致分流失效。
「系统级流量接管」并不等于「所有字节一律出国」。在 Clash 中，最终仍由规则列表决定每一类流量的去向：国内站点、局域网、NTP、部分游戏反作弊域名等，通常应放在直连或过滤列表中。TUN 只是让这些判断对更多应用生效，而不是替代规则本身。
mihomo 配置示例（TUN 段）
以下示例适用于当前主流的 mihomo 内核（原 Clash Meta）。请根据实际网卡与客户端能力微调；首次开启建议先备份 config.yaml。
tun:
enable: true
stack: mixed
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: true
strict-route: truestack：system、gvisor、mixed等表示不同的用户态/内核态转发实现；mixed在多数环境下兼容性与性能较均衡。dns-hijack：将 DNS 查询导入内核，避免应用使用 DoH/自定义 DNS 时绕过策略（需与dns段配合）。strict-route：收紧路由，减轻「本应走代理却从物理网卡溜走」的旁路问题；若遇到局域网异常，可结合规则与排除网段排查。
DNS 与「防泄漏」在 TUN 下的要点
TUN 一开，DNS 往往是第一个出问题的环节：若仍由系统向运营商 DNS 明文查询，可能出现「IP 已分流、域名解析却泄露地理位置」的现象。常见做法是启用内核 dns.enable，使用 fake-ip 或 redir-host（旧式）等模式，并用 fake-ip-filter 把局域网、NTP、游戏等不适合 fake-ip 的域名排除在外。
同时，应为国内域名配置国内 DNS、为境外域名配置加密 DNS 或远程解析，并在 fallback 与 fallback-filter 中做好兜底，避免单次解析失败导致全站不可用。若出现解析循环或开机断网，可暂时改为 enhanced-mode: normal 缩小问题面，再逐项恢复。
各平台权限与注意事项
Windows
通常需要管理员权限或允许安装/加载虚拟网卡驱动。安全软件可能拦截驱动加载，表现为 TUN 开关打开后立即失败或断网。建议从可信渠道安装客户端，并优先通过本站 下载页 获取安装包，避免来路不明的「绿色版」携带旧驱动。
macOS / Linux
macOS 上首次创建 TUN 往往需要用户授权；Linux 下常见做法是为二进制授予 CAP_NET_ADMIN 或使用发行版打包的 systemd 单元。若权限不足，日志里会出现创建 TUN 失败或路由添加失败等提示，可对照内核日志逐项处理。
常见问题排查思路
开启 TUN 后无法上网
先关闭 TUN 恢复网络，再检查：路由是否被 strict-route 收紧后误伤内网；DNS 是否形成环路；规则是否把网关或本机管理地址误送代理。可临时简化规则为「全局直连 + 少量测试规则」验证 TUN 本身是否正常。
只有部分应用仍不走代理
少数应用使用硬编码 DNS、私有协议或绑定物理网卡，可能绕过 TUN。此时需要针对性规则、进程级策略（若客户端支持）或接受其直连，属于正常现象而非配置必然错误。
什么时候用 TUN，什么时候不必？
若你只在浏览器上网，系统代理已足够轻量；若你需要终端、游戏、开发工具与浏览器行为一致，或经常遇到「不跟随系统代理」的应用，TUN 更值得投入学习成本。相比同类工具，成熟维护的 Clash / mihomo 生态在规则集、内核更新与客户端配套上往往更省心：规则可读、社区资料多、问题可复现性强。
把 TUN 当作「流量入口形态」，把规则当作「决策大脑」，两者配合才能得到稳定、可预期的系统级透明代理体验。若你希望少手写 YAML、用图形界面完成订阅、策略组与 TUN 开关的一站式管理，可以选择与 mihomo 深度集成的现代客户端，在稳定性与易用性上通常优于零散工具链的简单拼接。