技术帮助 · 发布时间：
业务流量清洗接入时的源站健康探测与切换判定，关键不是“探测失败就立刻切”，而是确认用户请求实际经过的链路是否可用，并限制误切和反复切换。可以把探测看作决策信号，而不是业务成功的绝对证明：探测目标、判定阈值和切换动作要一起设计。
先分清探测检查了什么
常见探测由浅到深包括 ICMP、TCP 端口连接和 HTTP/HTTPS 请求。ICMP 只能说明网络层有响应；TCP 能验证端口是否可建立连接；HTTP/HTTPS 则可检查指定路径是否返回预期状态或内容。对提供网页或 API 的源站，应用层检查通常更贴近真实服务，但也要避免依赖容易变化的页面内容。
探测应尽量经过与业务相同的清洗接入和回源链路。若探测直接访问源站内网地址，却让用户请求经由代理、防火墙或负载均衡回源，结果可能与用户体验不一致。HTTPS 场景还应核对主机名、证书校验及请求路径，不能只因端口 443 可连接就认定服务正常。
五项判定经验：从失败信号到切换动作
1. 选能代表业务的检查点
为 HTTP 服务设置轻量健康路径，确认应用进程和必要依赖能够完成最基本请求；若某项依赖故障会让核心业务不可用，检查中应体现这一点。反过来，若健康路径调用了非关键外部服务，短暂的依赖波动可能造成不必要切换。检查项要对应“用户是否还能完成关键操作”，而不是越多越好。
2. 用连续失败和多个信号降低误判
单次超时可能来自瞬时丢包、探测节点拥塞或维护操作。可将连续失败次数、探测间隔和超时时长组合判定，例如以数秒为间隔连续失败数次作为初始参考，再根据源站响应时间、网络抖动和服务恢复速度调整。不同探测点若同时失败，证据通常比单点失败更充分；但探测点应避免共用同一出口或故障域。
3. 将切出与切回分开设门槛
故障转移应及时，恢复却需要观察。源站连续成功几轮后，可先标记为待恢复，再确认错误率、响应时间和连接数稳定，最后逐步恢复流量。恢复门槛可高于切出门槛，形成“迟滞”，避免源站在临界状态时来回切换。具体观察时长视应用启动、缓存预热和连接建立情况而定。
4. 确认备用源站能接流量
备用地址有响应，不等于它有能力承接全部请求。切换前要核对服务版本、配置、证书、数据同步状态及可用容量；特别是有状态业务，还要确认会话处理和数据一致性策略。主动探测只能验证设定的检查范围，不能替代容量评估，也不能证明所有业务路径都正常。
5. 设计排空、验证和回退步骤
切换可能涉及连接复用、缓存和长连接，既要关注新请求是否转向健康源站，也要考虑旧连接如何结束。代理层通常能较快应用路由变化；若依赖 DNS 调整，客户端和递归解析器的缓存会影响生效时间，不能把配置修改时刻当作全网切换完成时刻。业务流量清洗接入时的源站健康探测与切换判定，还应预先写明谁确认结果、如何回退以及怎样通知相关人员。
上线前按步骤验证
- 列出主、备源站的地址、端口、健康检查路径和预期响应，并确认探测请求携带正确主机名。
- 在预发布或低风险时段验证健康、超时、连接拒绝和应用错误等场景，记录探测状态与路由变化。
- 逐项调整探测间隔、超时和连续失败阈值；一次只改一个关键参数，观察是否出现误切或切换延迟。
- 演练源站恢复：先确认探测恢复，再小比例导流并观察错误率、延迟和资源占用，稳定后扩大流量。
- 保存切换记录和回退条件。若备用源站也异常，应有暂停自动切换或转人工判断的明确机制。
常见问题
探测间隔设得越短越好吗？
不一定。间隔过短会增加探测噪声和请求量；过长则可能延后发现故障。应结合故障容忍时间、源站响应波动和切换系统的执行速度设定。
只探测首页可以吗？
如果首页不经过核心应用逻辑，可能出现首页正常而关键接口不可用。优先选择轻量且能代表核心服务的检查路径，必要时分层检查。
恢复成功一次就能切回吗？
不建议。单次成功只能说明某一时刻检查通过。先连续观察，再逐步导流，可降低短暂恢复后再次故障的风险。
怎样判断切换真正生效？
同时查看探测状态、路由或代理配置、实际回源目标及业务错误情况；若使用 DNS，还要考虑缓存和客户端行为。以用户请求的实际路径验证，比只看控制台状态更可靠。
归根结底，业务流量清洗接入时的源站健康探测与切换判定，应把真实业务检查、连续失败门槛、恢复观察和回退方案连成闭环。阈值没有适用于所有系统的固定值，先演练并根据记录调整，才能让切换既及时又可控。
