健康检查协议选tcp还是http取决于后端暴露方式：纯端口监听用tcp（仅syn探测），web服务优先http（真实验证业务就绪）；需注意安全组放行clb节点网段（100.64.0.0/10）、http支持head方法、https监听下健康检查仍走http协议。
健康检查协议选 TCP 还是 HTTP？看后端服务暴露方式
如果后端是纯端口监听（比如 Nginx 未启用 HTTP、或自研 TCP 服务），必须用 TCP 健康检查——它只发 SYN，不依赖应用层响应；若后端是 Web 服务（如 Spring Boot、Node.js），优先选 HTTP，能真实验证业务是否就绪，避免端口通但进程卡死的假阳性。
常见错误现象：TCP 检查通过，但用户访问 502；HTTP 检查失败，但日志里没看到请求——大概率是安全组或 iptables 拦了负载均衡节点的探测 IP（阿里云为 100.64.0.0/10 网段）。
-
HTTP检查时，务必确认后端能响应HEAD请求（默认方法），否则切到GET；注意响应体超 8KB 会被截断，但不影响判断 -
HTTPS监听下不能校验返回码，健康检查实际走的是 HTTP 协议（CLB 内部解密后转发），所以健康检查域名和URI仍按 HTTP 配置 - UDP 服务只能选
UDP或TCP检查（后者测端口连通性），不能配HTTP
关键参数怎么设才不误杀也不漏判？
默认值看似省事，但在高并发或慢启动服务中极易出问题：比如 Spring Boot 应用冷启动要 15 秒，而默认 健康检查间隔 是 2 秒、响应超时时间 是 5 秒，结果还没起来就被标为不健康，流量全切走。
实操建议直接按场景套用：
- Web 类服务（Nginx、Tomcat）：
响应超时时间设 5 秒，健康检查间隔设 5 秒，健康阈值/不健康阈值都设 3 次（即连续 3 次成功/失败才变更状态） - 慢启动服务（含 JVM 预热、大缓存加载）：
响应超时时间拉到 15–30 秒，健康检查间隔加到 10 秒以上，避免刚启动就被踢出 - UDP 服务：
响应超时时间至少 10 秒（网络抖动影响大），且必须在 ECS 安全组放行 ICMP（PING 检查）或对应 UDP 端口
为什么改了配置没生效？三个隐蔽检查点
改完健康检查参数，后端服务器状态栏还是“不可用”，别急着重配，先盯住这三处：
- 后端服务器安全组是否放行了负载均衡节点网段？阿里云 CLB/NLB 节点源 IP 是
100.64.0.0/10，不是后端子网本身；ENS 边缘实例则需放行边缘节点所在 VPC 子网 - 后端服务是否绑定了
0.0.0.0？若只监听127.0.0.1，TCP 握手能通（内核层面），但 HTTP 请求会 Connection refused - 监听器和服务器组的健康检查开关是否冲突？比如在监听里关了健康检查，但服务器组里又开了——以监听配置为准，服务器组的设置会被忽略
CLB/TCP 健康检查引发 Connection reset by peer 怎么办？
这是正常现象，不是错误。CLB 的 TCP 健康检查流程是：SYN → SYN+ACK → ACK → RST。最后那个 RST 会让后端应用日志里刷出 Connection reset by peer，尤其在 Java 服务中特别显眼。
解决思路不是禁用检查，而是让日志忽略它：
- Spring Boot 项目可在日志配置中过滤掉含
reset by peer的 warn 日志 - 后端 Nginx 可在
error_log中加notice级别，避免把 RST 当异常记 - 真正要警惕的是连续出现
Connection refused或超时——那说明端口根本没监听，不是 RST 的问题
最易被忽略的一点：NLB 所有后端全挂时，会“尽力而为”把请求全发出去，此时健康检查状态栏可能仍显示“正常”，但实际已无可用节点——得结合监控看请求成功率，不能只信控制台图标。
