502 Bad Gateway 错误本质是 Nginx 作为代理未能从后端服务获取有效响应，需从“能不能通”“会不会等”“够不够用”“配没配对”四方面排查：直连验证后端可用性、调整超时参数、校验代理头与协议配置、扩大缓冲区及资源限制。
502 Bad Gateway 不是 Nginx 自己出错，而是它作为“信使”转述上游服务（比如 PHP-FPM、Java 应用、后端 API）失败的结果。排查核心思路是：先确认上游是否活着、能否通信、是否返回合规响应。
查 Nginx 错误日志定位直接线索
打开 /var/log/nginx/error.log，搜索最近的 502 行，重点关注报错末尾的提示，例如：
-
"upstream sent too big header" → 缓冲区太小，需调大
fastcgi_buffer_size或proxy_buffer_size - "connect() failed (111: Connection refused)" → 上游根本没监听，比如 PHP-FPM 没启动或 socket 文件路径不对
- "recv() failed (104: Connection reset by peer)" → 上游进程崩溃、主动断连，常见于内存溢出或脚本异常退出
- "Cannot assign requested address" → 端口耗尽，多见于高并发短连接场景，需优化 TIME_WAIT 回收或启用 keepalive
验证上游服务是否正常运行
区分上游类型逐一检查：
- 如果是 PHP-FPM：运行
systemctl status php-fpm看状态；用ps aux | grep php-fpm确认 master 和 worker 进程存在；再执行netstat -lnp | grep :9000（或对应 socket 路径）确认监听正常 - 如果是 Java/Tomcat/Go 等后端服务：用
curl -v http://127.0.0.1:8080/health直连测试，看是否返回有效 HTTP 响应（含状态码、Header） - 如果用的是 Unix socket（如
unix:/tmp/php-cgi.sock）：检查文件是否存在、权限是否为 nginx 用户可读写（ls -l /tmp/php-cgi.sock）
检查 FastCGI 或 Proxy 关键配置参数
配置不当会直接触发 502，重点核对三类设置：
-
超时时间过短：在
location ~ \.php$或location /块中，确保有足够长的等待时间，例如：fastcgi_connect_timeout 300;<br>fastcgi_send_timeout 300;<br>fastcgi_read_timeout 300;
-
缓冲区不足：尤其当后端返回大 Header（如大量 Cookie、自定义头）时，加一行：
fastcgi_buffer_size 64k;<br>fastcgi_buffers 8 64k;
-
PATH_INFO 解析错误（ThinkPHP/Laravel 等框架常见）：Nginx 默认不传递 PATH_INFO，导致框架路由失效并静默退出。解决方法是改用
try_files $uri $uri/ /index.php?$query_string;，让框架从 QUERY_STRING 解析路由，避开正则捕获问题
观察系统资源与连接状态
有时 502 是资源瓶颈的表象：
- 运行
free -h和df -h查内存和磁盘是否满（特别是 /tmp 或 /var/log） - 用
ss -s或netstat -an | grep TIME_WAIT | wc -l看是否有上万 TIME_WAIT 连接，若接近/proc/sys/net/ipv4/ip_local_port_range差值，说明端口枯竭 - 检查 PHP-FPM worker 数量是否打满：
ps aux | grep 'php-fpm:' | wc -l，对比pm.max_children设置值；接近上限就需扩容或优化代码
