1. TUN 接管流量，不等于所有连接都走代理

浏览器能联网，游戏、终端工具却没有出现在 Clash 的连接列表里，常见原因是这些应用没有读取系统代理。系统代理只是告诉应用一个 HTTP 或 SOCKS 代理入口；TUN 模式则创建虚拟网络接口，再借助路由把 IP 数据包送入内核，不要求应用主动支持代理协议。

本文的配置字段以使用 mihomo 内核的客户端为主。Clash 是客户端生态中的常见名称，不代表所有同名或历史版本都支持相同的 TUN 功能。操作前先在「关于」或「内核」页面记录客户端版本、内核名称与内核版本；如果实际使用的是旧版 Clash 内核，不要直接照搬 mihomo 的选项。

“全部流量”也有边界：被排除的应用或网段、未配置接管的 IPv6、其他 VPN 的专用路由，都可能绕开 TUN。局域网访问、组播发现和系统保留流量也不应简单理解为必须经过远端代理。判断是否生效，要看连接记录与实际路由，不能只看开关颜色。

2. 开启前检查：节点、权限与其他 VPN

  1. 先确认已有配置可用。导入订阅，选中配置和可用节点，用系统代理打开一个已知可访问的 HTTPS 页面。节点本身连接失败时，TUN 不会修复节点。
  2. 保存现有设置。备份配置，记录系统代理、DNS、TUN 和服务模式的原始状态。不要把订阅地址、访问令牌或节点密码贴到公开日志中。
  3. 暂时退出其他 VPN。包括加速器、企业隧道和另一款代理客户端。它们可能同时改写默认路由或 DNS；企业设备应先确认管理策略。
  4. 确认代理协议能力。TUN 能接收 UDP，不代表选中的节点和服务器就支持 UDP 转发。游戏、语音和 QUIC 是否可用，需要分开验证。

桌面客户端首次创建网卡或写入路由，通常需要管理员、root 或受控的特权辅助进程。Android 使用的是系统 VPN 授权，不等同于桌面“服务模式”，一般也不要求设备 root。

3. 四个平台的开启步骤与授权区别

下列桌面路径以 Clash Verge Rev 一类 mihomo 图形客户端的常见布局为例；不同发行版可能把「TUN 模式」命名为「虚拟网卡模式」。找不到同名入口时，应核对当前版本的设置说明，不要下载来历不明的所谓通用驱动补丁。

Windows：先安装服务，再启用虚拟网卡

  1. 进入「设置」→「服务模式」，执行安装或启用操作，并在 Windows 的 UAC 提示中确认授权。若该版本把服务入口放在「设置」→「系统设置」，以实际界面为准。
  2. 确认服务状态显示运行中，再进入「设置」→「TUN 模式」或「虚拟网卡模式」，打开开关。首次启用后等待网卡初始化，不要连续反复切换。
  3. 打开日志，检查是否出现权限拒绝、创建接口失败或路由添加失败。Windows 客户端可能使用 Wintun 等组件，驱动文件的提供方式由客户端决定。
  4. 打开「连接」页面，运行之前不读取系统代理的应用，查看是否新增记录；确认其命中的规则和策略组。

服务模式的作用是让受控后台服务执行需要权限的操作，不等于代理一定启动成功。如果界面显示“服务已安装”但仍然失败，要继续确认服务正在运行、内核进程已启动，以及安全软件是否拦截了网卡组件。不要把长期关闭防火墙当作修复步骤。

macOS：授权辅助服务，检查 utun 接口

  1. 在客户端「设置」→「服务模式」中安装或修复辅助服务，按系统提示输入管理员凭据。不要把管理员密码填入订阅导入框或节点设置。
  2. 启用「TUN 模式」，允许客户端完成必要的系统授权。具体授权窗口随客户端实现和 macOS 版本变化。
  3. 在终端运行 ifconfig 查看接口，运行 netstat -rn 查看路由；macOS 上通常会使用 utun 接口。

