1、nginx时序图
在 Nginx 的访问日志中，$request_time 和 $upstream_response_time 是排查接口性能最核心的两个指标。很多同学会混淆两者含义，误把用户侧网络耗时当成后端服务性能问题。下面结合时序图拆解两个指标的时间范围与定位思路。
2、指标详解
$request_time
$request_time 代表客户端视角的完整请求耗时，单位为秒，保留毫秒精度。 时间范围：Nginx 读到客户端请求第一个字节开始，直到 Nginx 将响应最后一个字节发送给客户端，即将写入访问日志时结束。
它包含的耗时环节：
- 客户端上传请求报文，尤其是 POST 大请求体，弱网环境会显著拉长耗时；
- Nginx 内部处理：路由匹配、权限校验、缓存判断等；
- Nginx 与后端建立连接、后端业务处理、Nginx 接收后端响应；
- Nginx 向下传输响应数据给客户端，大文件下载场景下，下行传输耗时会占大头。
核心结论：
request_time就是浏览器端用户真实感知到的请求耗时。request_time 高，不一定是后端慢，有可能是客户端网络问题。
$upstream_response_time
$upstream_response_time 代表Nginx 和后端服务之间的通信耗时。 时间范围：Nginx 和后端 TCP 连接建立成功那一刻起，到 Nginx 接收完后端返回的全部响应字节为止。
它包含：后端 TCP 连接建立、后端业务逻辑处理、Nginx 接收后端响应 header 与 body。 不包含：客户端上传请求体到 Nginx 的时间、Nginx 回传响应给客户端的网络耗时、Nginx 内部请求解析耗时。
当开启 proxy_next_upstream 重试机制时，该变量会出现多个逗号分隔的值，代表依次访问多个后端节点的耗时。
核心结论：这个指标用来判断后端应用本身是否慢。
3、瓶颈判断方法
request_time ≈ upstream_response_time：两者数值接近，瓶颈在后端服务。需要优化接口逻辑、数据库查询等业务代码。request_time >> upstream_response_time：request_time远大于upstream_response_time，瓶颈在客户端和 Nginx 之间。常见原因：移动端弱网、POST 上传大报文、返回超大响应体，下行传输缓慢。- 配套辅助指标：
$upstream_connect_time（后端 TCP 建连耗时），这个值偏高，说明 Nginx 到后端网络拥塞、端口不通或者连接池问题；$upstream_header_time，是连上后端到收到响应首包 header 的时间。
4、小结
$request_time：用户感受到的总耗时；$upstream_response_time：后端接口处理耗时。
两个指标搭配分析，就能快速定位性能瓶颈是在客户端网络、Nginx 网关，还是后端业务服务。