502 bad gateway应优先查nginx error.log中的三类线索：错误类型关键词（如“connection refused”）、upstream地址、时间戳与请求上下文；再用grep+awk统计高频原因；最后交叉验证php-fpm等上游日志并实测端口连通性、直连响应及资源瓶颈。
看到 502 Bad Gateway，别急着重启服务。真正有效的排查，是从错误日志里直接“读出”问题在哪——不是猜，是看。
盯住 error.log 里的三类关键线索
Nginx 错误日志（通常在 /var/log/nginx/error.log）每条 502 记录都包含明确的技术上下文。重点抓以下三类字段：
-
错误类型关键词：如
"connect() failed (111: Connection refused)"→ 上游服务根本没监听；"upstream timed out (110: connection timed out)"→ 连接建立成功但等响应超时；"recv() failed (104: Connection reset by peer)"→ 后端主动断连（常因崩溃或协议异常） -
upstream 地址：日志末尾的
upstream: "fastcgi://127.0.0.1:9000"或upstream: "http://backend:8080"告诉你它试图连谁——确认这个地址、端口、协议是否真实可达 -
时间戳与请求上下文：结合
client、request字段，可判断是否特定路径/用户/IP 触发，排除偶发抖动还是集中故障
用一条命令快速归类高频原因
不用人工翻日志，直接统计最近 1 小时内最常出现的错误模式：
grep "502" /var/log/nginx/error.log | grep "$(date -d '1 hour ago' '+%Y/%m/%d %H')" | \
awk -F': ' '{print $3}' | cut -d' ' -f1-5 | sort | uniq -c | sort -nr
输出示例：
-
124 upstream timed out→ 超时类问题优先查fastcgi_read_timeout或后端处理慢 -
87 Connection refused→ 立即检查 PHP-FPM 是否运行、端口是否监听、systemctl status php-fpm -
32 Connection reset→ 查后端应用日志（如 Laravel 的 storage/logs/laravel.log），大概率是脚本崩溃或内存溢出
关联上游日志交叉验证
单看 Nginx 日志只能知道“传菜失败”，要知“后厨为何失火”，必须查上游日志：
- PHP-FPM：查 /var/log/php-fpm.log 或 /var/log/php7.4-fpm.log，找
"WARNING: [pool www] server reached pm.max_children setting"（进程池打满）或"child exited on signal Segmentation fault"（段错误） - Node.js/uWSGI：查对应应用日志，重点关注启动失败、未捕获异常（uncaughtException）、OOM killer 杀进程记录
- 如果上游是另一台服务器：在那台机器上执行
journalctl -u your-app --since "1 hour ago"，比只看 Nginx 更接近真相
快速验证链路是否通畅
拿到线索后，立刻做三步实测，5 分钟内闭环：
- 测试上游端口是否监听：
ss -tlnp | grep ':9000'（PHP-FPM）或nc -zv 127.0.0.1 8080 - 模拟 Nginx 请求方式直连上游：
curl -v http://127.0.0.1:9000/health（HTTP 类）或echo -e "GET / HTTP/1.0\r\n\r\n" | nc 127.0.0.1 9000（FastCGI 需用专门工具如fcgi-client） - 检查资源瓶颈：
free -h（内存是否耗尽）、df -h（磁盘是否写满）、cat /proc/sys/fs/file-nr（文件描述符是否用光）——这些都会导致上游拒绝连接或响应中断
