先分清：接管流量和选择出口是两件事

浏览器能打开网页，游戏却连接失败；Clash 已经切到“全局”，终端里的下载仍然直连。这类现象通常不是按钮失灵，而是流量根本没有进入代理内核。排查时先问“连接有没有进来”，再问“进来之后走哪条规则”。

  • 系统代理、TUN：解决应用流量如何进入内核的问题。
  • 规则、全局、直连：解决内核收到连接以后，选择哪个出口的问题。
  • 策略组与节点：决定最终由哪一个代理服务器，或由本机直连目标。

因此，开启 TUN 不等于全部连接都走代理。TUN 接入后，规则中的 DIRECT 仍然可以让连接直连。反过来，只切换“全局”也不会强制接管一个完全忽略系统代理的程序。

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

HTTP 与 HTTPS 请求怎样进入 Clash

开启客户端的“系统代理”后，客户端通常会修改操作系统的代理设置，让支持该设置的应用连接本机代理端口。路径可以简化成：应用 → 127.0.0.1:7890 → 内核匹配规则 → 直连或代理出口。

HTTP 请求可通过 HTTP 代理转发；HTTPS 通常先使用 CONNECT 建立隧道，再在隧道内进行 TLS 通信。普通 HTTPS 代理隧道不需要安装解密证书，Clash 也不会仅因开启系统代理就读取加密网页正文。

为什么有的软件完全不受影响

系统代理是一项供应用读取的设置，不是覆盖所有网络连接的强制开关。浏览器可能读取它，也可能使用扩展或自己的代理选项；命令行工具往往读取环境变量或专属配置；游戏则经常直接建立 TCP、UDP 连接。

  • Windows：在「设置」→「网络和 Internet」→「代理」查看用户代理。部分服务使用独立的 WinHTTP 设置，不能仅凭这里的状态判断。
  • macOS：在「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」查看；不同网络服务的设置可能不同。
  • Linux：桌面环境的代理选项、Shell 环境变量和应用自己的设置不一定互通，需要分别确认。

系统代理的优点是改动范围较小，便于按应用排查。如果日常只需要浏览器和支持代理的开发工具，先用这种方式通常更容易看清问题。

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

TUN 是三层虚拟网络接口。支持 TUN 的内核借助操作系统路由，把符合接管条件的 IP 数据包导入虚拟网卡，再识别其中的连接并交给规则引擎。应用不必主动理解 HTTP 或 SOCKS 代理协议。

这里仍有一个前提：数据包必须实际被路由到 TUN 接口。自动路由、排除网段、接口绑定、其他 VPN 的路由优先级，都会影响覆盖范围。不能把“TUN 已开启”理解为任何进程、任何接口的流量都必然被接管。

比较项 系统代理 TUN 模式
应用配合 应用需要读取系统代理，或手动填写代理 一般无需应用支持代理协议
主要接入位置 本地 HTTP、SOCKS 等监听端口 虚拟网卡与操作系统路由
UDP 流量 普通 HTTP 系统代理通常不能接管；SOCKS5 还需应用支持 UDP 转发 可接收被路由进来的 UDP，出口仍需支持
运行权限 通常只需修改当前用户的代理设置 通常需要服务模式、管理员或网络管理权限
常见故障 应用忽略设置、端口填错、残留代理 路由冲突、DNS 异常、权限不足、出口不支持 UDP

mihomo 的配置项应该怎样理解

Clash 是客户端与内核生态的常见称呼，Clash Meta 后续以 mihomo 名称继续发展。不同内核的功能并不完全一致。下面是 mihomo 的 TUN 配置片段，用来说明字段关系，需要合并进现有配置，而不是直接替换整份订阅。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • enable：启用 TUN，但操作系统权限仍需满足。
  • stack：选择协议栈实现。mihomo 提供 system、gvisor、mixed 等选项，实际支持情况以当前内核为准；没有一种对所有设备都最快。
  • auto-route：自动添加接管所需的路由，并不代表忽略所有路由例外。
  • auto-detect-interface：自动检测出站接口；同时运行公司 VPN 时仍需检查实际出口。
  • dns-hijack：这里的 any:53 用于接管匹配到的 UDP 53 DNS 请求，前提是请求已经进入相应接管路径。

桌面客户端可能会通过界面设置生成这些字段，订阅刷新也可能覆盖手工修改。优先使用客户端提供的 TUN 设置、配置覆写或合并功能，并确认最终生效配置。

DNS 差异：网页走代理，不代表解析也走同一条路

系统代理下，域名可能在哪里解析

DNS 的处理取决于应用与代理协议。HTTPS 的 CONNECT 可以携带目标域名，由代理端继续处理；但应用也可能提前调用系统 DNS。SOCKS5 同样可以传递域名，也可以传递已经解析好的 IP，关键在于应用选择哪一种。

这就是为什么同一个 SOCKS5 端口，使用 socks5:// 与 socks5h:// 的命令行测试可能结果不同：在 curl 中，后者明确让代理侧解析目标域名。不能仅凭公网出口地址变化，就认定所有 DNS 请求都已进入 Clash。

TUN 的 DNS 劫持与 Fake-IP 不是同一个开关

