502错误最隐蔽典型诱因是后端应用池满，如PHP-FPM的pm.max_children耗尽、uWSGI或Java连接池打满，导致Nginx收到“upstream prematurely closed connection”或“connect() failed (111)”等提示；需查Nginx错误日志、直连后端验证状态、核对pm.max_children等核心参数，并通过ab压测复现确认。
502 错误本身不报“应用池满”，但这是最隐蔽也最典型的诱因之一——尤其在 PHP-FPM、uWSGI 或 Java 应用连接池耗尽时。Nginx 看到的只是“上游提前关闭连接”或“连接被拒绝”，背后往往是后端进程/线程/连接数已打满，新请求进不去，自然无法响应。
看 Nginx 错误日志里的关键线索
直接查 /var/log/nginx/error.log，重点关注含以下关键词的行：
- upstream prematurely closed connection：后端在没发完响应时就断开了，常见于进程处理中被强制回收或队列溢出
- connect() failed (111: Connection refused)：不是服务没启，而是监听队列已满（如 PHP-FPM 的 listen.backlog 耗尽）
- recv() failed (104: Connection reset by peer)：后端主动重置连接，常因子进程崩溃、OOM 杀死或资源超限退出
验证后端应用池是否真满了
绕过 Nginx，直连后端服务并观察行为：
- 对 PHP-FPM：运行 sudo systemctl status php-fpm 查状态；再执行 sudo php-fpm -t 验证配置；最后用 sudo cat /var/log/php-fpm/www-error.log 检查是否频繁出现 "WARNING: [pool www] server reached pm.max_children setting"
- 对 Node.js（PM2）：运行 pm2 list 看进程是否全在 online 状态；再查 pm2 show app-name 中的 memory usage 和 restarts 次数
- 对 Java（Tomcat）：访问 http://localhost:8080/manager/status（需开启 manager），重点看 Max threads 和当前 Current thread count 是否接近上限
检查后端核心资源限制参数
不能只看“进程在不在”，要看它“能不能接新请求”：
- PHP-FPM：pm.max_children（最大子进程数）、pm.start_servers、pm.max_requests（防内存泄漏重启阈值）都可能成为瓶颈
- uWSGI：processes、max-requests、listen（socket 监听队列长度）
- Nginx 自身也要配合：确保 worker_connections 足够，并在 upstream 块中启用 keepalive 减少连接开销
模拟压测快速复现问题
用简单命令触发排队效应，验证是否为池满所致：
- 用 ab -n 100 -c 50 http://127.0.0.1:端口/health（Apache Bench）发起并发请求
- 同时监控：ss -s（看 ESTAB 连接数）、free -h（内存）、dmesg | grep -i "killed process"（OOM 日志）
- 若压测中开始出现 502，且后端日志同步打出“reached max_children”，基本可锁定
