Clash 节点全红怎么办：区分测速失败与实际不可用
先确认“红”的含义
在 Profiles 中确认订阅更新成功，再查看代理组的测速 URL。部分节点只是不响应特定测试站点，并不代表业务流量完全不能走通。
三步复测
- 将测速 URL 换为稳定的 HTTPS 地址并保存。
- 选一个节点作为手动代理，打开两个不同网站；同时检查系统 DNS 是否可解析。
- 用手机热点重复测试。只有当前 Wi-Fi 全红时，重点检查路由器 DNS、IPv6 或企业网策略。
配置层检查
不要在一个代理组里叠加互相引用的 url-test 和 fallback。更新订阅后若旧节点仍显示，删除缓存的配置副本再导入。
诊断范围
“Clash 节点全红怎么办：区分测速失败与实际不可用”应先按可观察现象缩小范围：节点全红并不总是订阅失效。通过目标地址、DNS 和代理组设置判断真正原因。 记录发生时间、使用的客户端与系统版本、是否仅在某个网络或某个配置下发生。不要从单次测速、单个节点或一次重试直接推断根因，也不要在未备份配置时同时修改多个开关。
操作步骤
- 保留错误提示的非敏感部分，并记下当前客户端、系统、网络类型和最近一次成功时间；订阅链接、账号、令牌和个人网络标识不得写入截图或工单。
- 在受控条件下只改变一个变量，例如切换已知可用的网络、恢复一份已导出的配置，或暂时停用可能重复接管流量的另一个客户端；每次改动后回到同一个操作复测。
- 将结果归为“现象消失、现象不变、出现新错误”之一。前两类分别保留变更前后记录；出现新错误时立即恢复上一步，而不是继续叠加 DNS、代理模式、内核或系统权限改动。
验证与回退
完成调整后，以原始失败动作连续复测，并确认目标功能恢复而不是只看到界面状态改变。若复测失败，回退到已导出的配置或原先已知可用的客户端状态，再依据记录选择下一项检查。任何无法解释的证书、权限、路由或账户提示都应停止扩大改动范围并转交产品或网络管理员。
来源与适用边界
本文未绑定可逐条核验的外部案例，只提供本机侧可重复的诊断顺序，不把任何现象归因于特定服务商、线路或版本。若需要升级，应带着脱敏后的时间、错误文本和已执行步骤联系相应产品支持。
来源与更新
本文为本地诊断整理，未把它表述为某个公开个案的结论。执行前请以所用客户端和系统的当前官方说明为准。
排查顺序
- 记录症状确认客户端、系统、错误文本与发生范围。
- 低风险核对先检查本文对应的配置、权限、网络或版本条件。
- 复测与回退只改变一项；现象变化后再决定是否继续。
常见问题
全红是否表示所有节点失效？
不一定；测速 URL 不可达、DNS 异常或 ICMP/HTTP 被限制都可能造成全红。
应该一次测速多少节点？
先抽样 3 至 5 个节点，避免高并发测速造成误判。
确认结果、回退与日志
每次只修改一项并复测原始现象。若出现新错误，恢复导出的配置或关闭刚启用的开关；仍未解决时，请保留客户端与系统版本、错误文本、发生时间、已尝试步骤以及脱敏日志。
不要公开订阅地址、账号或完整连接信息。文中的命令与配置片段仅适用于其标注的客户端和系统；未提供命令时，请以来源中的官方界面或系统文档为准。
补充更新：先用一张表判断“红灯”是哪一层失败
简答：Clash 节点全红只说明健康检查未通过，不等于节点不可用。先手动选择单节点访问目标网站，再检查代理组的 url、timeout 和 expected-status；打不开时再排查 DNS、订阅与本地网络。
定义：“节点全红”是代理组健康检查未满足连接、超时或期望状态码条件的显示结果，不能单独证明实际业务连接已经失败。
先看速查表：红灯、网页和网络切换分别说明什么
如果你看到节点一片红，却仍能打开部分网页或播放内容，先不要删除订阅，也不要直接认定服务失效。健康检查只是代理组对指定地址发起测试；在 Mihomo 中，代理组的 url 是健康检查测试地址，timeout 控制等待时间，expected-status 可以限定期望的 HTTP 状态码。字段定义可查阅Mihomo 代理组配置文档。
| 现象 | 优先判断 | 下一步 |
|---|---|---|
| 测速红色，但目标网站能打开 | 健康检查地址、返回状态码或超时条件不适合当前网络 | 核对代理组的 url、timeout 和 expected-status |
| 测速红色，目标网站也打不开 | 可能是节点握手、节点域名解析、订阅状态或本地网络问题 | 换一个节点，并查看对应连接和内核日志 |
| 当前 Wi-Fi 全红，手机热点正常 | 问题更可能在路由器、DNS、IPv6 或企业网络策略 | 先用热点复测，再对比本地网络配置 |
| 批量测速红色，逐个测试结果不稳定 | 批量健康检查的请求量或测试条件可能影响观察结果 | 暂停连续批量测速，改为逐个节点、间隔复测并记录结果 |
这张表只能帮助分流，不能替代实际访问验证。判断链路是否真的可用，应以手动选择节点后能否访问实际目标网站为准，并确认连接记录中的上下行字节持续变化；仅出现一条连接记录，不足以证明链路已经建立并传输数据。
为什么 url-test 全红，实际连接却可能正常
以 url-test 代理组为例，内核会使用代理组配置的健康检查地址，对组内代理进行测试，再依据连接是否成功、是否超时以及是否符合 expected-status 等条件显示结果。Mihomo 文档将 url 定义为健康检查测试地址，将 interval 定义为定时测试间隔，并列出了 timeout 与 expected-status 等字段。
因此，测速请求失败与真实业务请求失败并不是同一件事：健康检查地址可能在你的网络中访问不稳定，测试超时值可能过短，或服务返回了与 expected-status 不一致的状态码。只要实际目标网站能通过同一节点访问，首先应把问题归到健康检查条件，而不是直接判定节点失效。
配置示例可以写成下面这样；其中 url、timeout 和 expected-status 都位于代理组字段中，不要把测速地址写到节点本身：
proxy-groups: - name: 自动选择; type: url-test; proxies: [节点A, 节点B]; url: https://www.gstatic.com/generate_204; interval: 300; timeout: 5000; expected-status: 204
示例中的地址和数值只是配置格式示意，不代表适合所有网络。实际修改后，应先保存配置、确认运行中的配置已重新加载，再进行一次单节点访问和一次测速对照。
不改订阅原文件：用扩展配置覆盖测速和 DNS
直接编辑订阅缓存文件，更新订阅后可能被重新生成；更稳妥的做法是使用客户端提供的扩展配置入口。Clash Verge Rev 官方文档说明，扩展配置可使用 YAML 对配置进行覆写或合并，并区分全局扩展与订阅扩展；其界面文案也列出了“Extend Config”和“Global Extend Config”等入口。可参考Clash Verge Rev 扩展配置文档。
- 修改代理组测速条件：打开 Profiles，找到正在使用的订阅，按当前界面进入右键菜单中的“Extend Config/扩展配置”，再写入对应的
proxy-groups字段。不同版本的菜单名称可能略有差异，以当前界面为准。 - 避免覆盖原订阅：不要把整份订阅复制后反复手改；只在扩展配置中覆盖需要调整的代理组字段，并先保存原配置作为回退副本。
- 验证是否生效：保存后重新载入配置，查看运行时配置或代理组显示的测试地址，再手动选择一个节点访问实际目标网站。
- DNS 只处理 DNS 问题：Clash Verge Rev 的设置文案包含“DNS Overwrite”和“Unified Delay”选项；DNS 覆写用于调整客户端 DNS 行为，不能直接修复节点握手失败。界面路径可能随版本变化，应以当前设置页面为准。相关字段可对照Mihomo DNS 配置文档。
如果使用扩展配置覆盖 DNS，可先从最小配置开始，例如只核对 nameserver、fallback 和 proxy-server-nameserver。Mihomo 文档明确说明，proxy-server-nameserver 专门用于解析代理节点域名；它解决的是节点服务器域名解析环节，不等同于健康检查地址本身的访问结果。
单节点仍打不开：按固定顺序排查实际连接
- 本地网络：关闭其他代理客户端，确认没有多个程序同时改写系统代理、监听相同端口或接管虚拟网卡。再用手机热点测试同一个节点。
- 系统时间：确认系统日期、时间和时区正常。时间认证只适用于部分协议或服务端校验场景，不能把它当成所有节点类型的通用原因。
- 订阅状态：确认订阅更新没有报错，节点列表不是旧缓存，配置中仍有节点地址、端口和必要的传输参数。若更新失败，可参考本站的Clash 订阅地址更新失败排查。
- 节点与日志：手动选择两个节点分别测试，查看与对应节点匹配的日志。遇到类似
dial、timeout或i/o timeout的信息时，记录发生时间、节点名称和网络环境，不要只看测速颜色。 - DNS 与 MTU：如果节点域名无法解析或连接建立后网页仍打不开，再检查 DNS；如果只有部分网站、长连接或大页面异常，再考虑 MTU、IPv6 和网络路径差异。本站已有Clash DNS 解析失败与 DNS 泄漏排查可继续参考。
- 系统代理、TUN 与权限：只有在内核日志显示连接已建立、但目标应用仍无法使用时，才检查系统代理开关、Windows 服务模式、TUN 权限和端口占用。单纯延迟测试全红，不能直接推出 TUN 权限有问题。
规则模式下，命中直连规则的网站显示本地出口属于正常现象。验证代理是否生效，应选择明确命中代理规则的目标，观察是否能访问目标网站，并用出口 IP 变化作辅助判断；不要只用国内直连站点下结论。
unified-delay 应该开吗：它解决的是比较方式，不是连通性
unified-delay 是 Mihomo 的顶层配置项。官方说明称，启用后会在计算 RTT 时消除不同代理类型因连接握手等差异造成的延迟差异。它的作用是让不同类型节点的延迟更容易比较，不是 DNS 修复开关，也不能把实际不可用的节点变成可用。定义见Mihomo 全局配置文档。
因此，节点全红时不要把开启 unified-delay 当作第一修复动作。正确顺序是先完成单节点访问、热点对照、订阅检查和日志定位；确认节点实际可用但延迟数字难比较时，再考虑启用它。
如果你一次点选大量节点进行测速，建议先停止连续批量操作，改成少量节点、间隔复测，并记录同一网络下的结果。这样可以减少测试条件变化带来的误判；如果单节点访问始终正常而批量测速始终异常，问题仍应优先归到健康检查方式或测试负载，而不是直接推断所有节点不可用。
本次补充的可复现排查记录
| 记录项 | 怎么做 | 如何解释 |
|---|---|---|
| 单节点访问 | 手动选择一个节点，访问实际目标网站，观察连接上下行字节 | 能持续访问且流量增长，说明该节点至少能完成当前业务连接 |
| 测速字段 | 核对代理组的 url、timeout、expected-status | 字段错误或测试地址不适配，可能造成红灯误报 |
| 网络对照 | 用当前 Wi-Fi 和手机热点测试同一节点 | 只有 Wi-Fi 失败时，优先查本地网络、DNS、IPv6 或企业策略 |
| 配置加载 | 使用扩展配置后重新载入，查看运行时配置 | 只改缓存副本且运行时未变化，说明修改没有进入当前内核配置 |
| 日志信息 | 记录与被测节点对应的 dial、timeout、i/o timeout 等信息 | 结合时间、节点和网络环境判断，不以红色图标单独下结论 |
更新于 2026 年 10 月 21 日。本文只补充健康检查、实际连接和配置排查方法；无法从客户端或内核日志确认的服务端状态，应以服务提供方的账户面板和服务条款为准。
常见问题
Clash 节点全红，但网页还能打开，算节点坏了吗？
不一定。全红只说明健康检查未通过，可能是测试地址、超时条件或状态码匹配问题。先手动选择同一节点访问实际目标网站，再核对代理组的 url、timeout 和 expected-status。字段定义可参考Mihomo 代理组文档。
为什么改了测速 URL，更新订阅后又失效？
直接改订阅缓存文件可能在更新时被重新生成。应使用客户端的扩展配置入口，把需要覆盖的 YAML 放到全局或订阅扩展中；Clash Verge Rev 官方扩展文档说明了这两类扩展及其执行顺序。
Clash Verge Rev 里怎么改测速 URL？
测速 URL 属于代理组配置字段，不是普通客户端里的独立“测速开关”。打开 Profiles，找到当前订阅，在右键菜单中查找“Extend Config/扩展配置”，以当前界面为准写入对应的 proxy-groups 字段，再重新载入配置。若只修改设置里的延迟测试选项，不一定会改变订阅代理组自身的 url。
DNS 会导致 Clash 节点全红吗？
可能影响节点服务器域名解析，但 DNS 不是唯一原因。Mihomo 将 proxy-server-nameserver 单独用于代理节点域名解析；健康检查还要结合代理连接、测试地址、超时和返回状态码判断。
unified-delay 能解决节点全红吗？
不能把它当作连通性修复开关。它主要用于消除不同代理类型在握手等环节造成的延迟差异，使 RTT 更容易比较；先完成实际访问和日志排查，再决定是否启用。
批量测速会把节点测坏吗？
不能仅凭全红结果这样下结论。批量测速会同时改变测试数量和时间条件，可能让结果更难解释；建议停止连续批量操作，改为逐个节点、间隔复测，并对照实际网站访问结果。没有服务端日志或公开公告时，不应推断存在封禁或限流。
常见问题
Clash 节点全红，但网页还能打开，算节点坏了吗？
不一定。全红只说明健康检查未通过，不能单独证明节点失效。先手动选择节点访问实际目标网站，再检查 url、timeout 和 expected-status。
Clash Verge Rev 里怎么改测速 URL？
测速 URL 属于代理组配置字段。打开 Profiles，找到当前订阅，在右键菜单中进入 Extend Config/扩展配置，写入对应的 proxy-groups 字段后重新载入。
DNS 会导致 Clash 节点全红吗？
可能影响节点服务器域名解析，但 DNS 不是唯一原因。还要结合代理连接、健康检查地址、超时和返回状态码判断。
unified-delay 能解决节点全红吗？
不能。它主要用于消除不同代理类型在握手等环节造成的延迟差异，改善延迟比较方式，不是 DNS 或连通性修复开关。
批量测速会把节点测坏吗？
不能仅凭全红结果这样推断。建议停止连续批量测速，改为逐个节点、间隔复测，并以实际网站访问和日志作为判断依据。
相关阅读
- Clash 订阅地址更新失败的排查顺序
- Clash DNS 解析失败与 DNS 泄漏排查
- 节点超时和网页打不开的分层排查
- Clash 无法设置系统代理时的权限与端口排查
- Clash YAML 配置报错的检查方法