DNS 劫持负责把匹配的 DNS 请求交给内核 DNS 模块；Fake-IP 则是一种响应方式：先给应用返回映射地址，再由内核将后续连接对应回原域名。mihomo 常见的 Fake-IP 地址池是 198.18.0.1/16，实际以配置为准，它不是代理服务器的公网地址。

  • 使用前述 DNS 接管片段时，还需要检查现有 dns.enable、上游解析器和相关路由，避免 DNS 模块未开启。
  • any:53 不会自动解开浏览器的 DoH，也不会把 TLS 加密的 DoT 请求当成普通 DNS 解析。
  • 域名规则依赖内核掌握域名信息；若只看到目标 IP，匹配结果可能与预期不同。
  • 局域网设备发现、公司内部域名或特殊应用不兼容 Fake-IP 时，应有针对性地调整过滤与解析规则，而不是直接清空所有 DNS 设置。

按应用选择：浏览器、命令行和游戏分别怎么配

浏览器：先检查自己的代理选项

浏览器一般可以先使用系统代理。如果只有某个浏览器不生效，检查代理扩展、独立代理设置、安全 DNS，以及是否复用了切换前建立的连接。Firefox 可在「设置」→「常规」→「网络设置」→「设置」中确认是否选择“使用系统代理设置”。

命令行：显式指定端口，先做可重复测试

以下命令用于比较直连、HTTP 代理与由代理解析域名的 SOCKS5。Windows PowerShell 中建议写 curl.exe，避免旧环境把 curl 解释成其他命令别名。测试站点是否可达不能单独证明代理成功，还要同步查看客户端连接记录。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com
curl --noproxy "" --proxy socks5h://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

第一条绕过显式代理，但如果 TUN 正在接管，它依然可能进入 TUN。因此，验证系统代理时先关闭 TUN；验证 TUN 时再移除显式代理参数，避免把两种路径混在一起。

需要让当前 Shell 中支持环境变量的工具使用代理时，可以临时设置如下变量。它们只影响读取这些变量的进程，不等于修改整台设备的网络出口。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

这里 https_proxy 的值仍可使用 http://，表示通过 HTTP 代理建立 HTTPS 隧道。Git、包管理器和容器工具还可能有自己的代理配置。容器里的 127.0.0.1 指向容器自身，不能直接当作宿主机地址。

游戏与语音：重点检查 UDP 出口

游戏登录可能使用 HTTPS，对战和语音却使用 UDP。出现“能登录、进不了房间”时，不能仅检查网页。TUN 可以接入相关 UDP 数据包，但所选节点、代理协议、服务端与链路必须都支持相应 UDP 转发。

代理也不保证降低延迟。对战服务器所在地区、绕路程度、丢包和抖动，比节点名称更有参考价值。测试时固定服务器与节点，分别记录直连和代理的结果；不要把一次测速站的带宽数字当成游戏体验结论。

软件不走代理：按连接记录分成两条排查路径

  1. 建立最小测试环境。暂停其他 VPN、加速器和代理扩展，只保留一个客户端。先记录当前设置，涉及公司网络时先确认网络管理要求。
  2. 确认内核已启动。检查混合端口是否确为 7890。Windows 可运行 netstat -ano | findstr :7890 查看监听，但端口存在不代表监听者一定是当前客户端，还应核对进程。
  3. 只测系统代理。关闭 TUN，打开系统代理，使用浏览器或前面的显式代理命令发起新连接，同时查看“连接 / Connections”和“日志 / Logs”。
  4. 再单独测 TUN。关闭系统代理，启用客户端要求的服务模式或管理员权限，再打开 TUN。Android 通常使用系统 VPN 授权；Linux 通常需要相应网络管理权限，不能照搬 Windows 的操作入口。
  5. 查看命中规则和实际出口。已有连接记录却显示 DIRECT，优先检查规则顺序、进程匹配与策略组选项。规则按顺序匹配，前面的命中结果可能先于预期规则生效。
  6. 最后处理 DNS 与兼容性。如果日志出现解析超时、Fake-IP 映射异常或特定 UDP 失败，再针对这些现象修改配置，一次只改一项。
观察到的现象 优先排查方向
操作软件时，内核没有对应连接 应用忽略系统代理、TUN 路由未覆盖、进程或接口被排除
有连接，出口为 DIRECT 规则顺序、直连模式、策略组当前选择
有连接，代理出口超时 节点可达性、协议配置、服务端状态、目标限制
网页可用，游戏语音失败 UDP 接管与转发支持、相关域名解析、游戏专用规则
开启 TUN 后公司内网失联 VPN 路由冲突、内部 DNS、私有网段排除设置

连接面板可能因短连接很快结束而看不到记录，必要时打开日志再复现。分享日志前应移除订阅地址、访问令牌、节点凭据和私人域名；不要为了截图公开整份配置。

最终选择：按最小接管范围开始

只处理浏览器和少数支持代理的软件，先选系统代理；开发工具需要稳定、可复现的行为，优先配置工具自己的代理参数；游戏、语音或不读取代理设置的应用确实需要接管，再考虑 TUN。

系统代理与 TUN 可以同时开启，不是必然冲突，但诊断时最好拆开测试。遇到断网也不必立即重装：先关闭 TUN，确认路由恢复，再关闭系统代理，检查系统中是否仍保留指向已退出客户端的本地端口。若 TUN 已接收连接而出口不通，切换接管方式通常解决不了节点本身的问题。

记住一条排查顺序即可：入口是否接管 → DNS 是否正确 → 规则命中哪里 → 出口能否连接。这四步能把“代理开着却没效果”拆成可验证的问题。具体规则字段可继续查阅配置与协议手册，首次安装则从快速上手教程开始。