$upstream_response_time 是衡量 Nginx 与后端通信真实延迟的核心指标，单位秒、精度毫秒，需配合 $upstream_addr 定位具体节点，并结合主动/被动健康检查实现精准监控与故障排查。
要真正看清后端服务响应快慢，关键不是看整体耗时，而是聚焦 Nginx 与后端之间那一次通信的真实延迟——$upstream_response_time 就是这个指标。
它测什么、怎么读
这个变量从 Nginx 向后端（如 Tomcat、Gunicorn）发起连接开始计时，到收到响应头（或完整响应体）为止，单位秒、精度毫秒：
- 成功响应：显示单个值，例如
0.042（42 毫秒） - 发生重试：多个值用逗号分隔，例如
0.018,0.063表示第一次转发耗时 18ms，第二次重试耗时 63ms - 某次失败：对应位置为
-，例如0.021,-表示第一次成功、第二次连接失败或超时
它和 $request_time 不同——后者包含客户端上传、Nginx 自身处理、响应下发等全部环节，在弱网或大文件场景下会明显偏高，无法反映后端真实性能。
必须搭配 $upstream_addr 才有用
$upstream_response_time 本身不带地址信息，单独看毫无定位价值。必须同时记录 $upstream_addr，才能知道“这几十毫秒到底发生在哪台机器上”：
-
$upstream_addr输出实际通信的后端 IP 和端口，例如192.168.1.10:8080 - 若启用重试或故障转移，它的值也以逗号分隔，且顺序与
$upstream_response_time严格对齐，可一一对应分析 - 配合使用，就能快速判断：是某节点 CPU 飙高？还是某台机器网络路径异常？或是某实例配置漏了连接池？
落地监控的三步实操
光有变量不行，得让它进日志、进告警、进排查流程：
- 在
log_format中同时写入$upstream_addr和"$upstream_response_time"，避免不同 upstream 组日志混杂 - 用
map指令把后端地址映射成策略标识（如rr、least_conn），生成$lb_strategy变量，方便后续按算法聚合分析平均耗时、P95、失败率 - 加两行响应头做轻量验证：
add_header X-Upstream-Addr $upstream_addr;和add_header X-Upstream-Time $upstream_response_time;，用curl -I直接观察单次请求的真实后端耗时，适合压测抽样或快速比对
健康检查要分主动和被动
只靠日志还不够，得让 Nginx 主动感知后端状态：
-
主动检查：定期发健康探测请求（如
/health），根据状态码（200 正常）、响应时间、超时判定是否可用；适用于流量稳定、可承受探测开销的场景 -
被动检查：基于真实客户端请求的结果判断，比如连续
max_fails=3次超时或 5xx 错误，就标记为不可用，fail_timeout=30s后再试探恢复；更适合低流量或敏感业务 - 两者可共存，但需注意
proxy_next_upstream的触发条件（如timeout error http_502）是否覆盖常见异常
