先给结论：区别在入口，不在是否“全局”

只需要浏览器和遵循系统代理设置的应用走代理，先用系统代理；需要接管不读取代理设置的命令行工具、游戏或其他 UDP 流量，再考虑 TUN。两者决定的是流量怎样进入 Clash 内核，而 Rule、Global、Direct 决定的是进入内核后怎样选路，不能把这两组概念混为一谈。

开启 TUN 后，规则命中 DIRECT 的连接仍然直连；开启系统代理后，选择 Global 也不会让所有进程自动读取代理设置。所谓“全局模式已经开启，游戏为什么没变化”，首先应检查游戏连接是否进入内核，而不是反复更换节点。

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

请求路径和本地端口

系统代理通常把 HTTP、HTTPS 等代理地址写入操作系统设置。愿意读取这些设置的应用，会先连接本地代理端口，再由内核根据目标地址和规则建立后续连接。以本地混合端口 127.0.0.1:7890 为例，路径是：

遵循系统代理的应用
  → 127.0.0.1:7890（HTTP / SOCKS 混合入口）
  → 内核规则与策略组
  → DIRECT 或选中的代理节点
  → 目标服务

这里的 7890 是示例，不是每个客户端都固定使用的端口。应在客户端设置或当前生效配置中核对 mixed-port、port、socks-port。HTTP 入口不能随意当成 SOCKS 入口使用；混合端口才同时接受这两种代理协议。

HTTPS、UDP 与浏览器扩展的边界

  • HTTPS：应用通常通过 HTTP CONNECT 建立到目标的隧道。普通代理转发并不意味着内核解密了网页的 TLS 内容，也不要求为了正常代理而安装根证书。
  • UDP：操作系统里的 HTTP 代理设置并不是通用 UDP 转发入口。SOCKS5 虽有 UDP ASSOCIATE，但应用必须主动实现，代理端和节点也要支持。
  • 浏览器：浏览器扩展、PAC 和自身策略可能覆盖系统设置。网页能打开不等于所有连接都进入同一入口，QUIC 等传输还要看浏览器具体实现与策略。
  • 终端：许多命令行程序读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，或者只接受自身代理参数，并不会自动跟随桌面系统代理。

Windows 11 可在「设置」→「网络和 Internet」→「代理」检查系统代理；macOS 可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」检查。这里只能证明设置已写入，不能证明某个应用确实采用了它。

TUN：通过虚拟网卡接收 IP 数据包

TUN 在网络层提供虚拟接口。客户端或内核配置路由，使符合条件的 IP 数据包进入这个接口；内核中的协议栈处理 TCP、UDP，再交给规则与出站连接。应用不需要专门支持 HTTP 或 SOCKS 代理，因此覆盖面通常比系统代理更广。

应用发出的 IP 数据包
  → 操作系统路由选择
  → TUN 虚拟接口
  → 内核协议栈、DNS 映射与规则匹配
  → DIRECT 或代理节点
  → 物理网卡发出最终连接

这也解释了 TUN 为什么需要更高权限：创建虚拟接口、修改路由、设置 DNS 劫持，往往涉及管理员、系统服务或 Linux 的相应网络权限。它不是单纯把代理地址换成了另一组端口。

TUN 不代表所有网络空间都已覆盖

自动路由有排除项，也可能被其他 VPN 的路由抢占。局域网、特定接口、IPv6、虚拟机和容器都要单独核对。尤其是 WSL2、Docker 与虚拟机，流量可能先经过独立网络空间或虚拟交换机；宿主机 TUN 已开，并不能直接推出这些环境里的 DNS 和路由也已正确。

覆盖差异：浏览器、命令行、游戏和局域网

