502错误完整排查流程
502 Bad Gateway是Nginx等反向代理常见的错误，通常意味着代理服务器无法从上游服务获取有效响应。本文梳理从现象确认、快速定位、到逐个击破的完整可操作流程，帮助运维人员高效恢复服务。
502 Bad Gateway表示充当网关或代理的服务器，从上游服务器接收到无效响应。通常上游是PHP-FPM、Tomcat、Node.js等应用服务。关键信息：代理服务器自身工作正常，问题出在它与上游的交互环节。
排查逻辑主干
核心路径分三层：上游服务存活与端口监听、上游服务是否能正常处理请求、代理与上游之间的网络与配置。建议按照“服务状态→配置正确性→资源限制→日志深挖”的顺序执行，避免跳跃式猜测。
快速定位：一分钟确认关键点
检查上游服务存活与监听
登录代理服务器，使用telnet或nc检测上游IP和端口：telnet 127.0.0.1 9000。无响应则先确认服务进程是否存在：ps aux | grep php-fpm或systemctl status php-fpm。若进程存在但不监听端口，检查对应的listen配置（如php-fpm的listen = 127.0.0.1:9000）及socket文件权限。
确认代理配置指向正确
对于Nginx，查看proxy_pass或fastcgi_pass指令，确保域名、IP、端口、unix socket路径与上游实际监听一致。例如fastcgi_pass unix:/run/php/php7.4-fpm.sock; 需确认.sock文件存在且Nginx进程有读写权限。
深入排查常见原因
上游服务挂掉或未启动
这是最高频原因。使用systemctl restart或supervisorctl重启上游服务，同时检查错误日志（如/var/log/php-fpm.log）。若启动失败，日志通常直接说明原因，如配置文件语法错误、端口被占用、依赖缺失。
超时导致连接断开
代理的超时设置比上游处理时间短，上游还在执行时连接被切断，代理收到无效响应即返回502。检查Nginx的fastcgi_read_timeout、proxy_read_timeout等指令，适当增加秒数。同时查看上游慢日志，定位慢请求进行优化。
上游返回不符合协议
常见于上游服务崩溃或脚本错误时输出非标准HTTP响应。查看代理错误日志，通常会留下“upstream sent invalid header”或“upstream prematurely closed connection”字样。应用层无响应时，可尝试直接用curl请求上游（如果可以直连）复现问题，检查应用错误日志。
资源耗尽
上游PHP-FPM进程数达到上限pm.max_children，新请求无法分配进程，代理连接失败。查看php-fpm状态页或日志中的“server reached pm.max_children setting”消息。调整pm.max_children时需结合服务器内存，避免过载。也可以调整pm模式为ondemand避免闲置进程。
文件描述符或端口耗尽
大量TIME_WAIT连接或进程打开文件过多，导致无法建立新连接。检查ulimit -n，通过ss -s查看连接状态。若代理与上游都在本机，考虑使用unix socket代替TCP连接以减少TCP开销，并优化内核参数net.ipv4.tcp_tw_reuse等。
反向代理自身问题
极少数情况，代理层版本Bug或配置不当导致。检查Nginx的error_log，出现类似buffer相关问题，可调整proxy_buffer_size和proxy_buffers参数。保持代理版本更新，已知Bug可查官方公告。