先选接管方式，再检查分流规则

浏览器能打开网页，终端却连接超时；开启系统代理后，游戏仍然使用原来的出口。这些现象不一定是节点失效，常见原因是应用没有读取系统代理设置。系统代理与 TUN 的主要差别，是流量怎样进入 Clash 内核，而不是节点速度或者订阅质量。

  • 主要使用浏览器：先开启系统代理。设置简单，出现问题时容易恢复。
  • 只想代理一个命令行任务：先给命令显式指定 HTTP 或 SOCKS 代理，不必立刻开启 TUN。
  • 应用不支持代理设置，或需要处理部分 UDP 流量：再考虑 TUN，并检查路由、DNS 和节点协议。
  • 正在连接公司 VPN：先确认单位网络要求，避免两个工具同时修改默认路由。

系统代理：让应用主动连接本地端口

系统代理会把本地代理地址写入操作系统的代理设置。支持这套设置的应用读取地址后，把请求交给客户端。例如，客户端监听 127.0.0.1:7890，浏览器便可以通过这个本地端口建立代理连接。端口号以客户端实际显示为准，7890 只是本文示例。

系统代理能接管哪些连接？

Edge、Chrome 等浏览器通常遵循系统代理，但具体行为还会受到组织策略、扩展和启动参数影响。Firefox 可以选择使用系统代理，也可以独立设置连接方式。下载器、开发工具和游戏则各有自己的实现，不能只凭任务栏里“系统代理已开启”就认定全部应用都已接管。

  • HTTP 代理常用于网页请求，HTTPS 通常通过 HTTP CONNECT 建立隧道；这不代表客户端在解密 HTTPS 内容。
  • SOCKS5 可以处理 TCP；能否使用 UDP，还需要应用、客户端和节点链路共同支持。
  • mixed-port 可以在同一端口接收 HTTP 与 SOCKS 代理请求，但不会让不读取代理设置的应用自动改道。

从系统设置核对地址

Windows 11 可以进入「设置」→「网络和 Internet」→「代理」，检查手动代理或设置脚本状态。macOS 可以进入「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」。这些位置用于核对系统设置；日常开关应优先使用客户端，避免两边反复覆盖。

不要把 0.0.0.0 填成应用的代理服务器地址。它常用于表示监听全部 IPv4 接口；同一台电脑上的应用通常应连接 127.0.0.1。只有需要局域网共享时，才另外考虑监听地址、防火墙和访问限制。

TUN 模式：通过虚拟网络接口接收 IP 流量

TUN 会创建或使用虚拟网络接口，再通过路由等机制把符合条件的 IP 数据包交给内核处理。应用不必提供 HTTP 代理选项，因此它更适合无法手动配置代理的程序。Clash Meta 后续发展的 mihomo 内核提供了相关能力，但不同客户端使用的内核、服务安装方式与界面开关并不完全相同。

“开启 TUN”不是“拦截所有网络”的保证。实际接管范围取决于 IPv4 与 IPv6 路由、接口排除项、局域网绕过、其他 VPN 和系统防火墙。虚拟机、容器以及 WSL 的流量也有额外网络路径，不能直接等同于宿主机应用。

对比项目 系统代理 TUN 模式
流量入口 应用主动连接代理监听端口 虚拟接口与路由接收 IP 流量
应用要求 遵循系统设置或单独配置代理 通常不要求应用支持代理协议
UDP 处理 普通 HTTP 系统代理不承接一般 UDP 可处理被接管的 UDP，仍依赖节点支持
权限与服务 通常不需要创建虚拟接口 通常需要提权或预装特权服务
排障重点 地址、端口、应用是否读取设置 路由、DNS、服务权限与接口冲突

为什么 TUN 常需要管理员权限？

创建接口和修改路由属于系统网络操作。Windows 客户端可能通过服务模式执行，macOS 可能需要授权辅助程序；Linux 通常涉及 /dev/net/tun 与相应网络管理权限。安装了特权服务之后，图形界面不一定需要每次都以管理员身份启动。

如果日志提示权限不足，应按所用客户端说明安装或修复服务，而不是不断重复切换 TUN。也不要为了排障长期关闭系统防火墙；先确认服务状态，再查具体被阻止的程序和规则。

命令行和游戏：按应用验证，不按开关猜测

命令行不通，先做显式代理测试

终端里的工具不一定读取操作系统代理设置。部分工具识别 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，但支持范围与大小写处理存在差异。排查时，显式传参通常比修改全局环境变量更容易确认影响范围。

# Windows PowerShell 使用 curl.exe，避免旧版别名干扰
curl.exe --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# macOS / Linux 使用 curl
curl --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# 通过 SOCKS5，并让代理端解析目标域名
curl --proxy socks5h://127.0.0.1:7890 --noproxy "" -I https://example.com

这些命令假设 7890 是支持相应协议的混合端口。返回 HTTP 响应说明这次代理请求建立成功，但不能单凭状态码判断使用了哪个公网出口。如果显式代理成功、普通命令失败，优先检查该工具的代理参数或环境变量，不要先更换订阅。

