高防CDN的防护链路中，有一个容易被忽视的环节：源站健康检查。清洗中心拦截了攻击流量，但如果源站本身因为其他原因（如程序崩溃、数据库连接失败、磁盘写满）无法正常响应，用户请求即使通过了清洗也无法得到正确响应。
源站健康检查的目标是让CDN在源站故障时快速感知，并采取降级或切换策略，避免用户请求持续打向一个已经不可用的源站。本文拆解高防CDN源站健康检查的探测机制和故障判定逻辑。
一、健康检查的三种探测方式
源站健康检查通常采用三种探测方式，各有适用场景。
TCP探测。 边缘节点定期向源站的指定端口发起TCP连接请求，如果连接成功建立，说明源站的网络层和传输层可达。TCP探测的优点是开销小、速度快，但它只能判断"端口是否开放"，无法判断应用层是否正常。源站的服务进程可能还在监听端口，但内部逻辑已经出错。
HTTP探测。 边缘节点定期向源站发送HTTP请求，检查响应状态码和响应内容。HTTP探测能够感知应用层的健康状态——如果源站返回5xx错误或响应内容不符合预期，说明应用层出现了问题。HTTP探测的开销高于TCP探测，但准确性更高。
自定义探测。 对于有特殊健康检查需求的业务，可以配置自定义探测逻辑。例如，请求一个特定的健康检查接口，该接口返回数据库连接状态、缓存状态、队列状态等业务指标。自定义探测的灵活性最高，但需要业务侧配合开发健康检查接口。
二、故障判定的逻辑：连续失败与阈值
单次探测失败不能直接判定源站故障。网络抖动、瞬时负载高峰、探测包丢失都可能导致单次探测失败。因此，健康检查系统通常采用连续失败阈值来判定故障。
典型的判定逻辑是：连续N次探测失败（例如3次），或最近M次探测中失败次数超过阈值（例如5次中失败3次），才判定源站为故障状态。判定为故障后，系统会采取相应的切换或降级策略。
故障判定还需要考虑恢复判定。源站故障后，系统需要持续探测，当连续N次探测成功时，才判定源站恢复正常并重新接入流量。恢复判定的阈值通常比故障判定更保守，避免源站在尚未完全恢复时被重新接入，导致请求再次失败。
三、故障后的切换策略
源站被判定为故障后，高防CDN通常采取以下几种策略。
多源站切换。 如果业务配置了多个源站（如主备源站、多地源站），CDN会将流量切换到备用源站。切换的前提是备用源站处于健康状态，且数据与主源站保持同步。
静态降级。 如果所有源站都不可用，CDN可以返回缓存的静态版本或错误页面，而不是让用户等待超时。这种降级策略保证用户至少能看到一个响应，而不是无限等待。这与高防CDN动态内容加速中提到的缓存策略是相关的——边缘缓存的静态内容可以在源站故障时作为降级响应。
告警通知。 源站故障时，CDN系统应当立即向运维团队发送告警，包括故障时间、失败探测记录、影响范围等信息，帮助运维团队快速定位和修复问题。
| 探测方式 | 检测层级 | 开销 | 准确性 | 适用场景 |
|---|---|---|---|---|
| TCP探测 | 传输层 | 低 | 中 | 快速感知端口可达性 |
| HTTP探测 | 应用层 | 中 | 高 | 感知应用层健康状态 |
| 自定义探测 | 业务层 | 高 | 最高 | 需要业务指标的健康检查 |
四、健康检查与清洗链路的协同
源站健康检查与清洗链路是两个独立的环节，但需要协同工作。清洗链路负责过滤恶意流量，健康检查负责感知源站状态。两者的协同体现在：当源站故障时，清洗链路不应继续将流量回源到一个不可用的源站。
评估时需要确认：清洗链路是否感知源站健康状态？源站故障时，清洗链路是否自动停止回源或切换到备用源站？健康检查的频率和超时时间是否可配置？这些细节决定了源站故障时业务的实际可用性。
对于有高可用要求的业务，建议配置多个源站并启用自动切换。同时，健康检查的探测频率不宜过高（避免给源站造成额外负担），也不宜过低（避免故障感知延迟过长）。典型的探测间隔在10–30秒之间，连续失败3次判定故障。
五、结语
源站健康检查是高防CDN防护链路中容易被忽视的环节。TCP探测感知端口可达性，HTTP探测感知应用层状态，自定义探测感知业务指标。故障判定需要连续失败阈值，故障后需要切换或降级策略。评估时需要确认健康检查是否与清洗链路协同、是否支持多源站切换、是否提供告警通知。这些能力，比"是否支持健康检查"这个简单的勾选项更能说明高防CDN在源站故障场景下的业务连续性保障水平。
