评估响应时间需拆解瓶颈位置：$request_time含全程耗时，$upstream_response_time仅反映后端通信；两者接近说明后端慢，差距大则查Nginx配置或网络；须关注P95/P99分位数而非平均值，并结合错误码、连接状态及系统指标交叉验证。
评估响应时间对系统的影响，不能只看一个平均值，得拆开看它在哪儿慢、谁在拖后腿、慢到什么程度才真正影响业务。
区分 $request_time 和 $upstream_response_time
这两个字段是判断瓶颈位置的关键：
- $request_time：从客户端发请求开始，到 Nginx 完全把响应发回客户端为止的总耗时。它包含上传时间、Nginx 自身处理、后端响应、响应下发全过程。
- $upstream_response_time：仅记录 Nginx 与后端（如 Tomcat、PHP-FPM）之间的真实通信耗时——从建立连接到收完响应头或体。它排除了客户端网络抖动和 Nginx 本地开销，更干净地反映后端性能。
如果两者接近（比如 $request_time 是 1.2s，$upstream_response_time 是 1.15s），问题大概率出在后端；如果差距大（比如 $request_time 1.5s，$upstream_response_time 只有 0.08s），就要查 Nginx 配置、SSL 处理、gzip 压缩、大文件传输或客户端弱网问题。
关注分位数而非平均值
平均响应时间容易掩盖问题。例如平均 200ms，但 P99 达到 2s，意味着 1% 的用户要等两秒——这已严重影响转化率和体验。
- P95 表示 95% 的请求都在这个时间以内，适合衡量主流用户体验；
- P99 更敏感，能暴露偶发抖动、慢查询、GC 暂停、单点故障等深层问题；
- 配合错误码一起看：P99 高的同时 504 突增，基本锁定 upstream 超时或后端不可用。
结合连接状态和系统指标交叉验证
响应时间变长，未必是代码或后端的问题，也可能是资源或连接层被压垮：
- 访问
/nginx-status查Waiting连接数持续偏高 → 可能 keepalive 连接积压，或后端响应慢导致连接空闲等待； -
Active connections接近worker_connections上限 → 新请求排队，$request_time 自然拉长； - CPU 持续 >75%、TIME_WAIT 连接超 3 万、内存缓存命中率骤降 → 说明系统级瓶颈正在拖慢整个请求链路。
按 IP 或 upstream 分组监控延迟变化
负载不均或定向攻击常表现为某台后端响应时间异常升高：
- 在日志格式中同时记录
$upstream_addr和$upstream_response_time，确保逗号分隔值严格对齐（重试场景下尤其重要）； - 用 Prometheus 抓取指标时，打上
addr="192.168.1.10:8080"标签，可单独告警某节点 P95 超阈值且环比激增； - 加响应头
X-Upstream-Addr和X-Upstream-Time，curl 一次就能确认当前请求落到哪台机器、耗时多少，适合快速比对和压测抽样。
