Clash 客户端里的“已连接”，可能只代表内核已启动、系统代理开关已打开，或者 VPN 接口已建立，并不等于目标网站已经访问成功。节点延迟有数字，也只能证明某一次探测请求完成。排查时需要把链路拆开：应用是否进入代理、规则是否选对出口、节点能否建立连接、域名是否解析正确。

01｜先确认基础网络与故障范围

先关闭系统代理和 TUN，再打开一个平时可以直连的网站。如果仍然失败，应先处理 Wi-Fi、网线、路由器、运营商或校园网认证；此时反复更新订阅通常没有帮助。酒店、机场等网络还可能要求先在浏览器完成门户认证，代理会让这一步绕远路。

  1. 分别测试一个常用国内网站和原先失败的目标网站，记录是全部失败还是仅部分失败。
  2. 用手机热点替换当前网络，并保持同一个客户端、配置和节点。热点正常而原网络失败，优先调查原网络限制。
  3. 确认系统时间、时区与日期正确。明显错误的时钟会引发 TLS 证书有效期错误。

不要仅凭 ping 判断网站是否可用。目标可能禁止 ICMP，而浏览器实际使用 TCP 443 或 QUIC。反过来，IP 能 ping 通，也不代表 HTTPS、证书和代理链路都正常。

02｜检查订阅有效期与配置是否真正加载

打开客户端的“订阅”或“配置”页面，手动更新当前订阅，再查看更新日志。重点区分下载成功、解析成功与配置切换成功：订阅地址返回了内容，不代表这份内容就是内核接受的 YAML。返回登录页面、额度提示或错误文本时，配置解析可能直接失败。

  • HTTP 401 或 403：检查授权、订阅令牌及服务商账户状态，不能只靠状态码断言订阅过期。
  • HTTP 200 但解析报错：确认返回内容类型、订阅格式，以及客户端内核是否支持其中的协议和字段。
  • 列表仍有旧节点：旧配置可以留在本地，节点存在不等于套餐仍有效；同时核对有效期与剩余流量。
  • 更新完成但节点没变化：确认当前激活的是刚更新的配置；使用 proxy-providers 时还要检查对应提供者的更新结果。

03｜检查节点连通性，不把延迟当通行证

固定选择一个节点，暂时避免自动选择组在测试期间换出口。对同一个目标连续测试 3 次，再换另一个地区或线路的节点做对照。如果只有一个节点失败，优先处理节点本身；如果同一服务商的所有节点均失败，则继续检查账户、网络和内核兼容性。

延迟检测通常请求某个测试 URL，成功只说明该 URL 在当时可达。目标网站可能有单独的访问限制，节点也可能只在高峰丢包。查看日志中失败的是“连接节点服务器”还是“节点访问目标”，两者不是同一层故障。

  • connection refused：连接被明确拒绝，核对服务器端口、服务状态或本地监听。
  • i/o timeout：连接或读写超时，需要结合报错中的地址判断是节点、DNS 还是目标。
  • TLS 握手失败：核对时间、SNI、协议参数和内核支持情况，不要直接关闭证书验证。

04｜对齐系统代理与 mixed-port

这是“客户端看起来正常，浏览器却没有请求日志”的高频原因。先读取当前生效配置中的 mixed-port，不要猜默认端口。下面以 7890 为例；若实际值为 7897，系统设置和测试命令也必须一起替换。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows 11 可在「设置」→「网络和 Internet」→「代理」→「手动设置代理」检查地址和端口；macOS 可在「系统设置」→「网络」→当前网络→「详细信息」→「代理」检查。由客户端管理系统代理时，优先使用客户端开关，避免两边来回覆盖。external-controller 是管理接口，不能拿来当网页代理端口。

用显式代理绕过浏览器设置

Windows 在终端使用 curl.exe；macOS、Linux 将命令名换成 curl。下列命令最多等待 20 秒，输出响应头，不下载完整网页：

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

收到 HTTP 响应说明请求至少到达了一个 HTTP 响应端；403 并不等于页面可正常使用。若出现 200 Connection established 后又报 TLS 错误，只代表代理隧道已建立，还不能判定 HTTPS 成功。如果显式代理成功而浏览器失败，重点检查浏览器代理、扩展和安全 DNS；如果本地端口都连不上，先查内核与监听。

