--- title: TUN 模式不生效的常见原因 date: 2026-05-10 updated: 2026-05-10 categories: - 排障手册 tags: - TUN - 排障 - 权限 - 冲突 - VPN index_img: /images/posts/tun-not-working.webp excerpt: TUN 模式不生效的 8 个常见原因：权限不足、VPN冲突、防火墙拦截等，附排查流程。 --- > **摘要**: TUN 模式能接管系统全部网络流量，但它比系统代理模式更容易出问题——权限不足、软件冲突、配置错误都可能导致 TUN 不生效。本文列出 TUN 模式最常见的故障原因和对应解决方法。 --- ## 问题一：权限不足 TUN 模式的工作原理是创建一个虚拟网络适配器并修改系统路由表，这两个操作都需要操作系统的最高权限。权限不足是 TUN 不生效最常见也最容易忽略的原因。 ### 各平台的权限要求 **Windows**： - 代理客户端必须以管理员身份运行 - 右键客户端 → 以管理员身份运行 - 或者在客户端属性中勾选"以管理员身份运行此程序"，这样每次启动自动获取权限 - [Clash Verge Rev](https://github.com/clash-verge-rev/clash-verge-rev) 提供了 Service Mode（服务模式），安装后客户端以系统服务运行，无需每次手动提权 **macOS**： - 首次开启 TUN 时，系统会弹出密码授权对话框 - 必须输入管理员密码才能创建虚拟网卡 - 如果点了取消或者授权失败，TUN 开关可能显示已开启但实际未生效 **Linux**： - 需要 root 权限或 `CAP_NET_ADMIN` 能力 - 使用 `sudo` 启动客户端，或通过 `setcap` 为二进制文件设置能力： ```bash 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` 字段 ```yaml tun: enable: true stack: mixed # 可选 gvisor / system / mixed ``` 3. 切换后重启客户端，观察 TUN 是否正常工作 4. 一般建议先用 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](https://wiki.metacubex.one/)。这既能防止 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` ```yaml 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 ``` 2. **确认 dns-hijack 配置正确**：TUN 配置中必须包含 DNS 劫持设置 ```yaml tun: enable: true dns-hijack: - any:53 # 劫持所有发往 53 端口的 DNS 请求 ``` 3. **检查 nameserver 是否可用**：如果上游 DNS 服务器不可达，所有 DNS 请求都会超时。国内环境推荐使用国内 DoH： - 阿里 DNS：`https://dns.alidns.com/dns-query` - 腾讯 DNS：`https://doh.pub/dns-query` 4. **清除系统 DNS 缓存**：修改 DNS 配置后，刷新系统缓存使新配置立即生效 ```bash # 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 私有地址段和其他特殊地址段： ```yaml 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，而是节点、订阅或网络本身的问题，参考[节点连不上的排查流程](./connectivity-checklist.md)。 --- ## 常见问题 ### 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 模式，无需任何手动操作。