TUN 模式不生效的常见原因

排障手册
7.4k 词

摘要: TUN 模式能接管系统全部网络流量，但它比系统代理模式更容易出问题——权限不足、软件冲突、配置错误都可能导致 TUN 不生效。本文列出 TUN 模式最常见的故障原因和对应解决方法。

问题一：权限不足

TUN 模式的工作原理是创建一个虚拟网络适配器并修改系统路由表，这两个操作都需要操作系统的最高权限。权限不足是 TUN 不生效最常见也最容易忽略的原因。

各平台的权限要求

Windows：

  • 代理客户端必须以管理员身份运行
  • 右键客户端 → 以管理员身份运行
  • 或者在客户端属性中勾选”以管理员身份运行此程序”，这样每次启动自动获取权限
  • Clash Verge Rev 提供了 Service Mode（服务模式），安装后客户端以系统服务运行，无需每次手动提权

macOS：

  • 首次开启 TUN 时，系统会弹出密码授权对话框
  • 必须输入管理员密码才能创建虚拟网卡
  • 如果点了取消或者授权失败，TUN 开关可能显示已开启但实际未生效

Linux：

  • 需要 root 权限或 CAP_NET_ADMIN 能力
  • 使用 sudo 启动客户端，或通过 setcap 为二进制文件设置能力：
1
sudo setcap cap_net_admin=ep /path/to/proxy-client

典型症状

  • TUN 开关显示已开启，但流量仍然没有走代理
  • 客户端日志中出现 permission denied、operation not permitted 等错误
  • 虚拟网卡未创建（Windows 设备管理器或 ipconfig 中看不到 TUN 适配器）

解决方法

  1. 确认客户端是否以管理员/root 身份运行
  2. 检查客户端日志，搜索权限相关的错误信息
  3. Windows 用户：安装 Clash Verge Rev 的 Service Mode，一劳永逸解决权限问题（设置 → Service Mode → Install）
  4. 重启客户端后重新开启 TUN

问题二：其他 VPN 或代理软件冲突

操作系统在同一时间只能有一个 TUN/VPN 适配器正常控制路由表。当多个程序同时试图修改默认路由时，结果是不可预测的——可能一个覆盖另一个，也可能两个都不正常工作。

常见冲突软件

  • 企业 VPN：Cisco AnyConnect、GlobalProtect、FortiClient 等公司 VPN 客户端
  • WireGuard：WireGuard 自身也会创建 TUN 设备并修改路由表
  • Tailscale：基于 WireGuard 的组网工具，运行时会接管部分路由
  • 其他代理客户端：同时运行多个代理客户端（比如 Clash Verge 和 v2rayN 同时开启 TUN）
  • OpenVPN：会创建 TAP/TUN 虚拟网卡

典型症状

  • TUN 开启后失败，日志报告设备创建或路由设置错误
  • TUN 开启后连接全部断开——包括代理流量和直连流量都断
  • 其他 VPN 软件突然不工作了
  • 网络偶尔正常偶尔断开，行为不稳定

解决方法

  1. 在开启代理客户端的 TUN 之前，关闭所有其他 VPN 和代理软件
  2. 检查系统托盘、任务管理器中是否有残留的 VPN 进程
  3. 如果必须同时使用公司 VPN 和代理，把代理客户端切换到系统代理模式——系统代理不创建虚拟网卡，不会与 VPN 冲突
  4. 某些场景下可以让代理客户端和 VPN 共存，但需要手动调整路由优先级，操作复杂且容易出错，不推荐普通用户尝试

问题三：虚拟化和 WSL 环境冲突

Windows 上的 Hyper-V、WSL2 和 Docker Desktop 都依赖虚拟网络适配器。这些虚拟网络与 TUN 设备之间可能产生路由冲突，导致虚拟机或 WSL 的网络在 TUN 开启后断掉。

冲突原理

WSL2 使用一个名为 vEthernet (WSL) 的虚拟网络适配器，通过 NAT 方式让 WSL 实例访问宿主机网络。当 TUN 模式修改了系统默认路由后，WSL 的网络流量路径被改变——原本应该通过宿主机直接出去的流量被 TUN 设备拦截，而 TUN 设备可能没有正确处理来自 WSL 虚拟网段的流量。

Docker Desktop（Windows 版）在使用 WSL2 后端时面临同样的问题。Hyper-V 虚拟机的虚拟交换机也可能因为路由变更而受影响。

典型症状

  • 开启 TUN 后，WSL2 内部无法访问网络（apt update 失败、curl 超时）
  • Docker 容器无法拉取镜像或访问外部网络
  • Hyper-V 虚拟机网络中断
  • 关闭 TUN 后，虚拟化环境网络恢复正常

