要准确分析后端响应分布，必须记录并分析 $upstream_status 而非仅看 $status；需自定义含 $upstream_status、$upstream_addr 和 $upstream_response_time 的日志格式，启用后结合 awk 聚合统计错误分布，联动 $status 与 $upstream_status 判定故障类型，并建议接入监控系统实现长期观测。
要真正看清后端服务的响应分布，不能只看 Nginx 返回给客户端的 $status（比如一堆 502），而必须依赖 $upstream_status——它才是后端真实吐出的状态码。这个变量是分析健康分布的“眼睛”，但前提是日志格式得先把它记下来。
必须启用含 upstream_status 的自定义日志格式
Nginx 默认 access_log 不记录上游信息。需在 http 块中明确定义：
- 用 log_format 包含 $upstream_status、$upstream_addr 和 $upstream_response_time
- 推荐格式示例：
log_format upstream_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent $upstream_status $upstream_addr $upstream_response_time "$http_referer" "$http_user_agent"'; - 在 server 或 location 块中启用：
access_log /var/log/nginx/upstream.log upstream_log; - 重启 Nginx 后，日志里每行就会带上有意义的 upstream 状态，如：
192.168.1.100 - - [28/Apr/2026:10:22:33 +0000] "GET /api/user HTTP/1.1" 200 1245 200 10.0.2.5:8080 0.042 "https://app.com" "curl/7.68"
按 upstream_status + upstream_addr 聚合识别异常节点
健康分布的关键是“谁在错、错得多不多”。直接用命令快速统计：
- 查各后端地址返回的错误码分布（例如哪台机器 500 高发）：
awk '{print $8, $9}' /var/log/nginx/upstream.log | grep "^[45]" | sort | uniq -c | sort -nr
（假设 $8 是 upstream_status，$9 是 upstream_addr） - 定位高频失败的后端实例：
awk '$8 ~ /^[45]/ {print $9}' /var/log/nginx/upstream.log | sort | uniq -c | sort -nr | head -10 - 注意重试干扰：若某行显示 "500 10.0.2.5:8080, 10.0.2.6:8080"，说明第一次失败后重试了另一节点——两个地址都要纳入排查，不能只盯第一个。
联动 $status 和 $upstream_status 判定故障类型
单看 upstream_status 容易误判。必须结合 Nginx 自身返回状态，才能区分真实问题根源：
- $status=502 且 $upstream_status="-"：Nginx 根本没连上后端（网络不通、端口未监听、防火墙拦截）
- $status=504 且 $upstream_status="-"：后端无响应超时（可能是进程卡死、OOM、或 upstream_response_timeout 设置过短）
- $status=200 但 $upstream_status=500：后端实际报错，但 Nginx 错误页或 proxy_intercept_errors 配置掩盖了问题——这就是典型的“健康假象”
- $status=502 且 $upstream_status=502：后端自己返回了 502（如它也作为网关转发失败），需继续向上游追查
进阶建议：为长期监控打基础
手工 awk 只适合临时排查。生产环境应考虑：
- 接入 Loki 或 ELK，对 $upstream_status 做实时直方图和同比环比告警
- 用 map 指令 将 $upstream_addr 映射为可读节点名（如 node-a），便于 Grafana 展示
- 配合 $upstream_response_time 做 P95/P99 分位统计，把慢响应和错误码交叉分析（比如 500 是否总伴随 >2s 响应）
- 若后端支持，加 $upstream_http_x_request_id 实现全链路追踪对齐
