网站突然 502：从进程到网关逐层看

502 的含义很具体：网关（通常是 nginx）把请求转给后端应用时，后端要么没响应，要么回了无效内容。排查方向只有一个——后端应用，从四个角度依次看。 第一看：进程还在吗 systemctl status php-fpm ps aux | grep php-fpm 后端可能是 php-fpm、gunicorn、uwsgi 或自己写的服务，先确认进程活着；Java 应用用 jps 看更直接，容器化部署用 docker ps 或 crictl ps 确认容器状态。注意 status 里反复在 active 和 failed 之间跳的，属于"起了又死"，和"没起"是一类问题，都要去看它自己的日志找死因。 第二看：端口通不通 netstat -lntp | grep 9000 curl -I http://127.0.0.1:9000 9000 是 php-fpm 常见端口，实际以配置为准。进程在但 nginx 连不上后端，多半是端口或监听地址对不上：nginx 配置里 fastcgi_pass 或 proxy_pass 指向的地址、端口，和后端实际监听的是否一致，逐字符比对；改了 nginx 配置却没 reload，新地址不生效，也是常见的一环。后端走 unix socket 的话，netstat 里看不到 TCP 端口，要确认 nginx 里写的 socket 路径与实际文件一致、权限可读写。 第三看：日志最后几行 tail -50 /var/log/nginx/error.log connect() failed (111: Connection refused) 说明后端没在监听；upstream prematurely closed connection 说明后端处理到一半崩了，再去后端日志找对应时间点的报错，常见的是 PHP 致命错误或代码抛了异常。111 和 104 两种错误码含义不同，前者是拒绝，后者是连接被重置，对应方向不一样。对照日志时注意时间对齐，两边日志差着时区的话，永远对不上。 第四看：是不是被打爆了 dmesg -T | grep -i "out of memory" free -m OOM（内存耗尽后内核强制杀进程的机制）杀掉 php-fpm 是 502 的经典剧本：内存耗尽，内核动手，nginx 转眼找不到上游。php-fpm 的 pm.max_children 设得过大、或单个请求内存泄漏，都会走到这一步；当前子进程数量用 ps aux | grep -c php-fpm 就能数出来，对照配置值和内存总量评估是否要调小。定位到泄漏之后，给进程设内存上限并配好监控，比反复重启体面得多。 502 若是一波一波出现，先调出请求量曲线对一对时间点，多半是后端扛不住瞬时并发。502 排查的说服力在日志里，不在猜测里。进程、端口、三份日志（nginx 的、后端的、内核的）依次看完，原因基本水落石出。