解决方法

  1. 在 TUN 配置中排除 WSL 的虚拟网段：WSL2 通常使用 172.16.0.0/12 范围内的地址，确保分流规则中这些网段走 DIRECT
  2. 切换到系统代理模式：如果你经常需要在 WSL 中工作，系统代理模式不会影响虚拟网络
  3. 在 WSL 内部单独配置代理：在 WSL 的 shell 中设置 http_proxy 和 https_proxy 环境变量，指向宿主机的代理端口（通常是 http://宿主机IP:7890）
  4. 调整 TUN 的路由配置：在 mihomo 配置中使用 exclude-interface 排除 WSL 的虚拟网卡

问题四：TUN 协议栈选择不当

TUN 设备接收到的是原始 IP 数据包，需要一个协议栈来处理这些数据包。mihomo（Clash Verge Rev 的内核）提供三种协议栈选项，选择不当可能导致 TUN 不正常工作。

三种协议栈对比

gVisor（默认推荐）：

  • Google 开发的用户态网络栈，在用户空间完整实现 TCP/UDP 协议处理
  • 优势：稳定性高、跨平台一致性好、与系统内核网络栈隔离
  • 劣势：CPU 占用比 system 栈稍高
  • 适用：日常使用的首选

system（内核栈）：

  • 直接使用操作系统内核的 TCP/UDP 协议栈
  • 优势：性能最好、CPU 开销最低
  • 劣势：在某些系统或网络环境下可能出现兼容性问题
  • 适用：高带宽需求、对性能敏感的场景

mixed（混合模式）：

  • TCP 走 system 栈，UDP 走 gVisor 栈
  • 折中方案：TCP 流量（网页、下载等大头流量）获得内核栈的性能优势，UDP 流量（DNS、游戏等）获得 gVisor 的稳定性
  • 适用：在 system 栈出现 UDP 问题但 TCP 表现好的情况下

典型症状

  • 使用 gVisor 栈时某些应用无法连接
  • 使用 system 栈时出现不定期的连接中断或系统网络异常
  • UDP 流量（如游戏、DNS）工作不正常

解决方法

如果 TUN 不生效或行为异常，切换协议栈是最简单的排查手段之一：

  1. Clash Verge Rev：设置 → TUN → Stack，在 gVisor / system / mixed 之间切换
  2. 配置文件方式：修改 tun.stack 字段
1
2
3
tun:
  enable: true
  stack: mixed    # 可选 gvisor / system / mixed
  1. 切换后重启客户端，观察 TUN 是否正常工作
  2. 一般建议先用 gVisor（默认），不行再试 mixed，最后试 system

问题五：防火墙和杀毒软件拦截

安全软件可能将 TUN 模式的行为——创建虚拟网卡、修改路由表、拦截所有网络流量——视为可疑操作并予以阻止。这在 Windows 上尤其常见。

可能的拦截行为

  • 杀毒软件阻止虚拟网卡创建：国内安全软件（如 360、火绒）可能直接拦截虚拟设备驱动的安装或加载
  • Windows 防火墙阻止 TUN 流量：防火墙规则可能阻止代理客户端在 TUN 虚拟网卡上的通信
  • 企业安全策略：公司电脑上的终端安全软件可能强制禁止创建 VPN/TUN 设备
  • Windows Defender SmartScreen：首次运行客户端时可能弹出警告并阻止执行

典型症状

  • TUN 开关开启但虚拟网卡未出现
  • TUN 虚拟网卡创建成功，但所有流量都无法通过——表现为全面断网
  • 客户端日志中出现驱动加载失败或网络接口创建失败的错误

解决方法

  1. 将代理客户端添加到杀毒软件的排除列表
    • Windows Defender：设置 → 隐私和安全 → Windows 安全 → 病毒和威胁防护 → 排除项 → 添加代理客户端的安装目录
    • 火绒 / 360：在对应的白名单或信任列表中添加客户端
  2. 检查 Windows 防火墙规则
    • 控制面板 → Windows Defender 防火墙 → 允许应用通过防火墙 → 确认代理客户端在列表中且已勾选
  3. 临时关闭安全软件测试
    • 暂时关闭防火墙和杀毒软件，测试 TUN 是否正常
    • 如果关闭后正常 → 确认是安全软件导致的问题，添加排除规则后重新开启
  4. 企业环境：如果公司安全策略禁止 TUN，可能无法绕过，只能使用系统代理模式

问题六：DNS 配置问题

TUN 模式下，代理客户端通常会接管系统的 DNS 解析。如果 DNS 配置不正确，TUN 可能成功捕获了所有流量，但由于域名无法解析，网站仍然打不开。

DNS 在 TUN 模式下的工作方式