游戏使用 UDP，TUN 也不是延迟保证

游戏可能同时使用 TCP 登录、UDP 对战和独立语音连接。开启 TUN 后，只有被路由接管且得到节点支持的连接才有机会经过代理。节点协议、服务端配置、规则命中和地区限制，都可能影响结果。

  1. 先在客户端连接列表里查找游戏进程或目标地址，确认连接是否进入内核。
  2. 检查命中的规则与代理组，避免登录连接走代理、对战连接却落到意外的直连规则。
  3. 核对节点是否支持 UDP 转发，不要只看网页测速结果。
  4. 在相同服务器和时段比较直连与代理表现，记录游戏内延迟、丢包及断线情况。

绕路更长的节点可能增加延迟。TUN 的作用是扩大可接管范围，不是自动提供游戏加速；游戏服务条款和反作弊限制也需要单独确认。

DNS 处理：区分代理解析与系统解析

系统代理与 TUN 的另一个关键差别，是域名查询经过哪里。使用 HTTP 代理访问 HTTPS 网站时，应用可以把目标域名交给代理处理；但应用自己的预解析、其他后台连接和安全 DNS 功能，仍可能采用不同路径。因此，“网页已经代理”不能证明所有 DNS 查询都采用相同出口。

TUN 可以配合 DNS 接管，把符合条件的 53 端口查询交给内核 DNS 模块。mihomo 中常见的 dns-hijack 就用于这类处理。它不是任意加密 DNS 的解密器：应用自行发出的 DoH 使用 HTTPS，DoT 通常使用 853 端口，不能期待一条针对 53 端口的配置自动识别并改写它们。

mihomo 配置片段如何阅读？

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

这是用于解释字段的局部片段，不是一份可独立运行的完整配置。auto-route 用于自动设置相关路由，auto-detect-interface 用于自动检测出口接口。listen 中的 1053 是本地 DNS 监听端口，不是节点端口；DNS 接管与这个监听端口也不是同一个概念。

Fake-IP 模式会给域名分配映射地址，再利用映射关系处理后续连接。198.18.0.1/16 属于这里使用的地址池，不是实际网站服务器地址。已有配置还需要合适的上游 DNS 等设置；不要把片段直接覆盖到订阅文件中，也不要在同一层重复添加第二个 dns 或 tun 键。

启用顺序：先建立基线，再增加 TUN

同时打开系统代理和 TUN 并非必然冲突，但也不能据此推断效果翻倍。HTTP 代理连接和虚拟接口接管可能同时存在，客户端通常需要正确处理自身流量与路由排除。排障时只保留一种入口，更容易判断问题发生在哪一层。

  1. 确认节点和配置：导入订阅，选定一个节点，使用 Rule 模式，先通过系统代理完成一次网页访问。
  2. 记录本地端口：在客户端中确认 HTTP、SOCKS 或混合端口，不把控制面板 API 端口误当作代理端口。
  3. 准备服务权限：按客户端说明安装服务或完成授权，关闭其他正在接管网络的代理工具。
  4. 单独测试 TUN：暂时关闭系统代理，开启 TUN，重新启动目标应用，观察连接列表和日志。
  5. 验证日常服务：检查网页、命令行、局域网设备及公司内网站点，确认规则没有误伤需要直连的地址。

Android 客户端通常通过系统 VPN 接口接管流量，同一用户下通常只能有一个处于活动状态的 VPN 服务。这与电脑上填写 HTTP 系统代理不是同一操作。iOS 的网络扩展也有独立机制，不能把桌面端 YAML 字段与开关位置直接照搬到移动端。

TUN 开启后无法上网，按现象缩小范围

系统代理正常，只有 TUN 失败

  • 检查服务是否运行，以及日志是否出现创建接口、设置路由或权限错误。
  • 检查其他 VPN、虚拟网卡和安全软件是否同时修改路由；一次只停用一个因素，再重新测试。
  • 核对 IPv6 接管设置。不要因为 IPv4 请求成功，就认定所有连接都已进入同一路径。

部分网站正常，部分应用报域名错误

  • 检查 DNS 模块是否启用、上游是否可达，以及应用是否配置了独立 DoH。
  • 检查 Fake-IP 过滤与直连规则，尤其是局域网域名、企业内部域名和依赖真实地址的服务。
  • 对照连接日志确认问题是解析失败、规则选错，还是节点连接失败，避免把所有超时都归因于 DNS。

退出客户端后仍然无法联网

先正常关闭 TUN 和系统代理，再退出客户端。若程序异常退出，检查系统代理是否仍指向已停止监听的 127.0.0.1:7890，以及原有 VPN 或网络服务是否已经恢复。重启相关网络服务或系统前，保存工作内容；不要在没有记录原设置的情况下批量删除路由。

如果仍然无法定位，可继续查看无法上网排查与配置文件检查。提交日志时，隐藏订阅链接、节点密码和访问令牌，只保留出错时间、内核信息、报错行与复现步骤。