Nginx upstream心跳检测失败时，error_log是最直接线索，需识别check failed日志模式并结合nginx-upstream-check-module启用状态、配置参数及网络连通性综合排查。
当 Nginx 的 upstream 节点心跳检测失败时，error_log 是最直接的线索来源。关键不是看有没有报错，而是要识别出与健康检查（health check）相关的特定日志模式，并结合配置确认是否启用、如何触发、为何失败。
确认启用了主动健康检查（active health check）
Nginx 开源版默认不支持 upstream 主动心跳检测；只有 Nginx Plus 或使用 nginx-upstream-check-module（第三方模块）编译的版本才支持。若你用的是标准开源版却在日志里看到类似 check interval 或 upstream check failed 的记录，说明已加载该模块。
- 检查编译参数：
nginx -V 2>&1 | grep -o 'with-http_upstream_check_module' - 查看配置中是否有
check指令，例如：
upstream backend {
server 10.0.1.10:8080;
check interval=3 rise=2 fall=5 timeout=1;
从 error_log 中识别心跳失败的关键信息
模块启用后，失败会以固定格式写入 error_log（级别通常为 error 或 warn）。典型日志条目如下：
- 2024/05/12 14:22:33 [error] 12345#0: *667 upstream check failed: code=000, response time=0.000s, upstream: "10.0.1.10:8080" —— 表示连接被拒绝或超时（code=000）
- 2024/05/12 14:22:36 [warn] 12345#0: *669 upstream check failed: http status 503, response time=0.002s, upstream: "10.0.1.10:8080" —— 健康检查请求返回了非 2xx/3xx 状态码
-
2024/05/12 14:22:39 [error] 12345#0: *671 upstream check failed: timeout, response time=1.001s, upstream: "10.0.1.10:8080" —— 检查请求耗时超过
timeout参数
注意：日志中的 response time 和 code/status 是判断根因的核心依据。
结合配置与网络快速定位原因
拿到日志后，按以下顺序排查：
- 检查目标节点是否真实可达：
telnet 10.0.1.10 8080或curl -v http://10.0.1.10:8080/health（确保健康检查路径可访问） - 确认 upstream 中定义的
check_http_send和check_http_expect_alive是否匹配后端实际响应（比如后端返回 200 但配置了http_2xx 3xx，没问题；若只配了http_2xx却返回 302，则判定失败） - 观察失败是否集中于某台 server：如果是，优先查该节点资源（CPU、端口占用、防火墙）、应用是否崩溃或未监听
- 检查 Nginx 到后端的网络路径是否存在丢包、策略限制（如安全组、iptables）
临时验证与日志增强技巧
调试阶段可临时调高日志级别并聚焦 upstream 检查：
- 在
http块中添加：
log_format checklog '$remote_addr - $upstream_addr [$time_local] "$upstream_http_content_type" $upstream_status $request_time';
access_log /var/log/nginx/check.log checklog; - 将 error_log 级别设为
debug（仅测试环境）：
error_log /var/log/nginx/error.log debug; —— 可看到更细粒度的检查调度和 socket 错误 - 用
nginx -t确保配置语法正确，再nginx -s reload生效
