测试不同状态码需构造真实触发环境：200用静态文件或return指令；404访问不存在路径；499用短超时客户端；502停upstream；504加大proxy_read_timeout并后端延迟响应。
要测试不同状态码在压测时的表现，核心不是“让 Nginx 主动返回特定状态码”，而是通过构造真实请求路径或后端行为，**触发对应状态码的产生环境**，再在压测中观察其对性能指标（如 RPS、延迟、连接堆积）的影响。Nginx 本身不“生成”404/502/499 等状态码用于测试，而是由配置逻辑或上下游行为决定——所以测试重点是模拟这些逻辑场景，并监控压测过程中的响应特征与系统反应。
准备可复现的状态码触发环境
先确保能稳定复现目标状态码，这是压测的前提：
-
200：访问一个真实存在的静态文件（如
/index.html），或配置一个始终成功返回的 location（如return 200 "OK";） -
404：访问一个明确不存在的路径（如
/nonexistent.js），或用try_files落空后未配error_page -
499：用短超时客户端发起请求，例如
curl -m 0.1 http://host/test，或在 ab/wrk 中设置极短 timeout（wrk 支持--timeout 100ms） - 502：临时停掉 upstream（如关掉后端的 Tomcat 或 PHP-FPM），再压测代理路径
-
504：保留 upstream 运行，但调大
proxy_read_timeout 1，再压测一个故意响应慢的接口（如后端 sleep 2s）
压测时区分并采集状态码分布
默认压测工具（如 ab、wrk）只输出聚合指标，无法按状态码拆分。需配合日志或实时采集：
- 使用 结构化日志格式，把
$status固定为第一字段（避免awk '{print $9}'失效）：log_format status_first '$status | $remote_addr [$time_local] "$request" $body_bytes_sent $request_time $upstream_status'; - 压测期间，用
tail -f access.log | awk -F' \| ' '$1 ~ /^4|5/ {print $0}'实时抓取异常响应 - 压测结束后，快速统计：
awk -F' \| ' '{c[$1]++} END {for (i in c) print i, c[i]}' access.log | sort
关注状态码对关键性能指标的实际影响
不同状态码背后反映的是不同处理路径和资源消耗模式，压测中要重点比对：
-
404 请求：通常比 200 更轻量（不读磁盘、不走 upstream），RPS 可能更高，但大量 404 可能说明客户端路径错误或爬虫扫描，需检查
Reading连接是否积压 -
499 请求：Nginx 不发响应就关闭连接，CPU 开销极小，但会快速消耗
worker_connections和 TIME-WAIT 资源；压测时若 499 比例突增，观察Active connections是否飙升后骤降 -
502/504 请求：涉及 upstream 建连、等待、超时判断，显著拉高平均
request_time和upstream_response_time；压测中若 RPS 下降、Waiting连接持续高位，大概率是 upstream 成为瓶颈
结合 stub_status 实时验证连接压力变化
在压测过程中，高频轮询 /nginx-status，对比不同状态码场景下的连接行为：
- 压 200 时：
Active connections稳定，Reading占比低，Writing快速释放 - 压 499 时：
Active connections波动剧烈，Writing极少，Waiting可能短暂冲高（因 keepalive 连接被客户端断开前仍计入） - 压 504 时：
Active connections持续高位，Writing数量多且耗时长，Accepts增速明显低于Requests
