Nginx 的 error_log 默认仅在所有重试均失败并返回 502/504 时记录错误，不会为每次上游失败单独打日志；若需观察每次重试细节，须将日志级别调至 info 或 debug，并配合 proxy_next_upstream_tries 和 timeout 参数分析实际触发时机。
当 Nginx 作为反向代理时，error_log 对重试请求（retry）的记录行为有明确但易被忽略的规则：它通常只在最终所有重试都失败后才记录错误，而不会为每次失败的上游尝试单独打日志。
重试过程本身不触发 error_log
Nginx 默认启用 proxy_next_upstream（如配置了 error timeout），遇到上游失败时会自动切换到下一个 server 或重试当前 server。这个“重试动作”属于内部流程，只要最终成功返回响应，error_log 就不会记录任何内容——即使中间某次连接被拒绝或超时。
- 例如：上游 A 超时（504），Nginx 自动重试上游 B 并成功返回 200 → 无 error_log 输出
- 只有所有 upstream 都失败（如 A 和 B 全挂），Nginx 返回 502/504 时，才会在
error_log中记一条错误，如：upstream timed out (110: Connection timed out) while connecting to upstream
想看到每次重试失败？需调高日志级别
默认 error_log level 是 error，只记录最终失败。若要观察每次重试细节（比如哪次连不上、哪次超时），需将日志级别设为 info 或 debug：
error_log /var/log/nginx/error.log info;- 此时日志中会出现类似：
[info] ... connect() failed (111: Connection refused) while connecting to upstream, ... - 注意：
debug级别会产生大量日志，仅建议临时开启排查；info是较平衡的选择
重试次数和间隔影响日志出现时机
实际是否记录、何时记录，还取决于 proxy_next_upstream_tries 和 proxy_next_upstream_timeout 的设置：
- 若设
proxy_next_upstream_tries 1，则最多重试一次；若第一次失败且无备用 server，会更快触发 error_log - 若设
proxy_next_upstream_timeout 1s，而单次 upstream 耗时超 1s，Nginx 可能提前放弃重试并记录超时 - 日志中的时间戳和上下文（如
upstream: "http://backend"）可帮助定位是哪个 server 或哪类错误（connect/refused/read timeout）
区分 client 错误与 upstream 错误日志
error_log 记录的 upstream 相关错误，一般带有 while connecting to upstream、while reading response header from upstream 等短语。而客户端断连、SSL 握手失败等，则属于另一类错误源，日志上下文不同：
-
client prematurely closed connection→ 客户端问题，非重试逻辑 -
no live upstreams while connecting to upstream→ 所有 upstream 均不可用，重试机制已失效 - 可通过
log_format添加$upstream_addr和$upstream_status到 access_log，辅助交叉验证重试路径
