error_log虽不直接记录健康检查结果，但通过记录模块未加载、探测失败、状态码不匹配等报错，暴露健康检查失效；同时忠实记录proxy_next_upstream重试过程中的每次失败，揭示后端真实异常，并支持与access_log交叉比对定位配置偏差及评估健康检查策略合理性。
error_log 本身不直接记录后端健康检查结果，但它在监控健康检查异常时承担着“故障回声”和“配置验证器”的关键角色——当健康检查失败、探测逻辑出错或上游服务响应异常时，这些信息往往不会出现在 access_log 中，而是明确写入 error_log。
暴露健康检查机制本身的失效
主动健康检查（如 nginx_upstream_check_module）一旦配置错误或探测路径不可达，Nginx 会在 error_log 中留下明确痕迹：
- 模块未加载报错：如 “unknown directive 'check'”，说明 check 模块未编译或未启用；
- 探测请求失败：如 “upstream timed out (110: Connection timed out) while connecting to upstream”，表明 /health 接口无响应或网络不通；
- HTTP 响应码不匹配：如 “check failed: status 503 not in http_2xx http_3xx”，说明后端返回了非预期状态，但 Nginx 已按配置将其判定为失败。
揭示后端真实异常而非网关假象
当 proxy_next_upstream 触发重试时，access_log 可能只显示最终成功的 200，而 error_log 会忠实记录每一次失败尝试：
- 例如某次请求先后打到 server A（返回 500）→ server B（返回 504）→ server C（返回 200），access_log 仅记一次 200，error_log 却会逐条记录两行错误，暴露后端整体不稳定；
- 若 error_log 频繁出现 “no live upstreams while connecting to upstream”，说明所有后端节点已被标记为 down，健康检查已完全失效，需立即介入。
关联日志定位配置与行为偏差
error_log 的时间戳、进程 ID 和错误上下文，可与自定义 access_log 中的 $upstream_status 字段交叉比对：
- 发现某台 upstream_addr 在 access_log 中大量返回 500，同时 error_log 中对应时间点出现 “connect() failed (111: Connection refused)”，说明该节点已彻底失联，而非应用层错误；
- 若 error_log 显示 “upstream sent too big header while reading response header”，则提示后端响应头超限，需调整 proxy_buffer_size 等参数，这类问题不会触发健康检查失败，但会导致请求中断。
辅助判断健康检查策略是否合理
通过 error_log 中失败频次和恢复日志，可反推当前 rise/fall 阈值是否适配业务实际：
- 频繁出现 “backend marked as down” 后几秒又 “backend marked as up”，说明 fail/rise 设置过激，轻微抖动即剔除节点；
- 长期无 “marked as down” 日志，但业务侧反馈后端偶发不可用，可能因 max_fails 设置过大或 fail_timeout 过长，导致异常节点未被及时隔离。