系统里原本就可能存在多个 utun 接口，因此“看见 utun”不等于当前 Clash 已接管。应结合启用前后的路由变化和客户端日志判断。macOS 的常见 TUN 实现使用系统接口，不应套用 Windows 的 Wintun 安装办法。

Linux：确认 TUN 设备与网络管理权限

图形客户端优先使用其自带服务模式；直接运行 mihomo 时，再按发行版文档配置 systemd 服务及权限。检查设备是否存在，可以执行：

ls -l /dev/net/tun
ip link show
ip route show
ip -6 route show

/dev/net/tun 不存在时，先检查内核 TUN 支持、模块加载情况，以及容器是否映射该设备。创建接口和调整路由通常涉及 CAP_NET_ADMIN；容器中即使进程以 root 运行，也可能没有所需能力。不要直接给整个图形客户端设置宽泛的永久提权权限。

启用后检查 ip rule show 与路由表，排查 NetworkManager、容器网络或其他 VPN 的规则冲突。部分 mihomo 版本提供 Linux 专用的 auto-redirect，但它不是本教程的跨平台前提，不要在所有设备上机械添加。

Android：允许建立 VPN，再检查分应用设置

  1. 在使用 mihomo 的 Android 客户端中导入配置，点击首页的启动或连接按钮。
  2. 首次启动时，在系统“连接请求”窗口允许建立 VPN。Android 客户端通常通过 VpnService 建立虚拟接口，不需要另外安装桌面驱动。
  3. 检查客户端「设置」中的「访问控制」或「分应用代理」。如果启用了“仅代理所选应用”，未勾选的应用就不会被接管。
  4. 若切到后台后断开，再检查系统「设置」→「应用」→当前客户端→「电池」中的后台限制；名称可能因系统而异。

同一用户配置下，Android 通常只能同时维持一个基于 VpnService 的 VPN。另一个 VPN、广告过滤器或加速器启动后，可能替换当前连接。「始终开启 VPN」和「屏蔽未通过 VPN 的连接」属于系统级策略，配置错误时会直接断网，建议基础验证完成后再考虑启用。

4. stack 怎么选：system、gvisor 与 mixed

stack 是 TUN 内部处理网络流量的协议栈选项，不是代理协议，也不是节点类型。mihomo 常见取值包括 system、gvisor 和 mixed，具体可用性仍取决于内核构建与平台。

选项主要区别调整建议
system使用系统协议栈相关实现处理流量客户端默认采用它且连接正常时，可以保持。
gvisor使用用户态网络协议栈遇到兼容问题时，可作为对照测试项。
mixed在 mihomo 中，TCP 使用 system，UDP 使用 gvisor需要分别观察 TCP、UDP 表现，不能仅凭网页测试判断。

不要把某个 stack 当成固定的“游戏最佳设置”。先保持客户端默认值；出现特定应用连接异常时，每次只改一个选项，并重启 TUN 后复测。MTU 也遵循同样原则：先用默认值，只有出现大包传输卡住、隧道封装等明确线索时再调整，不能因为一次延迟偏高就随意改成 9000。

5. DNS 劫持配置：接住 53 端口查询

应用先把域名解析为 IP，再建立连接。若 DNS 查询没有进入预期的解析链路，可能出现域名规则无法按预期工作、解析结果异常或连接超时。TUN 的 dns-hijack 用于把匹配的传统 DNS 请求交给内核 DNS 模块处理；这里的“劫持”是本机转向，不是修改远端网站。

mihomo 配置片段

下面示例启用 IPv4 TUN、自动路由和 UDP/TCP 53 端口接管。它不是完整订阅，不能覆盖整份配置。先备份，再通过客户端支持的覆写或合并功能应用；已有 tun 或 dns 字段时应合并内容，不要在 YAML 顶层重复创建同名键。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  • auto-route：让内核自动配置接管所需的路由；它不保证覆盖被排除或被其他软件抢占的路径。
  • auto-detect-interface：自动选择出站接口，多网卡、热点或企业 VPN 环境仍需核对结果。
  • any:53 与 tcp://any:53：分别匹配传统 UDP、TCP DNS 查询；匹配范围仍受流量是否进入 TUN 影响。
  • 127.0.0.1:1053：是本地 DNS 监听地址。系统 DNS 设置通常不能直接填写带 1053 端口的地址，本例依靠 TUN 转交查询。
  • nameserver：示例给出了两个具体的传统 DNS 上游，实际应按网络可达性、隐私要求和分流设计选择，并非所有网络都适用。