TUN 模式通过 dns-hijack 参数劫持系统发出的 DNS 请求（通常是发往 UDP 53 端口的查询），由代理客户端统一处理 DNS 解析。更多 TUN 和 DNS 配置细节可以参考 Clash Wiki。这既能防止 DNS 泄漏，又能让 Fake-IP 等高级 DNS 策略生效。

如果 DNS 模块未启用或配置有误，劫持到的 DNS 请求无法得到正确的响应，所有域名访问都会失败。

典型症状

  • TUN 开启后，直接 ping IP 地址能通（如 ping 1.1.1.1 正常），但网站打不开
  • 浏览器显示”DNS_PROBE_FINISHED_NXDOMAIN”或类似的 DNS 错误
  • 部分网站能打开但大多数不行（可能命中了 DNS 缓存的域名能用，未缓存的不行）

解决方法

  1. 确保 DNS 模块已启用：在 mihomo 配置中确认 dns.enable: true
1
2
3
4
5
6
7
dns:
  enable: true
  enhanced-mode: fake-ip    # 推荐使用 fake-ip 模式
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  1. 确认 dns-hijack 配置正确：TUN 配置中必须包含 DNS 劫持设置
1
2
3
4
tun:
  enable: true
  dns-hijack:
    - any:53    # 劫持所有发往 53 端口的 DNS 请求

  1. 检查 nameserver 是否可用：如果上游 DNS 服务器不可达，所有 DNS 请求都会超时。国内环境推荐使用国内 DoH：

    • 阿里 DNS：https://dns.alidns.com/dns-query
    • 腾讯 DNS：https://doh.pub/dns-query

  2. 清除系统 DNS 缓存：修改 DNS 配置后，刷新系统缓存使新配置立即生效

1
2
3
4
5
6
7
8
# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

问题七：局域网设备不可达

TUN 模式捕获系统的所有出站流量，包括发往局域网内部的流量。如果分流规则中没有将私有网络地址段设为直连，局域网内的打印机、NAS、本地开发服务器等设备都会变得不可达。

典型症状

  • 开启 TUN 后，网络打印机无法打印
  • NAS 设备（如群晖）的管理界面打不开
  • 局域网内的文件共享（SMB）失败
  • 本地开发服务器（如 localhost:3000 或 192.168.1.x:8080）无法访问
  • 智能家居设备（如 HomeAssistant）失联

解决方法

确保代理配置中包含以下直连规则，覆盖所有 RFC 1918 私有地址段和其他特殊地址段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

rules:
  # 局域网直连 - 必须包含
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  # 其他特殊地址段
  - IP-CIDR,100.64.0.0/10,DIRECT    # CGNAT
  - IP-CIDR,169.254.0.0/16,DIRECT   # 链路本地
  - IP-CIDR,224.0.0.0/4,DIRECT      # 多播
  - IP-CIDR,255.255.255.255/32,DIRECT  # 广播

大多数机场订阅配置已经包含了这些规则。如果你使用自定义配置或精简过规则文件，检查是否遗漏了这些直连规则。

问题八：系统代理和 TUN 同时开启

系统代理和 TUN 是两种不同的流量捕获机制。同时开启两者可能导致流量被重复处理——数据包先被系统代理捕获一次，再被 TUN 设备捕获一次，形成处理循环或冲突。

典型症状

  • 网络极不稳定，速度时快时慢
  • 部分网站能打开，部分超时
  • 客户端日志中出现大量重复连接或异常错误
  • CPU 占用异常升高（流量被循环处理）

解决方法

同一时间只使用一种模式：

  • 使用 TUN 模式时 → 关闭系统代理
  • 使用系统代理时 → 关闭 TUN

大多数现代代理客户端（如 Clash Verge Rev）在开启 TUN 时会自动关闭系统代理。但如果你的客户端没有自动处理，或者你手动开启了系统代理，需要自行确认不要同时激活两者。

在 Clash Verge Rev 中检查：界面顶部的模式切换区域应该只有一种模式处于激活状态。

系统排查流程

如果 TUN 不生效，按照以下顺序逐步排查，可以高效定位问题：

第一步：检查权限

确认代理客户端是否以管理员权限运行。这是最常见的原因，排查成本也最低。

  • Windows：右键客户端图标 → 以管理员身份运行
  • macOS：重新开启 TUN 时注意系统的密码授权弹窗
  • Linux：用 sudo 启动或确认已设置 CAP_NET_ADMIN

第二步：检查软件冲突

打开任务管理器（Windows）或活动监视器（macOS），确认没有其他 VPN 或代理软件在运行。重点检查：WireGuard、Tailscale、公司 VPN 客户端、其他代理客户端。

第三步：查看客户端日志

