先选接管方式，再检查代理规则

  • 浏览器、普通网页请求：先使用系统代理，确认应用读取了操作系统的代理设置。
  • curl、Git、开发工具：先显式配置代理端口；工具不支持代理或需要统一接管时，再考虑 TUN。
  • 游戏、语音、UDP 应用：优先评估 TUN，并确认出站协议、节点服务端与网络路径支持 UDP。
  • 公司 VPN、容器、虚拟机并用：先检查路由和 DNS，避免直接叠加多个接管工具。

Clash Meta 目前通常指向 mihomo 内核生态。客户端界面负责导入订阅、管理配置和切换开关；内核负责接收连接、匹配规则和建立出站。系统代理与 TUN 是两种不同的流量入口，不是两套订阅，也不是两个节点。

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

系统代理开关通常把本地代理地址写入操作系统设置，例如 127.0.0.1:7890。愿意读取这项设置的应用，会把请求交给该端口。端口必须与客户端当前生效配置一致，不能把示例中的 7890 当作所有客户端的固定值。

mixed-port: 7890
allow-lan: false
mode: rule

这段配置让 mihomo 在混合端口接收 HTTP 与 SOCKS 代理请求，但它本身不会替操作系统开启系统代理。客户端的“系统代理”按钮负责另一半工作。系统代理界面通常填写的是 HTTP 代理端口，也不代表系统内每个程序都会自动使用 SOCKS。

浏览器为何通常能用

在常见桌面环境中，Chrome、Edge 通常读取系统代理。Firefox 则可能使用独立网络设置，可在「设置」→「常规」→「网络设置」→「设置」中检查是否选择“使用系统代理设置”。浏览器扩展也可能覆盖代理配置，排查时应检查扩展的代理权限。

终端为何经常仍然直连

终端中的程序各自决定如何访问网络，不能假定它们读取桌面代理设置。先使用显式参数测试，可以把“工具未使用代理”与“节点连接失败”分开：

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

如果需要在当前 shell 会话中使用代理，可设置下面的环境变量。这里的 HTTPS 请求仍通过 HTTP 代理的 CONNECT 隧道传输，因此 https_proxy 的值也可以使用 http://。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 测试结束后清除当前会话设置
unset http_proxy https_proxy

以上命令适用于常见的 POSIX shell，不是 PowerShell 语法。也不是所有程序都遵循这些环境变量；部分开发工具需要独立设置。若 SOCKS 测试需要把目标域名交给代理端解析，可使用 curl --proxy socks5h://127.0.0.1:7890，其中 h 表示由代理端处理目标域名解析。

TUN：通过虚拟网卡接收 IP 流量

TUN 在操作系统中建立三层虚拟网络接口，再配合路由规则把符合条件的 IP 流量送入 mihomo。应用可以像平常一样创建 TCP 或 UDP 连接，不必先理解 HTTP 代理协议。内核收到这些流量后，再按配置决定直连、阻断或交给代理节点。

与系统代理相比，TUN 的覆盖范围通常更大，但并不是所有网络环境下的“全部应用开关”。路由排除项、其他 VPN、网络命名空间、虚拟机网络与操作系统权限，都可能影响实际接管范围。

最小检查片段

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  • enable：请求启用 TUN；能否创建接口还取决于权限和运行环境。
  • stack: mixed：选择混合协议栈，通常由系统栈处理 TCP、gVisor 栈处理 UDP；它不是代理节点协议。
  • auto-route：自动配置所需路由，不应在与其他 VPN 冲突时盲目保留默认行为。
  • auto-detect-interface：辅助识别出站接口；多网卡、VPN 并存时仍需核对实际选择。
  • dns-hijack：将匹配的传统 DNS 请求送入内核 DNS 模块，不会直接解密应用内的 DoH 或 DoT。

Windows 通常需要管理员权限或客户端安装的服务组件，Linux 通常需要相应网络管理权限并具备 TUN 设备，macOS 则需要客户端对应的授权机制。不同客户端的菜单名称并不统一，应确认其“服务模式”或权限提示已经完成，再开启 TUN。不要把“开关已打开”当作“虚拟接口与路由已创建”的证据。

浏览器、命令行与 UDP 覆盖对比

流量场景 系统代理 TUN 模式
浏览器 HTTP / HTTPS 应用读取系统设置时可接管 路由覆盖时可接管
curl、Git 等命令行 常需参数、环境变量或工具配置 通常不必逐个填写代理端口
游戏、语音 UDP 普通 HTTP 系统代理通常不覆盖 可接收，但出站链路仍需支持 UDP
局域网与打印机 取决于代理绕过列表 取决于路由排除与直连规则
容器与虚拟机 通常需在各自环境设置 受虚拟网络拓扑与转发路径影响

UDP 能接管，不代表节点能转发