# Windows PowerShell：查看 7890 端口监听进程
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux：查看监听端口和进程
ss -lntp 'sport = :7890'

# macOS：查看监听端口和进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

确认端口由当前客户端内核占用。若另一个程序先占用了端口，应关闭冲突程序或更改代理端口，不要看到一个进程号就直接结束进程。

05｜检查应用是否绕过了系统代理

系统代理不是覆盖所有程序的总开关。部分游戏、命令行工具和自带网络栈的软件不会读取它；浏览器扩展也可能使用独立代理配置。判断依据是：请求发出时，客户端“连接”页面或日志中有没有对应目标记录。

  • 浏览器：暂时停用代理切换扩展，并确认没有单独设置 SOCKS 地址或绕过列表。
  • 命令行：检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY，防止旧端口或排除规则覆盖预期。
  • Firefox：在「设置」→「常规」→「网络设置」→「设置」检查是使用系统代理，还是手动代理。

在 PowerShell 中可用 Get-ChildItem Env:*proxy* 查看相关环境变量；在 macOS、Linux 中使用 env | grep -i proxy。输出可能包含认证信息，分享前先脱敏。不要同时启用多款 VPN、代理扩展和网络加速工具，否则数据包像在换乘，排查记录却没有站名。

06｜检查 TUN 权限、服务与路由接管

若显式 HTTP 代理正常，只有开启 TUN 后断网，说明节点未必有问题，应转向虚拟网卡、路由和权限。Windows 客户端通常依赖服务模式或管理员权限；Linux 需要相应网络管理权限；macOS 需要按客户端要求授权网络组件。权限要求应以当前客户端说明为准。

  1. 关闭 TUN，确认系统代理或显式代理能正常访问，建立对照组。
  2. 检查内核日志是否出现创建虚拟网卡失败、权限不足、添加路由失败等错误。
  3. 暂时退出其他 VPN、虚拟组网软件，再启用 TUN，观察默认路由是否改变。
  4. Android 在系统“设置”中搜索“VPN”，确认当前授权给目标客户端；常驻 VPN 与阻止非 VPN 连接的组合也可能影响切换。

mihomo 的 tun.enable、auto-route 与 dns-hijack 分别涉及接口启用、路由和 DNS 接管；开了第一个不代表其余环节自然正确。客户端可能会合并生成这些字段，应检查最终运行配置，而不是只看订阅原文。

07｜检查规则模式、策略组与 REJECT 命中

在“连接”页面找到失败的域名，核对命中规则、策略组和最终节点。规则按顺序匹配，命中即停止；某个具体域名可能在前面被 DIRECT 或 REJECT 处理，后面的兜底规则根本没有执行机会。

可以短暂切换到全局模式，并明确选择刚验证过的节点。如果全局能访问、规则模式失败，重点检查规则顺序和策略组选择。全局模式只改变已进入内核流量的分流方式，不会让原本绕过代理的应用自动被接管；TUN 下的私网与路由排除也仍需单独检查。

# 规则片段：PROXY 必须是配置中真实存在的节点或策略组
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上例用于说明顺序，不是建议覆盖整份规则。若网页主域名正常、图片或登录失败，应继续查看关联的 CDN、API 和认证域名。修改后恢复规则模式，保留针对性修正，而不是长期靠全局模式掩盖错误。

08｜区分 DNS 失败、污染与加密解析绕行

日志出现域名解析失败、DNS 超时，或同一域名在不同网络得到明显异常的结果时，再进入 DNS 排查。CDN 本来就可能返回不同 IP，不能只因为两次结果不同就认定污染。应结合返回地址范围、连接错误与更换可信解析路径后的表现判断。

先确认查询发给了谁

# Windows：查看系统默认 DNS 的回答
nslookup example.com

# 仅当 mihomo DNS 实际监听 127.0.0.1:1053 时使用
nslookup -port=1053 example.com 127.0.0.1

# macOS、Linux：安装了 dig 时可指定相同监听端口
dig @127.0.0.1 -p 1053 example.com A

