CDN回源健康检查该访问什么：静态200与业务就绪的差别

一个始终返回200的静态文件，可以证明某条请求路径还能返回内容，却未必证明应用已经准备好处理登录、查询或订单。健康检查的价值取决于它要支持什么决策：提醒值班人员、停止向某个实例送流量，还是触发重启。不同决策不应共用一个含义模糊的结果。

为每个检查结果写一句解释

Kubernetes探针文档明确区分了存活与就绪：暂时不适合接流量，不一定意味着应杀死进程。这里借用其职责划分帮助设计检查，不表示CDN平台具备相同机制。

检查路径必须到达想验证的组件

如果探测请求命中了CDN缓存，源站宕机时也可能继续拿到200。若目的是检查源站，应确认请求是否实际回源、缓存策略是否符合预期，并查找对应日志。反过来，验证边缘公开内容可用性时，缓存响应可能正是需要检查的对象。

同时记录探测使用的域名、Host、TLS名称、端口、路径与认证条件。探测默认站点成功，不能证明真实业务虚拟主机成功；探测被登录跳转带到另一个页面，也不能被简单算作业务就绪。

依赖检查应该有范围

应用可以检查处理请求必需的配置和关键依赖，但不宜每隔几秒执行一次完整重任务。检查本身若消耗大量数据库连接，会在压力期间进一步加重问题。返回内容只需表达必要状态，详细内部错误留在受控日志中。

对非关键依赖，应先明确是否允许降级。比如推荐服务不可用时，首页仍可能提供主要内容；是否摘除实例，应由业务恢复策略决定，而不是把所有外部依赖都串成一个“全部成功才健康”的判断。

避免在临界状态反复切换

在平台支持的范围内，核对探测周期、超时、连续失败判定和恢复判定。数值要依据正常响应分布及可接受恢复时间讨论，本文不提供通用阈值。一次短暂抖动是否足以触发切换，应通过受控演练验证。

演练至少覆盖应用启动未完成、单实例故障、共享依赖故障和恢复阶段。特别检查所有源站同时异常时平台如何处理，不能只测试“坏一台、另一台正常”的理想情况。

怎样确认设计真的有效

保存每次探测结果与流量动作的对应关系，并验证切换后的业务结果。恢复时除了检查200，还要确认数据状态、会话和缓存是否正确。健康端点不应泄露连接串、内部地址或密钥。

若所用SCDN套餐没有自动健康切换能力，应采用明确的监测与人工处置流程，不在文档中假定功能存在。把这些条件列入灰度上线和回滚验收，可以减少“检查全绿、用户仍失败”的盲区。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。