节点显示超时却能用？健康检查地址与状态码怎么查

节点列表显示超时，网页却还能打开，先核对健康检查的目标地址、判定条件和更新时间，再确认网页实际用了哪个节点。一次检查失败，只能说明那次探测没有满足要求，不能直接推断所有应用都无法访问。

作者：小六｜资料核对日期：2026年10月26日

本文以使用 Mihomo 内核的客户端为例，重点解释 HTTP 健康检查。界面颜色、负数和“不可用”等提示的具体含义，要结合客户端说明与日志判断。

第一项：网页真的用了同一个节点吗？

先选择一个有问题的具体节点，对常用目标发起新请求，并查看连接记录中的最终出口。上层策略组的名字相同，不代表每次选中的具体节点相同。

如果浏览器走了直连，或者策略组已经换到其他候选，那么“网页能打开”还不能证明列表里那个超时节点可用。先把比较对象对齐，后面再看检查本身。

建议记下节点、请求时间、目标和最终出口。少量明确的新请求已经能提供线索，不需要把全部节点轮流测速。

健康检查会请求指定目标，它并不会同时访问你常用的所有网站。Mihomo 的代理集合文档单独列出了检查地址、间隔和超时等设置。

因此，同一个节点能访问目标 A，但对检查目标 B 失败，并不矛盾。应先核对完整地址与错误阶段，再判断是测试目标的问题，还是连接本身异常。

还要找到实际生效的设置位置：客户端手动测试、策略组检查和代理集合检查，不能只凭界面上都有“延迟”两个字，就当成同一项操作。节点通过 use 从集合引入时，也应检查集合自身的 health-check，不能只改策略组里的地址。

正常。HTTP 204 No Content 表示请求已成功处理，但没有响应正文，见 MDN 的 204 说明。检查地址没有显示一篇网页，本身不能作为失败依据，应查看实际状态码。

关键在于地址与预期是否配套。Mihomo 的策略组通用字段说明，设置 expected-status 后，响应状态必须符合所配条件，才会被视为可用；默认 * 表示不要求特定状态码。

例如，检查要求 204，目标却正常返回 200，就可能因为条件不符而未通过。这里是解释判定逻辑，没有代表任何服务的实测结果。

先查清目标应当返回什么。若目标实际给出登录页或错误页，仅仅放宽条件让它变绿，会减少检查提供的信息。反过来，对本来应返回 200 的目标坚持要求 204，也不能准确表达你的检查目的。

修改前保留原设置，每次只调整相关条件，再对照真实访问结果。绿灯与红灯都要结合检查范围解释。

两项控制的事情不同，下面的数字只是单位示例，不是通用推荐值。

这些定义可以在前述官方文档中核对。界面上的“超时”并不等同于节点永久失效，也可能是当前条件下没有在阈值内完成检查。

如果仅调整等待上限后通过，只能说明判定条件发生了变化，不能证明节点突然变快。比较前后结果时，应记录是否换过地址或阈值。

Mihomo 为组与集合分别提供懒惰检查设置。文档说明，默认启用的相关懒惰行为会使未使用的组或集合节点不持续接受对应检查。因此，列表里留下一个数字，不代表刚刚又测了一次。

查看测试时间，必要时按客户端支持的入口触发一次检查，并确认完成。刷新界面、更新订阅和完成节点健康检查，是需要分别核对的动作。

如果自动选择的表现与预期不同，可以接着看策略组选择指南；其中的自动选择示例也可对照官方 url-test 文档。

涉及证书时，可参考本站证书错误检查顺序。想比较节点表现，则继续看测速记录方法，把探测延迟与持续传输分开记录。

保留客户端版本、检查地址、阈值、状态码或脱敏错误，以及实际请求出口，通常已经足够展开交流。无需发送完整订阅或节点密码：Telegram 联系我