301和302本身服务端耗时相近，终端跳转耗时差异源于客户端行为：301可被浏览器缓存而免去请求，302每次需完整两次请求链路，且Location不合规会引发DNS、跨域等额外延迟。
直接看 $status 只能知道“是否跳转”和“跳转类型”，它本身不记录耗时。要分析 301/302 对终端跳转耗时的影响，必须把 $status 和其他日志字段、客户端行为、网络链路结合起来看，重点不是状态码本身，而是它触发的后续动作链条。
区分 301 和 302 的耗时逻辑差异
301 和 302 在服务端响应时间上几乎无差别，真正影响终端耗时的是浏览器或客户端如何处理这个响应：
-
301 响应后，浏览器可能直接从本地缓存跳转：只要之前访问过同路径且收到过 301，下次请求可能根本不发到 Nginx，而是直接重定向到新地址——这时
$status根本不会出现在日志里，但用户感知极快。 -
302 响应每次都要走完整链路：浏览器不缓存（或仅短时缓存），每次请求都打到 Nginx → 后端 → 返回 302 → 浏览器再发起第二次请求。这意味着一次跳转实际产生两条日志：
GET /old → 302和GET /new → 200，总耗时是两次 RTT + 后端处理时间之和。 -
302 若 Location 是相对路径或内网地址，会引发额外解析或失败重试：比如
$upstream_http_location记录为/dashboard或http://10.0.1.5:8080/login，浏览器可能因跨域、协议不匹配或 DNS 不可达而卡顿甚至报错，这类问题在$status里只显示 302，但真实耗时飙升。
用日志定位高耗时跳转的真实瓶颈
单靠 $status 无法判断耗时，需组合以下字段交叉验证：
-
查连续请求对：用
awk '$9==302 {print $1,$4,$7}' /var/log/nginx/access.log | head -20提取 IP、时间戳、原始 URI，再 grep 同一 IP 下紧随其后的GET /new-path请求，计算时间差——这就是终端实际跳转延迟。 -
对比
$request_time和$upstream_response_time：如果$request_time明显大于$upstream_response_time（比如前者 800ms，后者 50ms），说明耗时主要花在客户端解析 Location、DNS 查询或网络传输上，而非服务端。 -
检查
$upstream_http_location是否合规：运行awk '$9==302 && $13 ~ /^https?:\/\// {print $13}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5，看高频跳转目标是否含内网 IP、缺失协议、或域名不可达——这些都会让浏览器反复尝试或降级处理，拉长总耗时。
结合 error.log 判断非预期延迟
很多“慢跳转”其实不是重定向本身慢，而是重定向失败后浏览器重试或降级导致：
- error.log 出现
connect() failed (111: Connection refused)，但 access.log 显示 302：说明后端返回了 Location，但 Nginx 没法连过去，只能返回错误页，浏览器可能重试多次才放弃。 - 出现
upstream timed out且$status是 302：表示后端返回太慢，Nginx 等不到完整响应就超时，此时跳转地址可能不完整或丢失，浏览器解析失败后会卡住或报错。 - 看到大量
client intended to send too large body配合 302：说明 POST 后重定向（PRG 模式）时，客户端误把大 Body 重复提交，造成阻塞。
验证客户端真实耗时的辅助手段
服务器日志有局限，终端耗时最终取决于用户环境：
- 用 Chrome DevTools 的 Network 面板抓取真实跳转链：看每个请求的
Time列，重点关注Waiting (TTFB)和Content Download，确认是 DNS、SSL 还是 Location 解析拖慢了整体。 - 在页面中注入 Navigation Timing API 日志：例如
performance.getEntriesByType('navigation')[0].redirectCount能读出浏览器实际执行了几轮重定向，redirectStart到redirectEnd给出精确毫秒级耗时。 - 对关键跳转路径加 UTM 参数或唯一 trace_id，并在前端埋点上报：这样能把 Nginx 日志中的
$request_uri和前端采集的耗时数据关联起来，形成闭环分析。
