先区分流量入口与代理模式

系统代理和 TUN 回答的是“应用流量怎样进入 Clash 内核”；规则、全局、直连模式回答的是“进入内核后怎样选择出口”。两组开关不在同一层。开启 TUN 后仍可使用规则模式，国内网站匹配 DIRECT，其他目标按策略组处理；开启全局模式也不会自动让不读取代理设置的游戏进入内核。

本文配置片段面向 Clash Meta 后续发展的 mihomo 内核。Clash 是内核与客户端生态的常用统称，图形界面提供的功能取决于实际内核及操作系统。旧版 Clash 配置与现代 mihomo 的 TUN 字段不能直接视为完全兼容，先在客户端的内核信息中确认名称，再参考相应文档。

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

启用系统代理后，客户端通常向操作系统写入本地代理地址，例如 127.0.0.1:7890。遵守该设置的浏览器先连接这个端口，再由内核选择直连或代理出口。HTTPS 通常通过 HTTP CONNECT 建立隧道；系统代理本身不等于解密 HTTPS 内容，也不要求安装证书才能完成普通代理转发。

接管范围由应用决定

  • 浏览器：许多浏览器默认读取系统代理，但扩展、企业策略或浏览器独立设置可以覆盖它。
  • 命令行：curl、Git、包管理器是否采用系统设置，取决于工具及构建方式；显式参数或环境变量更便于核对。
  • 游戏与语音：不少程序直接使用套接字通信，不读取系统 HTTP 代理；仅打开系统代理往往不改变其 UDP 路径。

mixed-port 是同时接受 HTTP 与 SOCKS 代理连接的监听端口。以下配置表示本机应用可通过 7890 端口访问内核，不代表系统代理已经自动写入，也不代表其他设备能够连接该端口。

本地监听配置示例
mixed-port: 7890
allow-lan: false
mode: rule

系统代理的主要优势是变动范围较小：无需为普通网页代理新建虚拟网卡，关闭后通常只需恢复系统代理设置。它的边界也很清楚：应用不使用这个入口，内核就看不到相应连接。

TUN：通过虚拟网卡与路由接管连接

TUN 创建三层虚拟网络接口，接收操作系统路由到该接口的 IP 数据包。内核处理这些流量，再按规则建立实际连接。因此应用即使没有代理选项，也可能被接管。它不是让所有程序都学会 HTTP 代理，而是在更低的网络层改变流量路径。

在桌面系统中，创建虚拟网卡和修改路由通常需要管理员权限、特权服务或相应系统能力。Android 客户端通常借助系统 VPN 接口实现接管，同一用户空间一般不能同时启用两个此类 VPN。具体行为仍以平台和客户端实现为准。

mihomo TUN 字段示例

合并到现有配置，不是完整订阅
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • stack: mixed 选择 mihomo 支持的混合协议栈实现；不要仅凭名称判断它一定比其他栈更快。
  • auto-route 请求自动配置接管路由；auto-detect-interface 用于自动识别出口接口，具体支持与效果依平台而异。
  • dns-hijack 将匹配的传统 DNS 请求交给内核 DNS 处理，需要配套启用并正确配置 DNS 模块；示例没有覆盖所有加密 DNS 路径。

系统代理与 TUN 的差异对照

比较项系统代理TUN
进入内核的条件应用读取代理设置，或显式指定代理操作系统将对应数据包路由至虚拟接口
主要覆盖对象遵守代理设置的浏览器及其他应用包含不支持代理配置的应用，但受路由范围约束
UDP普通系统 HTTP 代理通常不覆盖；SOCKS UDP 需应用支持可接管 UDP，仍需节点协议及服务端支持转发
权限与系统改动主要修改用户代理设置通常涉及特权、虚拟接口及路由
DNS 排查重点应用本地解析还是交给代理解析DNS 接管、内核解析、加密 DNS 与 IPv6 路径
常见冲突代理端口错误、残留设置、应用独立配置其他 VPN、虚拟网卡、出口识别与路由重叠

两种方式都不会凭空增加节点带宽。TUN 还增加了数据包处理环节，资源开销受协议栈、系统、连接数量影响。若浏览器原本已经正确使用代理，单纯换成 TUN，不应预期下载速度自动翻倍或延迟必然下降。

游戏、终端与 UWP 的选择建议

网页与常规下载：先用系统代理

