slb健康检查不支持自定义http状态码，需将业务逻辑映射到标准码（如200/503），并通过路径隔离、参数调优及外部系统兜底实现逻辑自定义。

SLB健康检查探针本身不支持直接返回自定义HTTP状态码（比如 299、499），它只识别标准 HTTP 状态码范围（如 2xx、3xx、4xx、5xx）并按预设规则判定成功或失败。但你可以通过合理配置健康检查参数 + 后端服务配合，实现“逻辑上的自定义状态判断”。

关键在于：把业务健康逻辑映射到 SLB 能识别的标准响应上，而不是让 SLB 解析非标状态码。

---

✅ 健康检查路径需暴露真实健康语义

后端必须提供一个专用的健康接口（例如 /health 或 /status），该接口不只返回 200 OK，而是根据实际业务状态决定响应内容和状态码：

• 健康时：返回 HTTP 200 + JSON 如 {"status":"ok","load":0.4}
• 轻度异常（如数据库延迟高）：仍返回 200，但 SLB 不感知内容 —— 此时需配合高级策略（见下文）
• 严重异常（如主库断连、核心缓存不可用）：主动返回 HTTP 503 Service Unavailable 或 HTTP 4XX

⚠️ 注意：SLB 的「健康状态返回码」设置中若只勾选 http_2xx，那返回 503 就会被判为失败；若同时勾选 http_5xx，则 503 反而变成“健康”——所以务必按业务意图反向配置。

---

✅ 利用健康检查域名与路径做灰度/环境隔离

不同集群可配置不同健康路径，实现差异化探测逻辑：

• 生产集群：/health?env=prod → 检查数据库连接 + Redis + 外部依赖
• 预发集群：/health?env=staging → 跳过外部依赖，只检查进程存活

只要后端能区分请求参数并返回对应结果，SLB 就能基于统一机制完成差异化判定。

---

✅ 配合高级参数控制灵敏度，避免误踢

自定义健康逻辑常伴随短暂抖动（如 GC、瞬时超时），需调优以下参数防止频繁震荡：

• 健康检查间隔时间：建议设为 5～15 秒（太短加重后端压力，太长故障发现慢）
• 健康检查超时时间：设为比后端 /health 接口 P95 延迟高 20%～50%，例如接口通常 300ms，这里填 500
• 健康检查阈值：连续成功 3 次才恢复服务（避免刚恢复就进流量）
• 不健康检查阈值：连续失败 3 次才剔除（容忍偶发超时）

---

✅ 真正的“自定义检查”要靠外部系统兜底

SLB 原生不支持执行脚本或调用 API 判断健康，但你可以：

• 在后端部署轻量健康代理（如 nginx + lua 或 sidecar），统一聚合多个子系统状态，再暴露标准 /health
• 用云监控 + 函数计算定时调用业务健康接口，异常时触发 SLB API 主动移除后端服务器
• 结合阿里云 ARMS 或 SLS，对 /health 日志做异常模式识别，联动告警与运维流程

这类方式不属于 SLB 内置能力，但能补足原生健康检查的业务深度限制。

不复杂但容易忽略