Clash TUN 模式完全指南：开启全局代理，彻底处理应用不走代理难点

为什么「开了代理」仍有应用不走？ 一文看懂

TUN 模式（在 Clash / Mihomo 语境下也常称透明代理或虚拟网卡模式）的思路不同：在操作系统里创建一个虚拟网络接口，把符合策略的 IP 层流量引入内核，再由 Mihomo 按规则决定直连还是进节点。对应用而言，它仍然像平常一样连通 IP 与端口，只是路由表与防火墙策略被调整，让更多流量必须经过 Clash 这一跳。

不少运用者第一次接触 Clash 系客户端时，会先在设置里开启「系统代理」：由客户端把 Windows 或 macOS 的系统 HTTP/HTTPS（有时含 SOCKS）指到本机某个端口。浏览器、部分商店客户端会读取这些变量，于是上网「看起来已经翻墙成功」。

但现实中大批程序根本不查系统代理：命令行工具、游戏、语音与视频会议、某些下载器、企业定制软件，通常干脆发起原生套接字连接。还有若干环境会显式设置 NO_PROXY 或内置直连列表。于是你会遇到经典现象：浏览器正常，而某个 App 仍然直连或仍然连不上目标服务。

先看这一点：另一类高频状态是 UDP：系统代理路径核心服务基于 TCP 的 HTTP(S)；即便配置了 SOCKS5，也要看应用是否真正走 SOCKS、以及内核与规则是否对 UDP 做了无误转发。游戏、QUIC、部分 DNS 查询若未进入代理管道，就会表现为「规则写了但没用」。

TUN 模式在做什么：从「应用自觉」到「路由兜底」 核心要点

这也带来两个干脆后果。第一，TUN 一般得更高权限：创建 TUN 设备、改路由、在 Windows 上常配合服务或管理员能力，在 Android 上则表现为系统级的 VPN 通道。第二，失误配置时「影响面」也更大——若规则或 DNS 有漏洞，也许出现全机断网或环路，排查要对照日志逐步收缩范围。

能够把系统代理理解成「在应用门口贴告示：请走这个端口」；而 TUN 更接近「在小区路口改指示牌：要去外网先经过收费站」。后者不依赖每个司机是否看告示，所以覆盖面大得多。

技术上说，启用 TUN 后，内核会把特定目标地址的数据包交给 Clash 创建的用户态隧道接口。Mihomo 收到后再解析连接意图，匹配 rules 与 proxy-groups，与平常 Rule 模式下的逻辑一致，只是入口从「应用主动连本地 Mixed 端口」变成了「网卡层截获」。

系统代理、TUN 与 Mixed 端口怎样配合？ 逐条拆解

更齐全的客户端操作操作操作界面与权限说明，可对照本站 Clash Verge Rev 运用指引 中的代理模式章节，与这篇文章 TUN 部分互为补充。

补充说明：多数图形客户端会同时提供：系统代理开关、TUN 开关、以及本地 Mixed / HTTP / SOCKS 入站端口。两者不是互斥条目，而是不同入口。

典型推荐是：Rule 模式 + 按需开启 TUN，让国内外分流在规则层完成；浏览器既可走系统代理，也可走 SwitchyOmega 指到本地端口。若你暂时不想动路由表，能够只用系统代理处理浏览器，等遇到「某个软件死活不走代理」再开 TUN。

若同时开启系统代理与 TUN，要留意避免重复劫持或环路：比如让「连通 Clash 控制面或订阅域名」的流量被失误地再送进代理链。高频做法是在规则里为本地回环、LAN、以及内核元数据地址保留直连或单独策略，具体名称因订阅而异，但思路一致。

开启 TUN 之前：先确认这四件事 底层逻辑

1. 内核与客户端版本充分新：旧版 Core 对 TUN、ebpf、部分 DNS 行为兼容不齐全，升级后再试一般比盲目改规则更有效。
2. 当前配置能正常 Rule 上网：在仅系统代理模式下，先确认节点与规则无硬伤，再开 TUN，避免把「节点挂了」误判成「TUN 坏了」。
3. 关闭冲突软件：另一款 VPN、公司全局代理、某些「网络优化」驱动也会改路由；同时跑起来时容易出现抢路由、DNS 被覆盖等难点。
4. 备份当前网络环境：记录原始网关与 DNS，或在虚拟机里先演练。TUN 异常时，最快恢复手段通常是退出客户端或禁用 TUN 并刷新路由。

换个角度：若你尚未安装客户端，可先前往本站 下载页面 获取当前系统对应构建，再按下面分平台流程操作。

Windows：服务、管理员与防火墙 一文看懂

Windows 下还有一类难点是 WSL、Docker、虚拟机桥接 与宿主路由交互：开启全局 TUN 后，子系统的内置路由也许变化。若你依赖这些环境，推荐在规则中为相关子网显式指定直连或单独策略组，避免开发流量误走代理。

在 Windows 上，图形客户端普遍提供「安装服务」或「TUN 模式」按钮。首次启用时，系统也许弹出 UAC 授权，这是正常现象——创建虚拟网卡与修改路由得提升权限。

若服务未安装成功，高频缘由涵盖：安全软件拦截驱动、企业策略禁止安装虚拟网卡、或旧版本残留冲突。能够尝试：以管理员身份跑起来安装流程、暂时排除客户端目录、卸载重复的旧驱动后重启，再重新安装服务。

