系统代理与 TUN 模式的边界
SECTION / PROXY VS TUN系统代理(System Proxy)是操作系统层面的一项设置,本质是往系统或应用运行环境写入一组代理地址(HTTP_PROXY / HTTPS_PROXY 等环境变量,或 Windows 的 WinINet/WinHTTP 配置项、macOS 的网络偏好设置)。程序在发起网络请求时,如果读取了这组配置并主动把流量投递到代理端口,才算“走了代理”。这是一种**协商式**转发:代理生效与否,取决于目标程序是否配合。
TUN 模式则完全不同。Clash Meta(mihomo)开启 TUN 后,会在系统里创建一张虚拟网卡(Windows 上依赖 Wintun 驱动,macOS/Linux 上对应 utun/tun0 设备),并把系统默认路由指向这张虚拟网卡。此后所有经过网络层的 IP 数据包——无论来自哪个进程、是否知道代理的存在——都会先被虚拟网卡截获,再交给 Clash 内核按规则处理。这是**网络层的强制接管**,不依赖任何程序的主动配合。
一句话总结区别:系统代理管的是“愿不愿意走”,TUN 模式管的是“走不走都得经过我”。
TUN 模式不是替代系统代理的“加强版”,而是另一套转发路径。多数客户端两者可以共存,但同时开启时需要留意路由表是否出现互相覆盖的情况,建议二选一使用,减少排查成本。
哪些流量必须依赖 TUN 才能被代理
SECTION / WHO NEEDS TUN下列几类场景下,系统代理无法生效,只有 TUN 模式能覆盖:
- UDP 为主的协议。系统代理机制主要围绕 HTTP/HTTPS(基于 TCP)设计,大量在线游戏、语音通话(VoIP)、部分视频会议软件使用 UDP 直连,不会读取系统代理配置。
- 命令行与后台服务。许多 CLI 工具(包管理器、部分构建脚本)、系统守护进程不检查代理环境变量,或需要额外的 --proxy 参数才会走代理,配置繁琐且容易遗漏。
- 硬编码 Socket 连接的应用。一些桌面客户端、移动端应用直接调用底层 Socket API,完全绕开系统代理设置,常见于部分即时通讯与云同步工具。
- ICMP 与非常规协议。 Ping、Traceroute 等基于 ICMP 的探测流量,以及部分 P2P 协议,同样不在系统代理的处理范围内。
- 虚拟机与容器内的流量。宿主机的系统代理通常不会自动传递给虚拟机或容器,而 TUN 模式在宿主机路由层拦截,配合网络模式设置可以覆盖到这部分流量。
如果你发现某个应用“开了代理却依然直连”,大概率就属于以上几类,开启 TUN 模式是最直接的解决办法。
各平台开启方法与权限要求
SECTION / PLATFORM SETUPTUN 模式因为需要创建虚拟网卡、修改系统路由表,在三大平台上都要求更高的权限,细节各不相同。
Windows 上创建虚拟网卡依赖 Wintun 驱动,主流客户端(Clash Verge、Clash for Windows 衍生版)会在安装或首次启用 TUN 时自动安装该驱动。启用步骤:
- 以管理员身份运行客户端(右键“以管理员身份运行”,或在设置中开启“开机以管理员权限启动”)。
- 在设置面板中找到 TUN 模式开关并启用,首次启用系统会弹出驱动安装或网络适配器授权提示,点击允许。
- 若系统防火墙拦截了虚拟网卡的出站规则,需要在 Windows Defender 防火墙中手动放行该驱动对应的网络类别(通常首次弹窗时选择“专用网络”即可)。
不以管理员权限运行是 Windows 上 TUN 模式无法开启的最常见原因,表现为开关打开后又自动弹回。
macOS 上创建 utun 设备需要 root 权限或系统网络扩展授权,现代客户端多采用系统网络扩展(System Extension)方式规避每次输入密码:
- 首次开启 TUN 模式时,系统会弹出“系统扩展被阻止”提示。
- 前往“系统设置 → 隐私与安全性 → 网络扩展”,找到客户端对应的扩展条目并允许。
- 部分客户端仍采用传统方式,需要在设置中授权“以管理员权限运行核心”,输入一次系统密码后由后台进程长期持有权限。
如果开启后网络扩展列表里找不到条目,通常是系统安全策略拦截了安装,可重启客户端或系统后重试一次。
Linux 上创建 tun0 设备需要 CAP_NET_ADMIN 权限,最简单的方式是以 root 身份运行内核进程,或为二进制文件单独授予该权限:
sudo modprobe tun
sudo setcap cap_net_admin=eip /path/to/mihomo使用 setcap 方式的好处是不必以 root 身份启动整个客户端,只让核心进程获得网络管理权限,更符合最小权限原则。图形化客户端(如部分基于 GTK/Qt 的封装)通常在设置中提供“授权 TUN”按钮,底层执行的正是上述命令。
TUN 模式赋予客户端接管全局路由的能力,请只从官方渠道获取客户端并核对下载来源,不要为来源不明的程序授予管理员权限或 CAP_NET_ADMIN。
DNS 处理:fake-ip、劫持与路由环路
SECTION / DNS BEHAVIOR开启 TUN 模式后,DNS 查询同样会被虚拟网卡拦截,这也是 TUN 模式下最容易出问题的环节。配置文件中通常需要显式声明 DNS 劫持与解析策略:
tun:
enable: true
stack: system
dns-hijack:
- "any:53"
auto-route: true
auto-detect-interface: true
dns:
enable: true
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 1.1.1.1dns-hijack 表示把所有对外的 53 端口 DNS 请求强制拦截并交给 Clash 内核处理,避免绕过规则直连境外或被污染的 DNS 服务器。fake-ip 模式则给每个域名分配一个位于私有网段内的假 IP,应用侧看到的是这个假 IP,真正的连接建立时才由内核换成实际出口,好处是能按域名匹配规则,而不必等待真实解析结果。
常见问题排查方向:
- DNS 泄漏。如果发现直连流量的 DNS 请求没有被拦截(例如浏览器仍在使用系统原生 DNS),检查 dns-hijack 是否覆盖了对应端口,以及系统网络设置里是否手动指定了固定 DNS 服务器导致冲突。
- 路由环路。 TUN 模式下,代理节点服务器本身的连接不能再经过 TUN 网卡,否则会形成“代理连接自己”的死循环。客户端通常通过 auto-detect-interface 或显式排除进程规则来避免这一问题,手动配置时务必确认该项已开启。
- 与 VPN 客户端冲突。同时运行 TUN 模式与其他 VPN 软件,两者都会争抢默认路由,表现为其中一方间歇性失效,建议二者不同时启用。
验证 TUN 模式是否已生效
SECTION / VERIFICATION开启 TUN 模式后,建议按以下顺序验证,而不是仅凭客户端开关状态判断:
- 检查虚拟网卡是否存在。 Windows 下打开“网络连接”查看是否新增名为类似“Mihomo”“Clash”字样的适配器;macOS/Linux 下执行 ifconfig 或 ip addr 查看是否出现 utun / tun0 设备。
- 检查默认路由。Windows 用 route print,macOS/Linux 用 netstat -rn 或 ip route,确认默认路由已指向虚拟网卡而非物理网卡。
- 用不遵循系统代理的工具做测试。例如在终端里执行 curl 而不带任何代理参数,或直接用命令行 Ping 一个被规则判定为“需要代理”的域名,观察是否命中预期出口。
- 查看客户端的连接日志。多数客户端在“连接”或“日志”面板里会标注每条连接的入站类型,TUN 模式下的连接通常标记为 TUN 而非 HTTP/SOCKS,可用来确认具体是哪条链路生效。
如果以上检查全部通过,但某个具体应用仍未走代理,大概率是该应用在系统层面绑定了固定网络接口或使用了自定义 DNS,需要单独排查该程序的网络设置,而非继续调整 Clash 配置。