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 内置能力，但能补足原生健康检查的业务深度限制。
不复杂但容易忽略
