测速成功只证明一条测试路径
看到 50 ms 或绿色延迟，不代表整个网络已经正常。自动测速通常只请求配置中的一个测试 URL；你要打开的网站可能命中不同规则、使用另一个策略组，或需要额外的登录域名与资源域名。测速也不是下载带宽测试。
mihomo 的 url-test 文档明确包含独立的 url 与测速间隔。先记下报错网站、客户端版本、代理模式、实际选中节点以及是否开启 TUN，再开始排查。
下文适用于 ClashFX、Clash Verge Rev，也可用于标准版 ClashX 的基础排错。mihomo 专有选项不能直接当作旧 ClashX / ClashX Pro 的通用配置。合盖之后才发生的故障，可接着看睡眠唤醒排查。
按症状选择下一步
| 现象 | 优先核对 | 不要急着做 |
|---|---|---|
| 只有浏览器打不开，其他应用能联网 | 浏览器专有代理 / 扩展、系统代理、浏览器 DNS 设置 | 不要直接重装所有客户端 |
| 所有走代理的应用失败，但直连可用 | 本地监听端口、真实节点、规则和订阅状态 | 不要只重复按测速按钮 |
| 某一个网站失败，其他代理网站正常 | 连接面板里的规则、目标服务状态和账户 / 出口限制 | 不要默认把整个 DNS 配置改掉 |
| 首页打开，登录或图片加载失败 | 登录、接口与静态资源域名是否走了不同策略 | 不要只给首页域名写一条规则就结束 |
| TUN 开启时失败，系统代理模式可用 | 路由、DNS / Fake-IP、另一个 VPN 或网络过滤工具 | 不要同时开启多个 TUN 测试 |
| 仅合盖唤醒后失败 | 先检查 Wi-Fi 和本地监听是否恢复，再看 TUN 数据路径 | 不要把每次断网都归咎于节点 |
确认代理端口真的在监听
先到客户端设置确认 HTTP 或 mixed 端口。下面的 7890 只是示例；不同配置可以使用不同端口。scutil --proxy 能看到 macOS 当前系统代理，lsof 则能核对监听进程。
scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN系统代理指向 127.0.0.1:7890，而这个端口没有监听时，浏览器连接会失败。若监听者是另一款客户端，也不能因为端口相同就认定请求进入了当前软件。先让目标客户端启动并完成配置加载，再核对端口，避免两个客户端相互覆盖设置。
终端中的 curl 通常不会自动按 macOS 图形界面的系统代理设置走代理，环境变量也可能另行指定代理。所以下一步会明确指定两种路径，避免“终端能开网站”被误解成“浏览器代理已生效”。
用同一个目标比较直连与指定代理
先在客户端中暂停 TUN 并记下原状态，才能比较真正的直连基线；--noproxy 只影响 curl 显式代理，不会绕过仍在运行的 TUN。把示例目标换成实际打不开的公开页面，不要使用包含订阅 token、登录凭据或签名参数的链接。
# 先暂停 TUN，并记录原开关状态；端口改为客户端实际 HTTP / mixed 端口
task_proxy_port=7890
task_target_url='https://example.com/'
# 直接路径：不使用 HTTP_PROXY / ALL_PROXY，也不使用系统代理
curl --proxy '' --noproxy '*' --connect-timeout 5 --max-time 20 \
-sS -L -o /dev/null -w 'direct HTTP=%{http_code} total=%{time_total}s\n' \
"$task_target_url"
# 指定本地代理路径：清空 no_proxy 对本次请求的绕过规则
curl --proxy "http://127.0.0.1:${task_proxy_port}" --noproxy '' \
--connect-timeout 5 --max-time 20 -sS -L -o /dev/null \
-w 'proxy HTTP=%{http_code} total=%{time_total}s\n' "$task_target_url"命令不修改系统设置，只发出请求。-L 跟随重定向；HTTP 状态码来自最终响应，HTTP=000 不是网站的真实 HTTP 响应，应结合 curl 的错误文字判断。参数含义可查curl 官方手册。
| 对照结果 | 说明与下一步 |
|---|---|
| 直连成功，指定代理失败 | 关注本地代理、节点出口、代理规则与代理侧解析 |
| 指定代理成功，浏览器失败 | 优先检查浏览器代理扩展、系统代理、缓存与浏览器自己的安全 DNS |
| 两种路径都失败 | 仍可能是目标站点、底层网络或各自解析问题；用第二个已知正常站点对照 |
| 提示 Failed to connect / connection refused | 先核对监听端口和进程，不能仅凭此断定远端节点失效 |
| 返回 403 或 429 | 目标服务可能拒绝请求或限流；确认服务状态、账户权限和出口策略，不是“完全没联网” |
查实际连接，不只查测速名单
打开客户端的连接面板或日志，再刷新失败网页。记录目标域名、命中规则、策略组和最终节点；某个节点测得延迟不代表这个网页正在使用它。自动组的名字一致，也不保证其实际选择一致。
- 检查是否意外命中 DIRECT 或 REJECT；查看自定义规则是否被前面的规则覆盖。
- 短暂切换到 Global 并选择一个具体节点，对同一目标重试。成功时说明原有规则或策略选择值得优先检查；失败时还不能排除 DNS、节点或服务限制。
- 恢复原来的 Rule 模式。只调整有证据指向的规则，不永久用全局模式掩盖问题。
- 登录、图片、视频等分别使用不同域名时，看各条失败连接，而不是只观察首页域名。
规则从上到下匹配的说明见mihomo 规则文档。本站的规则优先级指南可帮助检查顺序与兜底规则。
分清解析、TLS 与网站拒绝
scutil --dns 显示系统解析配置，但浏览器安全 DNS、客户端内部 DNS 和 TUN 的 Fake-IP 可能采用不同路径。dig 成功只提供一个解析线索，不足以证明浏览器和代理侧解析都正确。
如果客户端确实启用了 SOCKS 端口，可以用下面的对照让代理负责解析主机名；7891 同样只是示例。成功而其他路径失败时，应继续检查解析路径和规则，不能仅凭一次成功断定某个 DNS 服务有问题。
task_socks_port=7891
curl --proxy "socks5h://127.0.0.1:${task_socks_port}" --noproxy '' \
--connect-timeout 5 --max-time 20 -sS -L -o /dev/null \
-w 'HTTP=%{http_code} total=%{time_total}s\n' "${task_target_url}"出现证书验证或 TLS 握手报错时，核对系统时间、目标证书和网络拦截工具。不要把 -k 关闭证书校验当作修复。出现明确的登录、地区或账户限制时，按目标服务要求处理；客户端换一个按钮不能保证解除限制。DNS 配置选项可查mihomo DNS 文档。
恢复设置，留下可复现记录
排查结束后恢复原模式与 TUN 开关。一次只改一个选项，记录“改前现象、改动、改后结果”；若切换失败就回到原状态，不同时更换节点、DNS、规则与浏览器设置。
求助时提供客户端版本、macOS 版本、发生时间、公开目标域名、实际端口、命中规则和错误类别即可。截图与日志应隐藏订阅地址中的 token、节点密码、访问令牌和完整私人 URL。能证明请求停在哪一层的记录，比单独一张绿色延迟截图更有帮助。
常见问题
延迟是绿色，为什么不能保证网站正常？
测速请求的是指定测试 URL，业务网站可能走不同规则、节点和解析路径；目标服务也可能拒绝访问。延迟值不能证明整个业务链路正常。
curl --noproxy 能绕过 TUN 吗？
不能。它只控制 curl 显式代理的绕过行为。要比较真实直连与指定本地代理，应先暂停 TUN，并记录、恢复原来的开关状态。
dig 成功说明 DNS 没问题吗？
只能说明该次查询成功。系统解析、浏览器安全 DNS、客户端内部 DNS 与 Fake-IP 的路径可能不同，需要结合失败连接日志判断。
403、429 都是节点故障吗？
不一定。它们是服务响应，可能与权限、出口策略、限流或服务状态有关；应按目标服务要求核对，不当作本地端口无法连接。
资料来源与适用范围
资料核对日期：2026-10-04。版本功能以文中标注的稳定版或官方资料为准；网络排查需在自己的配置与环境中验证。