场景 系统代理 TUN
浏览器 HTTP / HTTPS 通常可用，需排除扩展与 PAC 覆盖 路由接管后可进入内核，仍按规则分流
curl、Git 等终端工具 常需环境变量或显式代理参数 通常不需应用代理参数，但需检查实际运行环境的路由
游戏 UDP 与语音 普通 HTTP 系统代理通常不覆盖 可以接收 UDP，后续还依赖节点及服务端能力
局域网打印机、NAS 常通过系统绕过列表直连 需检查局域网规则、路由排除和防火墙
权限与改动范围 主要修改应用可读取的代理设置 涉及虚拟接口、路由及可能的 DNS 接管

对游戏而言，“TUN 已接管”和“游戏适合走这个节点”是两回事。节点需要支持 UDP，服务端也要允许相关转发；游戏区服、往返延迟、抖动、丢包和 NAT 行为同样影响体验。代理面板里一次 HTTP 延迟测试为 60 ms，不代表游戏 UDP 往返延迟也会是 60 ms，更不能据此判断语音是否稳定。

开启前检查：权限、路由、DNS 和节点能力

按顺序保存基线

  1. 记录当前状态：保存当前生效配置，记下系统代理端口、DNS 设置和其他 VPN 状态。需要远程维护时，先确认有恢复网络的备用方式。
  2. 确认内核：在客户端的内核信息或日志中核对是否使用 mihomo，以及其版本。不能仅凭客户端名字判断是否支持同样的 TUN 字段。
  3. 检查权限：按客户端提供的服务模式或权限提示操作。已安装服务却仍失败时，查启动日志中的接口创建、权限不足与路由写入错误，不要只重复切换开关。
  4. 暂时停用冲突入口：排查阶段先关闭其他 VPN 和系统代理，仅保留 TUN，避免两个入口同时存在而难以确认测试路径。
  5. 确认出口接口：切换 Wi-Fi、有线网络或热点后，检查自动识别的出口是否仍正确。错误出口可能引发连接失败，严重时还会形成路由回环。

mihomo 配置片段的含义

下面只演示 TUN 与 DNS 的关联配置，不包含节点、订阅提供器和完整分流规则，不能作为完整可联网配置。应把字段合并到现有配置中，避免重复创建顶层 dns 或 tun 键；由客户端管理的项目应优先使用客户端的覆写机制。

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
  nameserver:
    - https://dns.alidns.com/dns-query
  • stack: mixed 是协议栈选项，不是 mixed-port，也不是“同时开启系统代理”的开关。可用栈及其平台行为应以当前内核文档为准。
  • auto-route 让内核配置接管路由；auto-detect-interface 用于识别出站接口。多网卡和其他 VPN 环境仍需人工核对。
  • dns-hijack 的 any:53 用于接管进入 TUN 的普通 UDP DNS 请求；需要处理 TCP 53 时，应按当前内核支持情况配置 tcp://any:53。
  • 127.0.0.1:1053 是内核 DNS 监听地址，不代表操作系统 DNS 设置可以直接填写带端口的地址。
  • 198.18.0.1/16 是此处的 Fake-IP 地址池。返回合成地址不等于解析故障，前提是后续连接仍能回到保留映射的内核。

示例选择了一个具体的 DoH 上游，但上游是否可达仍取决于当前网络及 DNS 出站配置。不要在网络已断开的情况下连续更换多个 DNS 选项；先看 DNS 请求有没有进入内核，再检查上游解析与连接错误。

DNS 与 IPv6：TUN 开了仍直连的常见原因

普通 DNS 接管不等于覆盖加密 DNS

UDP/TCP 53 的劫持规则不能直接识别任意 HTTPS 连接里的 DoH 请求，也不能把 DoT 自动变成内核 DNS 查询。浏览器启用“安全 DNS”后，可能使用自己的解析路径；其连接本身或许仍被 TUN 接管，但内核不一定获得相同的域名映射信息。

如果域名规则命中异常，可以暂时关闭浏览器自定义安全 DNS，重新建立连接，观察内核能否记录域名与对应规则。确认原因后，再决定保留哪一种解析策略，而不是长期叠加多套无法解释的 DNS 设置。