如果需求集中在浏览器和能够显式设置代理的下载工具，系统代理通常足够。先确认浏览器请求出现在连接面板，再查看命中规则及实际出口。某个网站打不开时，应先检查节点、DNS 和规则，而不是立即增加 TUN 这一层变量。

终端工具：少量工具优先显式指定

Windows PowerShell 中使用 curl.exe 可避免某些环境下 curl 别名带来的差异。以下两条命令分别通过 HTTP 代理和 SOCKS5 代理测试；第二条让代理端处理目标域名解析。端口必须与客户端实际监听值一致。

Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

如果只有 Git 或包管理器需要代理，可在该工具中单独配置；如果大量命令行程序、子进程和开发工具都需要统一接管，再考虑 TUN。环境变量只影响读取它们的进程，也可能需要重启终端后才生效。

游戏与语音：先确认 UDP 和区域需求

TUN 适合接管不提供代理选项的游戏，但“接管成功”与“游戏连接可用”是两步。节点协议、节点配置和服务端都需要支持所需 UDP 转发。还应查看游戏实际连接的服务器区域与命中策略，避免把原本可直连的近距离服务器绕行到远端出口。延迟测试显示 50 毫秒，不代表游戏服务器往返也会是 50 毫秒；这是数值含义示例，并非实测结果。

UWP 应用：区分代理设置与回环限制

Windows 上部分 UWP/AppContainer 应用会受到访问本机回环地址的限制。即使系统代理指向 127.0.0.1:7890，应用也可能无法正常使用它。TUN 可以避免依赖应用主动访问本地 HTTP 代理这一入口，但并非所有 UWP 网络问题都由回环限制引起。若使用客户端提供的回环豁免工具，只对确有需要且受支持的应用操作，不要把批量豁免当作默认步骤。

开启 TUN 后的验证与故障定位

建议先建立系统代理可用的基线，再单独验证 TUN。两者同时开启并不必然产生循环，但会让请求入口难以判断。尤其是显式配置过代理环境变量的终端，即使关闭系统代理，也可能继续通过本地端口访问。

  1. 确认原始网络。暂时关闭两种接管方式，检查本地网络、网关和直连网站是否正常，排除基础连接故障。
  2. 验证系统代理。打开系统代理，用显式 --proxy 请求核对 7890 监听端口、节点和规则是否可用。
  3. 只测试 TUN。关闭系统代理，清理测试程序的独立代理设置，再启用 TUN；用没有显式代理参数的程序发起新连接。
  4. 核对接管证据。在连接面板或日志中查找对应目标，检查规则、策略组和出口。Windows 可用 Get-NetAdapter 查看接口，用 route print 查看路由；不要仅凭托盘图标判断。
  5. 检查 DNS 与 IPv6。如果域名失败但已有连接仍正常，重点看解析日志。IPv4 正常而部分应用仍绕行时，应检查 IPv6 路由与配置是否一并覆盖。

有连接记录，但仍无法访问

这说明至少部分请求已经进入内核，应继续查看是否命中了 REJECT、选中了不可用节点，或服务端拒绝连接。UDP 游戏失败而 HTTPS 正常时，优先核对 UDP 支持，不要把 HTTP 测试成功当作所有协议都可用的证明。

完全没有对应连接记录

先确认面板连接到了当前运行的内核，再检查 TUN 服务权限、自动路由是否生效、应用是否绑定物理网卡，以及是否有另一个 VPN 抢占默认路径。Windows 上可通过「设置」→「网络和 Internet」→「代理」检查系统代理残留；该路径针对 Windows 11，其他版本的名称可能不同。

最终取舍：按应用覆盖范围选择

  • 只需要浏览器访问：系统代理起步，保持规则模式，确认本地端口和当前策略组。
  • 少量终端工具：优先显式代理参数或工具自身设置，便于分别验证和撤销。
  • 游戏、语音或不支持代理的应用：考虑 TUN，同时确认 UDP、DNS、IPv6 与路由范围。
  • 已有企业 VPN 或复杂虚拟网络：先评估路由冲突；系统代理影响面通常更容易控制。

选择依据是应用怎样联网，而不是哪个开关看起来更“全局”。保持一条已经验证可用的接管路径，每次只改变一个设置，再从连接记录和规则命中确认结果，通常比同时启用所有选项更容易定位问题。首次配置可先阅读入门指南，需要了解规则与配置组织时再查看新手到进阶。