Fake-IP 返回保留地址，是映射机制

在上述配置中，DNS 可能返回 198.18.0.0/16 范围内的映射地址，内核再把连接关联回域名。它不是目标网站的真实公网 IP。若局域网设备发现、特定游戏或内部域名不兼容，应针对具体域名设置 fake-ip-filter，或使用客户端支持的其他 DNS 模式，而不是删除整个 DNS 配置。

Android 的「私人 DNS」也要单独考虑。若应用绕过内核 DNS 使用其他解析路径，应检查其连接与分流结果。IPv6 同样需要端到端配置：本例没有给出 IPv6 接管方案，不能据此声称 IPv6 已被覆盖；开启双栈前要核对内核、路由、DNS 返回结果与节点能力。

6. 三步验证：接口、连接记录与 DNS

  1. 确认接口和路由。日志中应能看到 TUN 成功启动，而不是不断重试。Windows 可用 route print，macOS 用 netstat -rn，Linux 用 ip route show 检查变化。不同实现可能创建分段路由或策略路由，不一定直接替换默认路由。
  2. 确认非系统代理应用进入内核。关闭该应用自身的代理设置后重新发起连接，再查看 Clash 的「连接」页面。桌面环境也可临时关闭系统代理，仅保留 TUN 做对照；企业设备不要随意改动受管理设置。
  3. 确认解析与规则结果。查询一个未缓存的域名，检查日志、DNS 返回和后续连接是否一致。Fake-IP 模式下出现映射地址本身不是错误，重点是连接能否建立、是否命中预期策略。

例如可以执行以下命令测试一次 HTTPS 请求。它用于验证链路，不代表测速或任何实测性能结论：

curl --noproxy "*" -I --connect-timeout 10 https://example.com

--noproxy "*" 用于绕过 curl 常规代理配置，便于观察 TUN 路径；Windows PowerShell 中建议明确使用 curl.exe，避免命令别名差异。测试后应在连接列表里核对目标域名、匹配规则和出站策略，单看命令返回成功不足以证明走了远端代理。

7. 常见故障与安全回退

开 TUN 后所有网页都打不开

先关闭 TUN，确认基础网络恢复，再检查服务权限、当前配置、DNS 上游可达性和其他 VPN。若关闭后仍无法解析，检查是否残留手动 DNS 或系统代理设置，并恢复到操作前记录的状态。不要一边重装客户端，一边更换节点、stack 和 DNS，否则很难定位真正原因。

网页正常，游戏或语音仍失败

先看相关进程是否进入连接列表，再看 UDP 是否得到节点支持。浏览器能打开网页，通常只能证明部分 TCP 或 HTTPS 路径正常。Android 还要检查游戏是否被分应用规则排除；桌面则检查游戏是否绑定了特定网卡，以及是否存在其他加速器路由。

局域网打印机、NAS 或企业域名失效

先确认目标需要直连还是企业 VPN 路由，再调整对应规则、DNS 解析策略或 TUN 路由排除。规则中的 DIRECT 与路由排除不同：前者仍可由内核处理后直连，后者让指定流量不进入 TUN。内部域名依赖企业 DNS 时，公共 DNS 上游通常无法替代它。

退出客户端后网络没有恢复

优先重新打开客户端，正常关闭 TUN 并退出，让程序执行清理；再检查系统代理、DNS 和残留服务状态。远程操作服务器时尤其要留意：修改默认路由可能切断 SSH，应事先准备控制台或带外访问方式，不要在唯一管理连接上直接试错。