精准统计静态资源首字节响应耗时需用$upstream_header_time而非$request_time，因其专指Nginx建连完成后到接收响应首行的时间（毫秒精度），等价于上游TTFB；须在proxy_pass location中配置log_format显式记录，并结合$upstream_connect_time和$upstream_cache_status交叉分析瓶颈。
要精准统计静态资源的首字节响应耗时（即从客户端发起请求到收到第一个响应字节的时间），关键不是只用 $request_time，而是必须结合 $upstream_header_time —— 它专指 Nginx 与上游（如源站、对象存储、CDN 回源节点）建立连接后，到接收到响应首行（含状态码和响应头）所花的时间，单位为秒、精度毫秒，天然适配静态资源回源场景。
为什么 $upstream_header_time 是首字节耗时的核心指标
静态资源（如 JS、CSS、图片）通常走反向代理或 CDN 回源路径。此时：
-
$request_time包含了 Nginx 接收请求头、等待 upstream 建连、读取响应体等全部环节，无法区分“卡在建连”还是“卡在源站处理” -
$upstream_response_time是完整响应耗时（含响应体传输），对首字节无意义 -
$upstream_header_time正好覆盖「连接建立完成 → 收到响应头第一行」这一区间，等价于上游侧的 TTFB（Time to First Byte），且不含 Nginx 自身解析开销
配置支持毫秒级首字节记录的 log_format
在 http{} 块中定义日志格式，显式包含 $upstream_header_time，并确保它出现在 proxy_pass 所在的 location 中：
'$status $body_bytes_sent "$http_referer" "$http_user_agent" '
''$upstream_addr $upstream_header_time $upstream_cache_status '
''rt=$request_time uct=$upstream_connect_time';
说明：
-
$upstream_header_time是核心字段，值如0.047表示 47ms，直接用于分析首字节延迟 -
$upstream_addr可确认实际回源目标（避免 DNS 轮询干扰判断） -
$upstream_cache_status辅助识别是否命中本地缓存（MISS / HIT / BYPASS），排除缓存干扰 -
uct=$upstream_connect_time用于交叉验证：若uct高但upstream_header_time更高，说明瓶颈在源站处理而非网络
启用该格式并验证是否生效
在静态资源匹配的 location 块中启用日志（例如匹配 .js|.css|.png）：
proxy_pass https://origin.example.com;
access_log /var/log/nginx/static_ttfb.log static_ttfb;
# 其他 proxy_* 配置保持不变
}
验证步骤：
- 执行
nginx -t确保语法正确 - 重载配置：
nginx -s reload - 触发一次静态资源请求（如 curl -I https://yoursite.com/app.js）
- 查看日志：
tail -n1 /var/log/nginx/static_ttfb.log，确认字段如0.032出现且非“-”
用日志快速定位首字节慢的常见原因
采集足够样本后，按 $upstream_header_time 排序或设阈值（如 >100ms）筛选日志，可聚焦问题类型：
- 若
$upstream_header_time高 +$upstream_connect_time也高 → 检查 TLS 握手、DNS 解析、中间网络抖动 - 若
$upstream_header_time高 +$upstream_connect_time低 → 源站应用处理慢（PHP/Node 启动延迟、数据库查询阻塞等） - 若
$upstream_cache_status为MISS且$upstream_header_time普遍偏高 → 源站未开启 Gzip 或响应头缺失Cache-Control，导致频繁回源
