流量高峰时，负载均衡仍把请求送往“健康”节点：探针返回 200，下单接口却持续超时；探针也可能因管理端口拥塞被误判，摘除后正常业务反而下降。健康检查不能只选“活”或“死”，而要区分探针故障、业务故障与地域性异常，避免真实用户持续进入失效节点。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：数掘科技（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、探针故障不等于业务故障
主动探测偏差常源于检查对象与用户路径不一致。端口可连接只说明基础设施可达；探针若绕过关键依赖或地域 DNS，得到的可能是假健康。共享控制面拥塞也会让所有节点同时超时。因此要记录探测目标、源地址、耗时和返回码，区分网络与应用层错误，不能把一次抖动判为“不健康”。连续成功与失败序列也要保留，避免把间歇性抖动误判成稳定故障。
被动请求观测来自真实调用，能覆盖用户链路，但低流量节点可能没有样本。主动探测制造可控信号，被动观测确认业务影响，两者应按探针链路、节点进程、关键业务、用户地域分层判断，而非给实例贴标签。随身服务器可汇总探测、网关日志与地域延迟，定位故障边界，但指标须保留来源和时间窗。
二、用连续证据完成摘除与恢复
第一层看探测是否连续失败，达到连续失败阈值才进入疑似异常；第二层看错误集中于本节点，还是多地域同时失败；第三层看真实请求的错误率、延迟和成功率。只有节点信号恶化且业务影响得到确认，才摘除。阈值随流量调整：低流量服务需更长观察窗，高流量服务可更快隔离。样本过少时继续观察，不用低置信度结果直接摘除。
摘除不能“一刀切”。若所有节点共享同一探针路径，应先降权或暂停检查，而非全部摘除；若只有华南用户失败，应检查地域解析、跨区链路和可用区分布，避免区域异常扩散为全局故障。恢复时先少量回流量，观察成功率和业务错误率，再逐步放量；一层恶化就回退，并设置半开状态。
常见踩坑是：把 HTTP 200 当作业务正常，把一次 502 当作节点永久损坏，摘除后只验端口、不验关键接口。每次判定应记录时间、样本数、信号层级和动作，并用真实用户结果校验策略。这样才能让分层健康判定支撑故障摘除恢复，避免流量流向失效节点。
健康检查要判断的并非“某次请求是否成功”，而是实例在当前流量下能否稳定提供服务。主动探测能快速发现进程退出、端口失联等硬故障；被动请求观测更接近真实用户路径，可识别依赖超时、错误率升高和响应变慢。两者结合，才能同时兼顾发现速度与业务真实性。
用连续失败阈值控制摘除，用分层判定决定恢复
阈值不宜写死，应结合探测周期、请求量、故障时间和业务容忍度确定。连续失败阈值达到后才摘除，可过滤瞬时抖动；但连接拒绝、关键依赖超时等确定性故障，不应等待过多样本。更好的做法是设置分级健康判定：偶发失败进入观察，明确故障直接隔离，错误率超过基线且样本量足够时同样摘除。还要记录失败原因，避免把 DNS 抖动、证书过期和后端偶发 502 混为一类。
恢复也不能只看一次成功。应先在不放流或低权重状态下连续验证，再逐步恢复流量，并继续观察错误率和延迟。健康状态切换应设置迟滞与冷却期，防止实例反复进出，触发连接重建和流量震荡。故障摘除与恢复应形成可追踪的状态链，而不是简单地修改一个“健康”标记。
常见误区与可执行检查清单
最容易踩的坑是：检查地址固定返回 200，却没有触达关键依赖；探测频率过高，反而压垮目标；只统计失败次数，不区分取消、超时和 5xx；所有实例共用阈值，忽略流量差异；摘除后立即全量回池。多可用区环境中，还要排除代理连接池、熔断状态、DNS 缓存和证书问题造成的假故障。
检查时依次确认：核对协议、端口、路径、超时与期望状态码；对照主动、被动日志定位误摘和漏摘；确认阈值、样本窗口、最小样本数、权重、冷却期及告警均已生效；查看摘除、隔离、回池和再隔离记录；最后在低峰期做受控演练，验证流量迁移、容量余量和回滚方案。任何调整都应先小范围灰度，并观察业务错误率与延迟，而非只看负载均衡面板。
最终目标不是让面板永远显示绿色，而是让判定与用户体验一致：异常及时隔离，正常实例不被误伤，恢复过程可观察、可回滚。
喜欢 
顶
难过
囧
围观
无聊
