Nginx 在 error.log 中记录上游节点宕机与恢复事件，前提是启用 max_fails/fail_timeout 被动健康检查并设置日志级别为 notice 或 error；关键日志包括“upstream server temporarily disabled”和“upstream server restored”。
Nginx 本身不提供“节点宕机日志”的独立日志类型，但它会在 error.log 中自动记录上游节点被标记为不可用（down）的关键事件，前提是正确启用了被动健康检查机制（max_fails/fail_timeout）并配置了合理的日志级别。
确保 error.log 记录节点状态变更
Nginx 默认在 error 级别及以上记录后端故障相关事件。只要 upstream 配置了 max_fails 和 fail_timeout，当某节点因连续失败被标记为 down 或恢复为 up 时，Nginx 就会写入明确日志：
-
upstream server temporarily disabled—— 表示该节点刚被标记为 down（例如因连接拒绝或超时） -
upstream server restored—— 表示该节点在fail_timeout后首次探测成功，重新加入轮询
这些日志默认已启用，无需额外指令，但需确认以下两点：
-
error_log 指令未被设为 warn 或更高：若配置了
error_log /var/log/nginx/error.log warn;，则notice级别的状态变更日志会被过滤掉。应至少保留error_log ... error;（或更推荐notice） - 全局或 http 块中未禁用 notice 级别输出：Nginx 的 notice 级别包含节点启停事件，属于有效诊断信息，不建议屏蔽
增强日志可读性与定位效率
单纯依赖默认日志可能难以快速筛选节点状态变化。可通过以下方式提升实用性：
-
在 upstream 块中为每个 server 显式命名：使用
server 192.168.1.10:8080 weight=2 max_fails=3 fail_timeout=30s; # api-node-a注释，虽不参与解析，但方便人工比对日志中的 IP/端口 -
配合 grep 快速提取关键事件：例如执行
tail -f /var/log/nginx/error.log | grep -i "disabled\|restored\|upstream" -
避免日志被覆盖：配置
error_log /var/log/nginx/error.log notice buffer=64k;并启用 logrotate，防止关键事件丢失
注意：主动健康检查的日志行为不同
若使用第三方模块（如 nginx_upstream_check_module）或 Nginx Plus 的 health_check，其探测结果通常也记入 error.log，但格式和触发条件不同：
- 开源 check 模块常用日志如：
[error] ... upstream check is down, server: 192.168.1.10:8080 - Nginx Plus 的 health_check 日志更结构化，含响应码、延迟等字段，需开启
health_check_log on; - 无论哪种方式，都不替代 passive 容错日志，而是作为补充——被动日志是所有标准 Nginx 版本都具备的基础能力