在客户端中开启 Debug 级别日志，重新开关 TUN，观察日志输出。关注以下关键词：

  • permission、denied → 权限问题
  • device、interface、create failed → 虚拟网卡创建失败
  • route、routing → 路由设置失败
  • dns、resolve → DNS 配置问题

第四步：切换 TUN 协议栈

在客户端设置中将 TUN 协议栈从 gVisor 切换到 system 或 mixed（反之亦然），重启客户端测试。不同协议栈在不同系统环境下的兼容性不同，切换栈是低成本的排查手段。

第五步：排除安全软件

临时关闭防火墙和杀毒软件，重新测试 TUN。如果关闭后 TUN 正常工作 → 将客户端添加到安全软件的排除列表中，然后重新开启安全软件。

第六步：检查 DNS 配置

验证 dns.enable 是否为 true，dns-hijack 是否包含 any:53，上游 DNS 服务器是否可达。DNS 配置错误的典型表现是 ping IP 正常但网站打不开。

第七步：验证局域网直连规则

检查分流规则中是否包含 192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 等私有网段的 DIRECT 规则。缺少这些规则会导致局域网设备不可达。

第八步：退回系统代理测试

把代理模式切换回系统代理。如果系统代理正常工作 → 确认问题出在 TUN 模式本身，重点排查以上 TUN 相关的配置。如果系统代理也不工作 → 问题不在 TUN，而是节点、订阅或网络本身的问题，参考节点连不上的排查流程。

常见问题

Q：TUN 和系统代理哪个更好？

没有绝对的好坏，取决于使用场景。TUN 模式更全面——它捕获系统所有流量，包括 UDP、DNS 和不读取系统代理的应用程序。系统代理更轻量——不需要管理员权限，不会与 VPN 冲突，排障也更简单。

如果你只在浏览器中使用代理、不打游戏、不需要 UDP 支持，系统代理就够了。如果你需要游戏加速、防止 DNS 泄漏、或者让所有应用都走代理，才需要开启 TUN。

Q：TUN 模式会导致电脑变慢吗？

轻微影响，但正常情况下几乎感知不到。gVisor 协议栈在用户空间处理网络数据包，会占用一些 CPU 资源。在高带宽场景下（如下载大文件），CPU 占用可能会有一定上升。

如果感觉明显变慢，可以尝试以下操作：

  • 切换到 system 栈（性能最好但兼容性略低）
  • 检查是否加载了过多的分流规则（几万条规则会增加匹配开销）
  • 确认日志级别不是 Debug（Debug 日志的 IO 开销不可忽略）

Q：手机上需要开 TUN 吗？

不需要额外操作。iOS 和 Android 上的代理客户端（Shadowrocket、Surge、sing-box 等）默认通过系统提供的 VPN 接口捕获所有流量，效果等同于桌面端的 TUN 模式。当你在手机上开启代理客户端时看到的 VPN 图标，就意味着所有流量已经被接管。手机用户不存在”系统代理 vs TUN”的选择问题。

Q：WSL2 网络在 TUN 下断了怎么办？

四种解决思路：

  1. 排除 WSL 网段：在分流规则中将 WSL 使用的虚拟网段（通常在 172.16.0.0/12 范围内）设为 DIRECT
  2. 切换到系统代理模式：系统代理不修改路由表，不会影响 WSL 网络
  3. 在 WSL 内部手动配置代理：设置 export http_proxy=http://宿主机IP:7890 和 export https_proxy=http://宿主机IP:7890，宿主机 IP 可通过 WSL 内 cat /etc/resolv.conf 中的 nameserver 获取
  4. 使用 mixed 栈：部分用户反馈 mixed 栈对 WSL 虚拟网络的兼容性优于 gVisor 栈

Q：开启 TUN 后完全断网了怎么办？

首先不要慌——关闭 TUN 模式即可恢复网络。如果客户端界面无法操作（比如客户端也依赖网络），直接在任务管理器中结束代理客户端进程，系统网络会自动恢复。

完全断网通常意味着 TUN 虚拟网卡创建成功、路由表已修改，但代理客户端无法正确处理流量。常见原因：

  • 代理节点本身就不可用（先用系统代理模式确认节点可用性）
  • DNS 配置错误（参考问题六的解决方法）
  • 安全软件拦截了 TUN 虚拟网卡上的流量
  • 系统代理和 TUN 同时开启导致流量循环

Q：每次开机都要重新开启 TUN 吗？

取决于客户端的设置。大多数客户端支持”开机自启动”和”启动时自动开启 TUN”两个选项。在 Clash Verge Rev 中：

  • 设置 → 开机自启 → 开启
  • 设置 → TUN → 默认开启

配合 Service Mode 使用，可以实现开机后全自动进入 TUN 模式，无需任何手动操作。