游戏与语音常用 UDP，浏览器的 HTTP/3 也使用 QUIC，通常运行在 UDP 443 端口。TUN 可以提供流量入口，但节点协议、客户端节点配置、服务端支持和运营网络必须同时满足要求。普通 HTTP 代理通常不能直接转发这类 UDP；支持 UDP 的 SOCKS 客户端则是另一条显式代理路径。

因此，“网页正常、游戏失败”并不必然是 TUN 出错。应先在连接记录中找到游戏的目标地址、协议和最终策略，再检查该节点的 UDP 能力。节点延迟测试一般只代表某个测试目标的请求结果，不能据此证明游戏 UDP 可达。

DNS、fake-ip 与规则匹配的关系

系统代理和 TUN 都需要处理域名，但信息来源不同。HTTP CONNECT、SOCKS 域名请求可以直接向代理提供目标域名；TUN 收到的则首先是 IP 数据包。若要稳定应用域名规则，内核需要通过 DNS 映射、嗅探等机制关联域名，而不是仅凭目标 IP 猜测网站名称。

在 fake-ip 模式下，内核可以向应用返回 198.18.0.1/16 范围中的合成地址，并保存它与真实域名的对应关系。连接进入内核后，再按域名匹配规则。这个地址段不是节点出口地址，不能用“DNS 返回保留地址”直接判断解析失败。

三个常见边界

  1. 应用自带加密 DNS：浏览器通过 HTTPS 查询 DNS 时，普通的 53 端口劫持不会直接读取查询内容。排查阶段可暂时统一使用系统 DNS，再比较结果。
  2. 旧 DNS 缓存：切换模式后，应用可能仍使用此前缓存的真实 IP 或合成地址。应重启测试应用，必要时刷新系统 DNS 缓存，然后建立新连接。
  3. 局域网名称：路由器管理页、NAS 和企业内网域名可能需要指定内网 DNS，或按实际域名设置 fake-ip 过滤；仅添加直连规则不一定解决解析问题。

Windows 可以用 ipconfig /flushdns 清理系统 DNS 缓存，但这不会自动清空所有应用内部缓存。若浏览器与命令行结果不一致，应分别观察它们的 DNS 设置和连接记录，不要一次修改 DNS、节点与规则三个变量。

按四个步骤验证接管是否生效

1. 固定规则与节点

先保留 Rule 模式，并手动选择一个可用节点。测试期间暂停策略组的自动切换，避免结果变化来自节点更换。记录客户端生效端口，例如 7890，同时确认订阅中的策略组名称与规则引用一致。

2. 单独验证系统代理

关闭 TUN，开启系统代理。打开一个新的浏览器连接，再运行前面的显式 curl --proxy 命令。检查连接面板中是否出现测试请求、匹配哪条规则、最终使用哪个策略。浏览器能访问而普通 curl 没有连接记录，通常说明命令行没有主动使用代理。

3. 单独验证 TUN

关闭系统代理，清除测试终端中设置的代理环境变量，再启用 TUN。若此前配置过 ALL_PROXY、all_proxy 或工具专属代理，也应一并检查。随后执行不带代理参数的命令，避免把显式代理的成功误认为 TUN 成功：

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

Windows 可用 route print，Linux 可用 ip route 与 ip rule，macOS 可用 netstat -rn 辅助查看路由。不同平台的自动路由实现不同，不要求都出现同一条默认路由；重点是虚拟接口已建立，目标流量按预期进入内核。

4. 核对规则与出口

先在连接记录中确认请求进入内核，再查看最终策略。若规则指定代理，可通过可信的 IP 查询服务比较出口；若规则指定直连，出口没有变化就是预期行为。单次网页打开、状态栏图标或节点延迟都不足以独立证明整条路径正确。

模式选择与故障恢复

系统代理和 TUN 可以同时开启吗？

可以，但排查时建议只保留一种接管方式。两者同时开启时，部分应用会先连到本地代理端口，其他应用走 TUN，连接入口变得不直观。正常配置下并不意味着同一个请求必然经过两次远端代理；真正需要警惕的是其他 VPN、错误的出站路由或 DNS 设置造成回环。

开启 TUN 后，NAS 或公司 VPN 不能访问

先关闭 TUN，确认原网络恢复，再检查局域网网段、企业 VPN 路由和内网 DNS。代理规则中的 DIRECT 决定内核如何出站，路由排除则决定流量是否进入 TUN，两者处在不同层次。需要按实际拓扑选择处理方式，不能随意把所有私有地址段都指向一个节点。

关闭客户端后仍无法联网

  1. 检查系统代理是否仍指向已停止监听的 127.0.0.1:7890，必要时关闭遗留的手动代理。
  2. 通过客户端正常关闭 TUN，确认虚拟接口和自动路由已撤销，再退出程序。
  3. 检查 VPN、网络接口与 DNS 设置，恢复测试前记录的状态；不要直接清空全部系统路由。

进一步配置前，可查看完整文档中的规则、DNS 与 TUN 说明。保留可恢复的原配置，每次只修改一个配置段，能够更快定位问题发生在哪一层。