需在高并发持续压测中实时采集统计各状态码分布、时点、延迟及突变趋势，将其作为压力反馈信号；结合 access.log、stub_status 和 error.log 交叉分析根因。
要测试极限压力下 Nginx 的状态码响应速度，不能只看单次请求的 status code 返回，而是需在高并发、持续压测过程中，实时采集并统计不同状态码（尤其是 2xx/4xx/5xx）的分布、出现时点、响应延迟及突变趋势。核心是把状态码作为“压力反馈信号”，而非静态分类结果。
用 ab 或 wrk 搭配日志采样做压力触发
先用压测工具制造真实压力，再同步分析 access.log 中的状态码行为：
- 启动压测时开启
$status和$request_time日志变量（确保 log_format 包含这两项） - 运行类似命令：
wrk -t4 -c1000 -d30s http://localhost/（模拟 4 线程、1000 并发、30 秒持续请求） - 压测中用
tail -f access.log | awk '{print $9, $10}'实时观察状态码与耗时组合，例如是否出现大量 502+高 request_time，或 499（客户端主动断连）激增
按状态码分组统计响应时间分布
压测结束后，快速提取各状态码的延迟特征：
- 查所有 502 请求的平均耗时：
awk '$9==502 {sum+=$10; cnt++} END{print "avg:", sum/cnt}' access.log - 找最慢的 404 请求路径：
awk '$9==404 {print $10, $7}' access.log | sort -nr | head -5 - 统计每秒内各状态码数量变化（需按时间戳分桶），可发现“503 开始密集出现”的临界时间点
结合 stub_status 观察连接态与状态码突变的关联
状态码异常往往伴随连接层压力，需交叉验证：
- 在压测过程中每 2 秒执行一次：
curl -s http://127.0.0.1/nginx-status | grep 'Active\|Waiting' - 若 Waiting 连接数飙升至 800+，同时 access.log 中 499 数量陡增，说明客户端因超时频繁断连
- 若 Active connections 稳定但 502 比例突然上升，大概率是 upstream 崩溃或健康检查未生效
用 error.log 定位状态码背后的根因
很多状态码本身不直接反映瓶颈，错误日志才揭示底层失败逻辑：
-
grep "upstream timed out" error.log→ 对应 504，说明 proxy_read_timeout 不足或后端卡死 -
grep "no live upstreams" error.log→ 对应 502，upstream 全挂且无 backup -
grep "client intended to send too large body" error.log→ 对应 413，需调大 client_max_body_size
