nginx代理层开销≈$request_time−$upstream_response_time，该差值反映其自身处理耗时；差值>200ms且随请求体增大而升高，提示gzip/sub_filter等cpu密集操作；上传阶段差值大说明缓冲配置不当；波动剧烈但上游快则多因客户端弱网；tls下突增需检查ssl_buffer_size或加密套件。

要识别 Nginx 代理层自身的处理开销，关键不是单独看 $request_time，而是把它和上游真实响应耗时做差值对比——这个差值，就是 Nginx 自身在请求接收、转发、响应组装等环节所消耗的时间。

明确两个时间的分工

$request_time 是整条链路耗时：从收到客户端第一个字节，到发完响应最后一个字节，含网络传输、Nginx 处理、后端响应全部过程。
$upstream_response_time（取最后一个值）只记录 Nginx 连上后端后，到收完响应体的时间，基本剥离了客户端侧和 Nginx 自身逻辑干扰。

二者之差 ≈ Nginx 代理层开销 + 客户端网络延迟 + 响应体下发耗时

定位代理层高开销的典型信号

• 差值稳定 > 200ms 且与请求体大小正相关：可能是启用了 gzip on 或 sub_filter，尤其在返回大 HTML/JSON 时 CPU 解压或文本替换明显拖慢
• 差值集中在上传阶段（如 POST 大文件）：检查是否未启用 client_body_buffer_size 或 proxy_buffering off，导致 Nginx 等待完整 body 才转发，阻塞整个流程
• 差值波动剧烈，但 $upstream_response_time 很低：常见于客户端弱网、频繁中断重传；Nginx 在等待客户端 ACK 或发送响应时被卡住
• 差值在 TLS 场景下突增：若开启 ssl_buffer_size 过小或使用非硬件加速的加密套件，SSL 记录分片和加解密会显著抬高代理层耗时

日志配置与分析建议

确保 log_format 中同时包含这两个字段，并保留毫秒精度：

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

用以下命令快速筛查异常差值：

• 查差值最大的 10 条： awk '{if(NF>=8) print $NF-$(NF-1), $0}' access.log | sort -k1nr | head -10
• 统计差值超 300ms 的请求按方法聚合：awk '$NF-$(NF-1) > 0.3 {print $(NF-6)}' access.log | sort | uniq -c | sort -nr（需按实际字段位置调整）
• 排除后端影响后，聚焦 GET 请求看代理层表现：awk '$(NF-6)=="GET" && $NF-$(NF-1) > 0.25' access.log | head -5

验证是否为代理层问题的辅助手段

临时关闭可疑模块观察差值变化：

• 注释掉 gzip on、sub_filter、real_ip_recursive 等耗时模块，重启 Nginx 对比日志差值
• 对同一接口，用 curl 模拟本地直连后端（绕过 Nginx），对比响应时间与 $upstream_response_time 是否接近
• 开启 error_log /var/log/nginx/error.log debug;（谨慎使用），查看是否有 buffer full、ssl handshake slow 等提示