核心区别：应用主动连接代理，还是路由送入虚拟网卡

系统代理依赖应用配合，TUN 依赖操作系统路由。这是判断两者覆盖范围的起点。系统代理通常把本地 HTTP 代理地址写入系统网络设置；支持该设置的应用会连接 Clash 的本地监听端口，再由内核执行规则匹配。忽略系统设置、使用独立代理配置或直接创建网络连接的程序，可能不会进入这条路径。

TUN 则创建三层虚拟网络接口，让符合路由条件的 IP 数据包进入内核处理。应用不必知道本地代理地址，因此可以覆盖更多直接联网的软件。但“开启 TUN”不等于“所有流量都走远端节点”：路由排除项、其他 VPN、接口优先级与代理规则，仍会影响最终路径。

客户端、内核与订阅分别负责什么

  • 客户端：提供系统代理开关、服务管理、配置编辑与连接列表。不同项目的菜单名称和授权方式并不一致。
  • 内核：负责协议处理、DNS、规则匹配和 TUN 网络栈。Clash、Clash Premium 与 Clash Meta（后续使用 mihomo 名称）的功能不能直接视为相同。
  • 订阅：提供节点或完整配置。它可以影响策略组、规则和 DNS，但不能代替操作系统所需的虚拟网卡权限。

本文配置字段以 mihomo 为例。先在客户端的内核信息或启动日志中确认实际运行的内核，再核对字段支持情况；不要只凭应用名称判断 TUN 能力。

系统代理：适合浏览器，命令行需要单独验证

在 Windows 11 中，可以沿「设置」→「网络和 Internet」→「代理」→「手动设置代理」检查系统代理地址。假设客户端的 HTTP 或 mixed 监听端口是 7890，地址通常填写 127.0.0.1，端口填写 7890。这里的端口只是示例，必须与当前生效配置一致。

浏览器通常会使用系统代理，但浏览器扩展、独立代理选项和绕过列表可能改变结果。系统中的用户代理设置与 WinHTTP 配置也不是同一套机制，不能因为浏览器已经联网，就推断后台服务和所有桌面应用都会使用相同代理。

用 curl 区分“节点可用”和“系统代理被采用”

下面两条命令适用于 Windows 终端。第一条明确指定 HTTP 代理，第二条直接发起请求；第二条是否使用代理，还取决于环境变量等设置，不能把它当成必然直连的对照组。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --connect-timeout 10 -I https://example.com
  • 显式代理成功、普通请求失败：先检查终端环境变量与应用代理支持，不要立即更换节点。
  • 提示无法连接 127.0.0.1:7890：检查监听端口、内核状态和本地防火墙。
  • 本地代理已连上，随后 TLS 或远端连接失败：继续查看节点握手、DNS 与规则命中记录。

在 macOS 或 Linux 上，可以对单条命令设置环境变量，例如 HTTPS_PROXY=http://127.0.0.1:7890 curl -I https://example.com。变量名写的是 HTTPS 请求的代理配置，代理地址仍可采用 HTTP 协议；这不意味着本地监听端口必须启用 TLS。不同工具对大小写变量及 SOCKS 的支持存在差异，应以工具说明为准。

TUN 模式：覆盖更多连接，但需要权限与路由配合

TUN 接收 IP 数据包，内核通过网络栈处理 TCP、UDP 等流量，再按配置发起出站连接。它不要求游戏或命令行工具主动连接 HTTP 代理，因此适合无法配置应用代理的场景。客户端通常需要管理员权限、服务模式或相应系统授权，才能创建接口、调整路由和处理 DNS。

mihomo 的最小字段示意

以下是配置片段，不是完整订阅。它假定现有节点、策略组、规则与 DNS 模块已经正确配置。客户端可能通过覆写机制生成最终配置，应检查生效结果，而不是只修改可能被订阅更新覆盖的源文件。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • enable：启用 TUN 功能；创建接口失败时，先看权限与服务日志。
  • stack：选择网络栈实现。mixed 是 mihomo 的一个选项，不能直接套用到所有旧内核。
  • auto-route：自动设置接管所需路由，不代表覆盖所有接口和所有例外路径。
  • auto-detect-interface：辅助选择出站接口；同时运行多个 VPN 时仍可能需要人工检查。
  • dns-hijack：把匹配的 DNS 请求交给内核 DNS 模块；上例为 UDP 53 端口匹配，不包含所有加密 DNS。

场景对比：命令行、游戏与 UWP 应用怎么选

场景系统代理表现TUN 使用条件
浏览器网页通常可用，检查扩展与绕过项可接管，但仅浏览网页通常不必启用
curl、Git 等工具常需显式代理参数或环境变量依赖路由覆盖，可减少逐应用设置
UDP 游戏连接HTTP 系统代理通常无法覆盖需要 UDP 出站能力与正确规则
受隔离的 UWP 应用访问本地代理可能受回环限制可能避开本地 HTTP 代理路径，但仍需实际验证
局域网与企业资源可使用代理绕过列表需要核对局域网路由、DNS 和 VPN 冲突

游戏：先确认 UDP，再比较延迟