1053 只是示例，必须与最终配置的 dns.listen 一致。代理监听端口 7890 不是 DNS 端口。启用 fake-ip 时，返回 198.18.0.0/16 范围内的地址可能是预期映射结果，不代表解析坏了；关键是后续访问是否仍被内核接管。

  • 确认 dns.enable 已启用，上游解析器能够连接，且代理服务器域名的解析没有形成依赖循环。
  • TUN 的 DNS 劫持通常针对普通 53 端口查询，不能据此推断浏览器自带的 DoH 也被同样接管。
  • 暂时将浏览器安全 DNS、Android“私人 DNS”设为与测试方案一致的状态，一次只改一项，测试后恢复所需设置。
  • Windows 修改 DNS 后可执行 ipconfig /flushdns，随后重启浏览器；清空系统缓存并不保证清掉所有应用自身缓存。

respect-rules 会让 DNS 上游连接遵循路由规则，使用时必须同步考虑 proxy-server-nameserver 等引导解析设置。不要为了修一个域名同时堆叠多套 fallback 和上游，最后连哪台解析器回答都无法确定。

09｜检查 IPv6、UDP 与 MTU 的局部故障

如果主页能打开，但视频、登录或较大的资源一直转圈，就需要检查协议差异。先用相同节点和 URL 对照，而不是立刻重装客户端。系统有 IPv6 地址，不代表当前网络与代理出口都具备可用的 IPv6 路径。

现象对照操作判断边界
直连 IPv4 正常、IPv6 超时关闭 TUN 后，用 curl 的 -4 与 -6 对同一目标直连测试用于检查基础网络；不代表远端代理的地址选择
浏览器失败，TCP HTTPS 测试正常暂时关闭浏览器 QUIC 后复测若改善，再检查 UDP 支持与路由，不急于长期禁用
仅 TUN 下大资源卡住备份后将 TUN MTU 临时调为 14001400 是诊断候选值，不是所有网络的最优值

测试基础网络的直连命令可使用 curl -4 --noproxy "*" -I --max-time 20 https://example.com/，再把 -4 换为 -6；Windows 使用 curl.exe。这要求目标存在相应地址记录。若通过 HTTP 代理测试，-4 不会强制远端代理使用 IPv4 连接目标，不能混淆两种实验。

MTU 修改必须确认客户端确实应用了最终配置，并在重连 TUN 后测试。若没有改善就恢复原值。UDP 不通也不意味着所有网页都会失败，许多浏览器能够回退到 TCP，具体表现取决于网络与应用实现。

10｜用日志闭环，保留最小复现与恢复方案

前九项仍未定位时，开启短时调试日志，只重现一次故障，再恢复 info。日志需要围绕同一时间点阅读：应用连接、命中规则、所选节点、DNS 查询和最终错误应能串成一条链。仅截取最后一行“超时”，通常不足以区分本地监听、节点连接与目标响应。

提交问题前整理这六项

  1. 操作系统版本、客户端版本、mihomo 内核版本，三者分别记录。
  2. 当前是系统代理还是 TUN，实际 mixed-port 数值，以及是否同时启用其他 VPN。
  3. 同一 URL 的显式代理测试结果、浏览器表现与测试时间。
  4. 规则模式和全局模式的对照，包含最终节点，不只写策略组名称。
  5. 当前网络与手机热点的对照，故障是否随节点或网络改变。
  6. 脱敏后的相关日志和最小配置片段，删除令牌、密码、订阅链接及私有地址信息。

如需检查 YAML 语法与配置字段，可在使用相同内核二进制、正确工作目录的前提下运行 mihomo -t -f config.yaml。配置检查通过只代表配置能够被接受，不代表节点、DNS 上游和目标网络一定可达。涉及外部规则文件、数据库与相对路径时，还应确保测试环境与实际运行环境一致。

这十项排查的目标不是把每个开关都拨一遍，而是逐段证明链路是否可用：基础网络 → 有效配置 → 本地监听 → 应用接管 → 规则选择 → DNS 与出口。定位到哪一段失效，就只修哪一段；“重装后偶尔好了”可以结束一次故障，却很难解释下一次。