502 bad gateway 错误表示 nginx 作为反向代理时无法从上游服务器（如 php-fpm、node.js 等）获取有效响应，主因包括上游服务宕机、网络不通、超时设置过短、缓冲区不足或响应头非法，需结合 access_log、error_log 及上游日志综合排查。
502 Bad Gateway 错误表示 Nginx 作为反向代理时，无法从上游服务器（如 PHP-FPM、Node.js、Tomcat 等）收到合法响应。访问日志本身不直接记录 502 的具体原因，但结合日志字段、时间戳、请求特征和上游状态，可以高效定位问题源头。
确认日志中确实记录了 502 错误
Nginx 默认 access_log 中的 $status 字段会记录响应状态码。确保你的日志格式包含该变量，例如：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time $upstream_addr';然后在日志中搜索：
grep ' 502 ' /var/log/nginx/access.log重点关注：
- 请求路径（是否集中于某接口或静态资源）
- 客户端 IP（是否来自爬虫或异常流量）
- $upstream_addr（实际转发到哪个 upstream server）
- $upstream_response_time（为“-”表示未收到响应；若为数值但远超预期，可能上游卡死或超时）
排查上游服务是否宕机或拒绝连接
502 最常见原因是上游进程不可达。检查以下几点：
- 上游服务进程是否运行：如 systemctl is-active php-fpm 或 netstat -tuln | grep :3000
- 端口是否被监听且可被 Nginx 访问：Nginx 运行用户（如 www-data）需能 connect 到 upstream 地址，注意 SELinux/firewalld/iptables 限制
- upstream 配置中是否用了域名但 DNS 解析失败（可用 curl -v http://upstream-host 测试连通性）
- 如果用 Unix socket（如 unix:/run/php/php8.1-fpm.sock），检查 socket 文件权限和所属用户是否匹配 Nginx worker 进程
检查超时与缓冲区设置是否过小
即使上游启动着，也可能因响应慢或体过大触发 502。关键配置项包括：
- proxy_read_timeout：Nginx 等待上游响应的最长时间（默认 60s），若上游处理耗时更长，会主动断开并返回 502
- proxy_connect_timeout 和 proxy_send_timeout：分别控制建连和发请求阶段的超时
- proxy_buffer_size、proxy_buffers、proxy_busy_buffers_size：若上游返回头过大（如大量 Set-Cookie 或自定义 header），超出缓冲区也会报 502
- 对应 FastCGI 场景则检查 fastcgi_read_timeout、fastcgi_buffer_size 等
建议在出错请求前后对比 $request_time 和 $upstream_response_time：若两者接近且较大，大概率是上游慢；若 $upstream_response_time 为“-”，而 $request_time 很小，则可能是连接阶段失败（如 refused / timeout）。
关联错误日志与系统指标交叉验证
access_log 只是线索入口，必须结合其他信息才能闭环：
- 查看 error_log（通常 /var/log/nginx/error.log），搜索对应时间点的 “upstream timed out”、“no live upstreams”、“Connection refused”、“Connection reset by peer” 等关键词
- 检查上游服务自身日志（如 PHP-FPM 的 slow log、error log；Node.js 的 stdout/stderr）是否有崩溃、OOM killer 杀进程、循环依赖等迹象
- 观察系统负载：用 uptime、free -h、dmesg -T | grep -i "killed process" 确认是否内存不足导致上游被杀
- 检查磁盘空间与 inodes：df -h 和 df -i，满盘会导致上游写日志/临时文件失败，间接引发 502
