要在Nginx负载均衡中准确记录后端处理响应时间，关键是使用$upstream_response_time变量，它精确反映Nginx向后端发起请求到接收响应头的时间（单位秒、毫秒精度），不含客户端上传、SSL握手及Nginx自身开销；需配合log_format自定义日志格式、启用access_log、同时记录$upstream_addr以定位具体节点，并区分$upstream_response_time（仅上游通信耗时）与$request_time（全链路总耗时）来精准归因性能瓶颈。

要在 Nginx 负载均衡中准确记录后端处理响应时间，关键不是只看总耗时，而是提取 Nginx 与后端之间真实通信的那部分——即 $upstream_response_time 变量。它专为这一目的设计，单位是秒（精度毫秒），不掺杂客户端上传、SSL 握手或 Nginx 自身逻辑开销。

启用并配置上游响应时间日志

默认 access_log 不包含该字段，需手动定义 log_format：

• 在 http 块中添加自定义格式，例如：

log_format upstream_log '$remote_addr [$time_local] "$request" $status $body_bytes_sent ' '"$upstream_addr" $upstream_response_time $request_time';

• 在对应 server 或 location 块中启用：

access_log /var/log/nginx/upstream.log upstream_log;

• 执行 nginx -t && nginx -s reload 生效

理解 $upstream_response_time 的含义和取值

这个变量反映的是 Nginx 向后端发起请求到收到响应头（或体）的时间：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 成功时显示如 0.042（42 毫秒）
• 重试时多个值用逗号分隔，如 0.018, 0.063，表示第一次 18ms、第二次 63ms
• 某次失败则对应位置为 -，如 0.021, -
• 若未启用 proxy_pass 或请求未走到上游，该字段为空或为短横线

必须搭配 $upstream_addr 才能定位具体节点

$upstream_response_time 本身不带地址信息，单独记录无法判断延迟发生在哪台机器上：

• $upstream_addr 会输出实际通信的后端 IP:PORT，如 192.168.1.10:8080
• 当发生重试或故障转移时，$upstream_addr 和 $upstream_response_time 严格一一对应，顺序一致
• 日志中同时出现两者，才能确认“192.168.1.10:8080 响应耗时 0.042 秒”这样的完整链路

区分 $upstream_response_time 和 $request_time

这两个变量常被混淆，但用途不同：

• $request_time：整条请求生命周期，含客户端上传、Nginx 排队、上游等待、响应下发等全部环节
• $upstream_response_time：仅限代理阶段，专注后端服务能力
• 若 $request_time 明显大于 $upstream_response_time，瓶颈可能在客户端网络或 Nginx 层；若二者接近，问题大概率在后端服务本身