502是Nginx转发请求后上游未返回有效响应，504是Nginx等待上游响应超时；前者需查上游进程存活与连接状态，后者应调优proxy_read_timeout等超时参数并监控上游处理性能。
要测试后端高负载下 Nginx 的 502 与 504 表现，关键不是盲目加压，而是模拟真实故障场景、精准触发对应错误路径，并通过日志和响应状态验证行为是否符合预期。下面分三步实操：
一、构造可复现的后端延迟/崩溃服务
先准备一个可控的上游服务，便于验证不同故障类型：
- 用 Python 快速起一个 HTTP 服务（如 Flask），提供两个接口：
/slow：固定 sleep 10 秒（用于触发 504）；
/crash：直接 exit() 或主动关闭 socket（用于触发 502 Connection reset 或 refused） - 部署在本地或同网段，确保 Nginx 可以 proxy_pass 到它（例如 http://127.0.0.1:8001）
- 避免用真实业务服务做首轮测试——它可能有缓存、熔断或健康检查干扰判断
二、针对性压测 + 日志联动观察
不用全量并发，聚焦单请求生命周期，看 Nginx 如何反应：
- 对 /slow 接口发起 curl 请求，同时 实时 tail -f /var/log/nginx/error.log：
若看到upstream timed out (110: Connection timed out) while reading response header→ 明确是 504，说明proxy_read_timeout生效了 - 对 /crash 接口发起请求，同样盯 error.log：
出现connect() failed (111: Connection refused)→ 是 502（上游没监听）；
出现upstream prematurely closed connection→ 是 502（上游启动但处理中崩了或主动断连） - 用
curl -v http://your-domain/slow看返回头里的Status: 504 Gateway Timeout，确认客户端收到的是预期状态码
三、模拟高负载下的连锁反应
单请求没问题，不代表集群稳定。继续加压看瓶颈转移：
- 用
ab -n 100 -c 20 http://your-domain/slow模拟并发慢请求，观察：
Nginx 的 worker_connections 是否打满（nginx -t && nginx -s reload后再试）；
上游服务进程数、内存、文件描述符是否耗尽（ps aux | grep your-app、lsof -p PID | wc -l） - 故意把上游服务设为单进程 + 无连接池，然后并发调用 /crash，会高频出现 502；此时 error.log 中 “Connection refused” 和 “No route to host” 可能交替出现——说明上游已无法响应新连接
- 对比调整前后：
把proxy_read_timeout 30;改成600;，再压测 /slow，504 应消失；
把上游服务重启脚本加入systemctl restart your-app，再快速发请求，大概率捕获到短暂的 502 Connection refused
整个过程不依赖监控平台，靠日志+curl+简单脚本就能闭环验证。核心是让每种错误都有明确触发方式和可观测出口，而不是等线上炸了才猜原因。
