源站多线路冗余与故障自动切换，不能只看备用线路是否连通。探测结果可能与真实用户请求不一致，而已有会话也未必能随线路切换迁移。上线前应分别验证健康检查、切换条件、会话状态和回切过程，再决定是否自动启用。
先确认探测测到了什么
健康检查要回答的是：用户实际依赖的服务是否可用，而非网卡或某个端口是否还在响应。比如，TCP 端口能够建立连接，不代表应用能正常处理请求；只检查首页，也可能漏掉登录、提交或读取数据时发生的问题。
设置分层探测
- 线路层：检查目标地址是否可达，帮助识别链路中断，但不能单独作为业务切换依据。
- 服务层：向源站的健康检查路径发起 HTTP 请求，并核对状态码或固定响应内容。该路径应轻量、稳定，不返回账号、密钥等内部信息。
- 业务依赖层：按需检查关键依赖是否可用。若探测路径依赖的组件与业务故障无关，可能造成误切；若完全不检查关键依赖，又可能漏报。
探测位置也要与用户访问路径相符。只有一个位置探测，可能把局部网络问题误判为源站故障。条件允许时，可由多个独立网络位置观察；若只有单点探测，应在切换策略中考虑这一限制。
把切换阈值和回切条件写清楚
故障转移的关键是容忍短暂抖动，同时避免持续把请求送往失效线路。可先用每隔数秒探测一次、连续失败数次后切换作为测试起点；例如间隔约 5 秒、连续失败 3 次，意味着判定通常要经历十几秒。实际时间受探测间隔、超时设置和调度方式影响，应以现场验证为准，不宜直接套用。
恢复也应设置连续成功条件，并在恢复后保留观察期，避免线路反复上下线造成频繁切换。首次上线可先告警或人工确认，再启用自动切换；同时记录探测结果、切换时间和触发原因，便于区分真实故障与探测误报。
会话保持是容易遗漏的风险
会话粘性只能帮助后续请求尽量落到同一后端，不能保证故障切换后会话仍然有效。若登录状态、购物车或任务进度只保存在原源站本机，切到另一源站后，用户可能需要重新登录，未提交的数据也可能丢失。
应区分已有连接与新请求：已经建立的 TCP 连接通常不会因路由切换而无缝迁移，可能中断并需要客户端重连；后续新请求则取决于负载均衡或路由策略。若服务使用 Cookie 粘性，需测试切换后备用源站能否识别会话；若按客户端地址保持，也要考虑地址变化、代理转发等因素。对必须延续的状态，应评估将会话放入共享存储，或设计可重试、可恢复的请求流程。
上线前按步骤演练
- 列出主、备源站及各自服务地址，确认配置一致、证书有效、数据状态符合切换要求。
- 从实际探测位置分别验证线路、服务路径和关键业务请求，记录正常响应与故障响应。
- 在测试环境模拟主线路不可达、应用无响应和短暂抖动，确认触发时间、切换目标及告警内容。
- 验证已有登录会话、进行中的请求和长连接，明确哪些会中断、哪些能重试或恢复。
- 模拟主线路恢复，检查回切是否有观察期，并确认切换和回切操作均有记录及人工接管办法。
只有探测逻辑和会话处理都经过验证，源站多线路冗余与故障自动切换才不只是线路可达，而是能在可预期的边界内恢复服务。变更前保留回退方案，并把阈值、责任人和演练结果写入运行文档。
常见问题
健康检查能否直接访问首页？
可以作为基础检查，但首页正常不一定代表关键功能正常。更稳妥的做法是使用专用轻量路径，并补充关键业务验证。
切换后用户一定会掉线吗？
不一定。新请求可能转到备用源站，但原有连接通常无法迁移；会话是否延续取决于状态存储、重连机制和业务设计。
主线路恢复后要立即切回吗？
不建议只凭一次成功探测立即回切。应要求连续健康，并设置观察期，降低短暂恢复引发再次切换的风险。