游戏下载通常是 TCP/HTTPS，游戏对局却可能使用 UDP；启动器下载成功不能证明对局连接已被接管。应在连接列表中按进程、目标地址和网络类型观察规则命中，再确认策略组最终选择的节点具备 UDP 能力。部分游戏还受 NAT、地区匹配与反作弊策略影响，TUN 不能保证改善这些条件。

节点列表中的一次 HTTP 延迟测试，也不能直接代表游戏延迟。可在同一服务器、相近时段分别记录直连与代理各 5 分钟的游戏内延迟和丢包。例如“网页探测 80 毫秒、对局 140 毫秒”只是两种测量对象的示例，不能据此判定配置错误；应比较相同指标的前后变化。

UWP：区分回环限制与网络故障

某些受 AppContainer 隔离的应用无法直接访问本机回环代理，需要按应用配置回环豁免。不要为排查问题批量放开所有应用；先确认目标应用是否受此限制，再使用客户端提供的工具或 Windows 对应管理方式。TUN 可能让应用不再直接访问本地 HTTP 代理，但不能保证解决登录服务、证书、应用自身 DNS 或远端区域限制。

DNS 与 Fake-IP：TUN 开关不是防泄漏结论

DNS 决定域名如何解析，也影响内核能否按域名规则匹配。Fake-IP 模式会为域名返回虚拟地址，并在后续连接中利用映射恢复域名信息；它不是远端节点，也不是加密协议。Fake-IP 与 TUN 经常组合使用，但二者不是同一个功能。

使用系统代理时，HTTP CONNECT 请求通常可以把目标域名交给代理处理，但应用仍可能自行预解析或使用独立 DNS。使用 TUN 时，传统 DNS 可以通过路由和 DNS 劫持进入内核；浏览器内置 DoH、Android 私人 DNS 或其他加密解析路径，不会仅因配置了 any:53 就被全部纳入同一解析策略。

  1. 确认客户端最终配置中的 DNS 模块已启用，并检查 enhanced-mode 与上游解析配置。
  2. 检查系统解析器、浏览器安全 DNS 与其他 VPN，明确哪些请求由谁处理。
  3. 改变模式后重新建立应用连接，必要时清理 DNS 缓存，避免旧解析结果干扰判断。
  4. 结合 DNS 日志与连接日志核对路径，不仅依赖检测网页显示的解析器地理位置。

检测页面出现本地运营商解析器，是需要继续调查的信号，不是完整结论。分流配置可能有意让直连域名使用本地解析；关键在于本应通过指定路径解析的域名，是否实际偏离了预期。

验证顺序：一次只改变一个接管变量

初次排查时，不建议同时切换 TUN、系统代理、DNS 模式和节点。变量过多会让“恢复联网”无法对应到具体原因。先固定一个已知可用节点，再按下面顺序检查。

  1. 验证本地入口：关闭 TUN，用显式代理参数访问测试地址，确认示例端口 7890 确实由当前内核监听。
  2. 验证系统代理：开启系统代理，用浏览器新建连接，观察连接列表是否出现目标域名以及匹配规则。
  3. 单独验证 TUN：暂时关闭系统代理与应用显式代理，启用 TUN 后重新启动目标应用，避免旧连接继续复用。
  4. 核对出站：查看命中的规则、策略组与最终节点。只看到连接进入内核，还不足以证明它走了远端代理。
  5. 检查业务结果：浏览器测网页，游戏测实际对局，终端测目标仓库或接口；不要用单一测速替代全部业务验证。

TUN 开启后断网

先关闭 TUN，确认基础网络能否恢复。随后依次检查接口是否创建、服务权限是否正常、默认路由是否被其他 VPN 抢占，以及 DNS 是否可达。若日志反复出现连接重试，还要检查节点服务器地址的解析和出站是否形成回环。不要用持续增加路由规则来掩盖接口选择错误。

局域网打印机或企业内网失联

记录实际内网网段，例如 192.168.10.0/24，再检查直连规则与路由排除设置。代理规则中的 DIRECT 表示进入内核后直接出站；路由排除则可能让数据包根本不进入 TUN，两者不是同一层操作。企业 VPN 还可能要求专用 DNS，不能只增加一个 IP 规则就认定排查完成。

选用建议：按覆盖需求增加复杂度

  • 主要访问网页：优先系统代理，配合浏览器连接记录检查是否生效。
  • 只需几个开发工具：优先为工具显式设置 HTTP 或 SOCKS 代理，配置范围清晰，便于复现。
  • 多个应用不遵循系统代理：考虑 TUN，重点检查权限、DNS、UDP 与局域网访问。
  • 同时运行企业 VPN：先确认组织网络要求，再测试路由与 DNS 共存，不要默认两个虚拟网络可以直接叠加。

稳定运行后，系统代理与 TUN 可以按客户端设计同时启用，但排错阶段应分开测试。两者同时开启不一定会重复代理，也不等于覆盖更完整；应用可能直接连接本地代理，而其他连接走虚拟网卡。保留一条清晰、可验证的接管路径，比单纯开启更多开关更重要。