IPv4 正常不能证明 IPv6 正常

目标同时提供 A 与 AAAA 记录时，应用可能优先使用 IPv6。若只验证了 IPv4 路由，IPv6 仍可能使用另一条路径。应分别查看 IPv4、IPv6 的测试结果、路由和连接记录；只有 IPv6 失败时，应检查本地 IPv6 连通性及内核相关配置，而不是认定节点整体失效。

Fake-IP 也需要完整路径配合：如果 DNS 已返回合成地址，应用连接却绕开 TUN，这个地址通常不能像真实服务器地址一样在公网访问。切换模式后出现部分应用持续失败，应先清理对应应用的 DNS 或连接缓存，并确认系统 DNS 没有残留指向已经停止的本地服务。

验证步骤：把“进内核”和“走代理”分开测

第一步：显式测试本地代理入口

先关闭 TUN，保持内核运行，使用下列命令明确访问示例混合端口。--noproxy "" 用来清空本次请求的绕过列表，避免 NO_PROXY 干扰。Windows PowerShell 中可将命令名写为 curl.exe，避免旧环境中的同名别名。

curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com

这个测试只验证显式代理入口和该次请求的出站链路，不证明系统代理已经生效，也不证明 UDP 可用。若此时失败，优先看端口监听、规则和节点，不要先排查虚拟网卡。

第二步：只保留 TUN，禁用本次请求的显式代理

关闭系统代理、开启 TUN，再执行以下命令。--proxy "" 禁用本次 curl 请求的代理设置，--noproxy "*" 表示不使用应用层代理；这并不会绕过操作系统的 TUN 路由。

curl -4 -I --connect-timeout 10 --max-time 20 --proxy "" --noproxy "*" https://example.com
curl -6 -I --connect-timeout 10 --max-time 20 --proxy "" --noproxy "*" https://example.com

应在客户端「Connections」或连接列表中查找对应时间的请求，再对照「Logs」查看规则、策略组和最终出站。有些界面会显示 TUN 入站类型；没有显示时，可结合虚拟接口计数和路由检查辅助判断。网页返回成功本身不是接管证据，因为它也可能本来就能直连。

第三步：使用实际应用验证 UDP

进入游戏区服或发起语音会话，记录测试时间，在连接列表中查找 UDP 连接、目标地址、规则和代理链。如果连接进入内核但命中 DIRECT，应调整对应规则；如果命中了节点却持续超时，再检查节点的 UDP 支持和服务端限制。浏览器测速与 ICMP ping 都不能代替这一步。

故障定位与回退：一次只调整一项

  • 浏览器可用，终端不通：系统代理场景先查终端环境变量与程序代理参数；TUN 场景先确认终端是否运行在容器、WSL2 或远程主机中。
  • TUN 一开就断网：先关闭 TUN 恢复基线，再查服务权限、虚拟接口创建、默认路由、物理出口和 DNS 上游；暂时退出其他 VPN，避免路由竞争。
  • 游戏进了代理但更卡：检查区服路径、UDP 丢包与抖动，比较同一时段的直连和代理结果。不要仅按 HTTP 延迟数字选择游戏节点。
  • NAS 或打印机不可达：核对局域网地址段是否命中直连、是否需要路由排除，并检查本地防火墙。DIRECT 是内核的出站决策，不一定意味着数据包完全绕过虚拟接口。
  • 退出客户端后网络异常：检查系统代理是否仍指向已关闭的端口，DNS 是否仍指向停止的本地监听，以及 TUN 路由和虚拟接口是否完成恢复。

最终选择可以很简单：应用愿意使用代理、需求主要是网页访问，就保持系统代理；需要覆盖非代理感知程序或 UDP，再启用 TUN，并把权限、路由、DNS、节点能力逐项验证。覆盖范围扩大不等于速度一定提高，能解释每一条连接的入口与出口，才算配置完成。