凌晨两点，监控面板显示源站仍返回200，主动探测却连续超时；负载均衡把请求切到备站后，连接池很快被压满，原本的单点故障演变成全链路流量抖动。真正需要判断的不是“节点是否在线”，而是健康探测、真实流量与状态码基线如何共同证明源站已经不可用，并给出摘除、切换和受控回切依据。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：数掘科技（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
主动探测由探针按固定周期请求指定路径，记录连接耗时、响应耗时和返回状态。它适合快速发现端口不通、进程卡死等故障，但单次结果容易受到网络抖动、缓存命中或探针位置影响。因此，3秒超时并不等于源站必然故障，至少还要观察连续失败次数和失败比例。
被动探测直接统计真实用户请求中的超时、连接重置与异常状态码。它更接近实际体验，却会被低流量、重试机制和特定业务请求干扰。例如，某个只接受POST请求的接口若被GET探针访问，返回405并不代表服务异常。
状态码基线应来自该源站正常时期的业务分布，而不是简单规定“只有200才健康”。对于登录接口，未登录返回401可能正常，业务接口返回404也可能正常；真正需要关注的是5xx比例是否突破基线、错误是否集中出现，以及同类请求的成功率是否持续下降。三类信号相互印证，才比单一探针更可靠。
判定时应设置健康检查阈值：主动探测连续失败达到次数上限，或被动错误率超过业务基线，才把源站标记为不健康。推荐采用滑动窗口，同时观察错误率、延迟和样本量，避免一个超时请求就触发摘除。探针集中超时但真实流量正常时，可以先降权观察，而不是立即清空节点。
确认故障后，故障摘除应停止向该源站发送新请求，并保留短暂观察期，防止重试流量继续堆积。切换时还要校验备站容量、连接池余量和跨机房延迟；若备站也接近饱和，应启用限流或返回明确错误，不能把故障节点的问题原样复制到所有节点。
恢复后的回切不能立即进行。应先以小比例流量试探，并设置回切抑制：连续多个观察周期内错误率、延迟和主动探测均恢复到基线，才逐步提升流量比例。一旦指标再次恶化，立即退回原流量比例。必要时加入冷却时间和半开状态，防止节点在好坏之间反复切换。
常见踩坑包括只看200、固定一次失败即摘除、忽略业务状态码，以及把探针网络故障误判成源站宕机。在随身服务器上运行轻量探针时，也应区分探针出口与用户访问路径的差异。最终目标不是追求最快切换，而是在误判率和恢复速度之间保持稳定。
主动探测应由独立节点发起，访问能代表业务可用性的接口，而非只检查 TCP 端口。它确认节点能否稳定服务；被动探测统计真实请求中的连接失败、超时、5xx 与异常延迟，确认用户是否已受影响。判定不能只看一次失败，可组合连续失败次数、统计窗口和成功率下限，例如连续失败 3 次且窗口成功率低于 80% 才判异常，连续成功 2 次才恢复。多探测节点还应多数一致，避免单点网络抖动造成误判。
判定需区分连接失败、响应超时与业务错误：前两者多指向基础设施或链路，业务错误可能来自应用逻辑或依赖服务。健康检查阈值应按流量峰值与恢复能力分组配置；探测间隔过短浪费资源，过长无法止损，超时值应略高于正常耗时的 P99。若目标接口正常返回 4xx，仍须校验状态码；需要上下文的接口也要携带合法凭据，避免把配置问题误判为源站故障。
进入故障摘除后，负载均衡器应停止向异常节点分配新请求，同时保留日志、检查结果与依赖信息，确认问题来自节点、探测链路还是共享依赖。常见坑是：只看进程存活，未检查监听端口和后端队列；把重启当成恢复；摘除与缩容条件混用，导致节点刚被摘除又被误缩容。
回切不能采用“探测成功一次就全量恢复”。回切抑制应包含稳定期、冷却期和渐进放量：节点连续健康至少 60 秒后，先引入小比例流量，观察错误率与延迟，再逐级提升；异常时停止放量并重新摘除。回切前还要预热缓存、连接池和依赖服务，并确认上游容量，避免瞬时流量再次压垮节点。
检查清单：①探测走独立路径，接口与状态码正确；②主动、被动信号分开记录，明确失败次数、成功率、连续成功和切换延迟；③确认摘除后无新流量；④模拟超时、5xx、连接重置及探测点失联；⑤演练节点恢复但依赖未恢复；⑥配置回切的稳定期、冷却期、灰度比例与自动回退；⑦关联三方时间线。
目标不是盲目追求切换速度，而是让状态变化有证据、可回退。阈值调整后须经故障演练和真实流量复盘，防止恢复节点被过早接回，也防止业务抖动被放大成大面积切换。
