Nginx可通过配置$upstream_response_time变量获取后端真实响应时间，需在log_format中显式记录、在proxy_pass场景下生效，并可通过add_header透传至前端；日志中该值为“-”表明后端未响应。
你提到的“无法获取后端请求时间”，通常是指在 Nginx 反向代理场景中，前端或监控系统拿不到后端真实处理该请求所耗费的时间（即 upstream response time），而不是 Nginx 自身处理时间。这个问题不是 Nginx 默认暴露的指标，需要主动配置才能获取。
确保 Nginx 启用了 upstream 响应时间记录
Nginx 本身通过 $upstream_response_time 变量记录从建立连接到收到后端完整响应所用的秒数（含小数，如 0.234 或 12.891）。但这个变量只在日志、响应头或 proxy_set_header 中可用，且前提是请求确实经过了 upstream（即使用了 proxy_pass 指向一个 upstream 块或明确地址）。
常见遗漏点：
- 直接写
proxy_pass http://127.0.0.1:8080而没定义 upstream 块——$upstream_response_time仍有效，但部分旧版本需显式 upstream 才稳定支持 - 日志格式未包含该变量，导致查不到
- 后端未真正响应（如 502/504），此时该变量为空或为“-”
在 access_log 中记录后端耗时
修改 Nginx 日志格式，把响应时间写入日志，便于排查和统计：
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$request_time $upstream_response_time $upstream_addr';
其中：
- $request_time：Nginx 接收完请求到发出响应的总时间（客户端视角）
- $upstream_response_time：Nginx 等待后端响应的时间（关键指标）
- $upstream_addr：实际转发到的后端地址，可确认是否轮询或故障转移
然后在 server 或 location 块中启用：access_log /var/log/nginx/access.log main;
将后端耗时透传给前端
如果前端需要实时感知后端处理延迟（比如做性能埋点或降级判断），可通过响应头返回：
location /api {<br>
proxy_pass http://backend;<br>
proxy_hide_header X-Upstream-Time;<br>
add_header X-Upstream-Time $upstream_response_time;<br>
}
注意：
– 若后端本身也设置了同名响应头，需用 proxy_hide_header 先屏蔽；
– $upstream_response_time 在失败时为空，前端收到空值或缺失头，就说明后端未正常响应。
验证后端是否真有响应时间数据
最直接的方式是手动测试并观察日志：
- 重启 Nginx 并触发一次 API 请求：
curl -v http://yourdomain.com/api/test - 立刻查看 access.log 最新行，确认是否有类似
0.002 0.187 127.0.0.1:3000的字段（第三段是 upstream_time） - 若第三段为“-”，说明 Nginx 根本没收到后端响应（可能是 502/504，需按之前 502 排查流程检查后端存活、端口、超时等）
只要后端能返回 HTTP 响应（哪怕内容为空或状态码是 200/500），Nginx 就会记录 $upstream_response_time。它不依赖后端是否主动上报时间，是 Nginx 自动测量的真实网络+处理耗时。
