HTTP 健康检查怎么配
HTTP 健康检查通过指定路径与期望状态码判断后端是否可用：路径应指向一个轻量、稳定、不依赖外部组件的探活接口，并明确期望的响应码范围。探活接口如果返回重定向或鉴权失败，检查会直接失败并把后端摘掉，这类「业务正常但成员异常」的现象在排查时经常被误判为网络问题。
基本信息
| 检查路径 | 指向轻量探活接口，避免重逻辑与登录鉴权 |
|---|---|
| 期望状态码 | 按产品配置可接受范围，探活接口通常返回 200 |
| Host 头 | 可指定健康检查请求携带的域名，便于按域名区分后端 |
| 检查间隔与超时 | 与业务响应时间匹配，避免探活被应用处理耗时拖垮 |
| 常见误判 | 302 跳转、401 鉴权拦截、502 依赖不可用导致检查失败 |
| 是否跟随跳转 | 各产品行为不同，探活接口建议直接返回 200 不依赖跳转 |
典型使用场景
- 为 HTTP 应用提供比 TCP 探测更准确的健康判断（进程假死可被识别）
- 多域名后端共用一个组时，用 Host 头区分不同站点的健康状态
- 灰度期间快速判断新版本实例是否可以接流量
- 配合发布流程：实例启动完成并探活通过后才接入流量
- 把探活接口与业务接口分离，避免依赖数据库等外部组件
复现健康检查请求
复现健康检查请求
curl -sS -o /dev/null -w '%{http_code}\n' \
-H 'Host: api.example.com' http://10.0.1.10:8080/healthz
# 若返回 301/302：说明发生了跳转，检查网关或应用的重定向规则
# 若返回 401/403：探活路径被鉴权拦截，需要为探活路径加白名单
curl -sS -m 3 http://10.0.1.10:8080/healthz | head -3 # 查看返回内容返回值与判断
| 返回情况 | 含义与处理 |
|---|---|
| 200 | 健康，正常参与流量分配 |
| 301 / 302 | 发生跳转，检查是否配置了强制 HTTPS 或路径重写 |
| 401 / 403 | 探活路径被鉴权拦截，需要为该路径放行 |
| 404 | 路径配置错误或应用未部署该接口 |
| 超时无响应 | 应用卡住或探活接口依赖的下游不可用 |
探活接口要足够轻：只检查进程可用性与必要依赖，避免把数据库查询、外部 API 调用放进探活逻辑，否则外部抖动会被放大成整组不可用。
健康检查是否跟随重定向因产品而异，探活接口建议直接返回 200，不依赖跳转行为，避免不同产品与版本之间表现不一致。