具体来说：防火墙侧，若你运用第三方防火墙，需允许 Mihomo 或对应服务进程接受/转发流量。部分「仅允许已签名应用」策略会误伤本地回环转发，表现为 ping 通但网页打不开，此时可对照日志看是 SYN 出不去还是 DNS 先不成功。

macOS：系统扩展、隐私与登录项 核心要点

若你同时运用 iCloud 专用代理、公司 MDM 描述文件或其他 VPN，也许出现谁最后写入路由表谁生效的竞态。此时没有万能开关顺序，只能逐项退出冲突组件，用 netstat 或图形化网络工具观察内置路由变化。

较新的 macOS 要求用户明确批准「系统扩展」或「网络过滤」类组件。若 TUN 开关灰显或一开就不成功，请到「系统设置 → 隐私与安全性」中查看是否有待批准的扩展，并按厂商说明重启。

部分发行版会把服务注册为登录项或后台守护进程，升级系统大版本后也许得重新授权。与 Windows 类似，先保证在「仅端口代理」模式下节点可用，再切 TUN，能显著缩小难点范围。

Linux 与 Android：权限模型简述 逐条拆解

移动端与桌面端的规则文件语法相同，但屏幕可操作项更少，出错时更依赖远程日志或导出诊断。若你在 Android 上运用 FlClash 等客户端，可与本站 FlClash 安卓指引 中的 VPN 与 TUN 章节交叉对照。

顺带一提：Linux 桌面高频前置条件是用户具备操作 /dev/net/tun 的权限，或运用具备能力的 systemd 服务跑起来内核。不同发行版的包名与组策略略有差异，若提示无法创建接口，首位查文档是否要求将用户加入 network 相关组或运用官方 AppImage / deb 安装方式。

Android 上，TUN 能力通常通过系统 VPN 权限呈现：用户授权后，系统会把流量引入应用建立的 VPN 通道，根本上与桌面 TUN 目标一致。需留意省电与「后台限制」会杀掉隧道，表现为间歇性掉线；可酌情调整电池策略，并在客户端里开启持久通知等保活条目。

DNS、fake-ip 与「看起来像没代理」 底层逻辑

同时确认 IPv6：若上游网络提供 IPv6 而规则核心写在 IPv4，部分站点会首位走 IPv6 直连，表现为「规则写了代理但仍直连」。可在系统层面临时关闭 IPv6 做 A/B 测试，或在配置里补充 IPv6 规则与 DNS 处理。

很多「网站打不开」并不是节点失效，而是 DNS 或域名解析策略与 TUN 同时启用后路径变了。Clash / Mihomo 兼容多种 DNS 处理模式，其中 fake-ip 会用虚拟地址响应查询，再在连接阶段映射回真实域名。若本地有其他 DNS 加速器、hosts 工具或企业 DNS 劫持，叠在一起容易出现解析不一致。

先看这一点：排查推荐：先看客户端日志里该域名命中了哪条规则、解析结果是什么类型；再临时改为 redir-host 或关闭 fake-ip 对比行为（仅作测试，长期方案需结合时延与兼容性权衡）。

绕过局域网与分流粒度 一文看懂

家庭与公司内网打印机、NAS、内网管理地址通常应直连。若 TUN 开启后内网资源失效，第一气核对是否误把 0.0.0.0/0 全量引入代理，或规则缺少对 RFC1918 地址段的直连声明。

进阶用户会运用进程级或域名级分流，但 TUN 层内置以五元组与目标 IP为主，进程级能力取决于内核与客户端实现。若你有「仅某几个 App 走代理」的诉求，也许要在规则、策略路由与客户端提供的分流 UI 之间组合实现，而不是只依赖一个总开关。

高频难点：按这个顺序排查 核心要点

TUN 无法拉起或立即回退（一眼看懂）

首位看系统是否拒绝扩展/驱动、权限是否到位、是否与另一 VPN 冲突。卸载冲突软件后重启，再仅开 TUN、关系统代理试一次。

开启后全机无网络（核心）

多半是路由或 DNS 环路。先退出客户端恢复，再在日志中查内置路由变更；核对是否把本地 DNS 或订阅刷新域名也送进了代理链。

只有个别应用异常（逐条）

记录该应用运用的协议与目标域名，对照规则命中状态。若是固定 IP 服务，确认是否走了 GEOIP 或失误策略组；若是 QUIC，确认 UDP 是否被策略允许通过所选节点。

小结 逐条拆解

久经考验、持续刷新的 Clash 系客户端在 TUN 与 Mixed 入站的组合上已经相当完备；若你正准备换机或希望从安装到订阅、再到规则分流一站式上手，可先通过本站渠道获取适合亲手系统的版本。→ 立即免费下载 Clash，开启流畅上网新运用感受

TUN 并不是「比系统代理更神秘的高级按钮」，而是把分流决策搬到更靠近网络栈的位置，从而减少应用「不听话」带来的漏洞。它与规则、DNS、IPv6 设置强相关：单开 TUN 而不整理规则，仍也许遇到解析异常或局部直连。

补充说明：实际运用中，推荐从 Rule + 系统代理稳健上网开始，遇到明确的不走代理状态再启用 TUN，并保留日志与配置备份，省事高速回滚。相比零散搜索失误码，固定一套「权限 → 路由 → DNS → 规则命中」的排查顺序，能省下大批时间。