502错误核心是PHP-FPM响应失败，需先确认服务状态与fastcgi_pass/listen路径一致，再调优dynamic进程模型、协同设置超时参数（fastcgi_read_timeout≥request_terminate_timeout）、增大缓冲，并通过nginx和php-fpm日志精准定位超时、连接拒绝或进程退出问题。
高并发下 Nginx 返回 502 Bad Gateway，核心不是 Nginx 本身扛不住，而是它背后的 PHP-FPM 没能及时响应——连接被重置、进程耗尽、超时中断，本质是资源与配置不匹配。解决关键在于“稳住上游”，让 PHP-FPM 能持续、可靠、高效地处理请求。
确认 PHP-FPM 服务状态和通信链路
502 出现的第一步永远是验证基础连通性：
- 执行 systemctl status php-fpm（或对应版本如 php8.2-fpm），确认服务处于 active (running) 状态
- 检查 Nginx 配置中 fastcgi_pass 的值（如 unix:/run/php/php8.2-fpm.sock 或 127.0.0.1:9000），必须与 PHP-FPM 池配置（/etc/php/8.2/fpm/pool.d/www.conf）中的 listen 完全一致
- 用 ls -l /run/php/php8.2-fpm.sock 查看 socket 文件是否存在，且属主/属组为 www-data（或 Nginx 运行用户），权限建议 srw-rw----
- 若用 TCP 方式，运行 netstat -tuln | grep :9000 确认端口已被 php-fpm 监听
调整 PHP-FPM 进程模型与数量
静态（static）模式在高并发下易僵化，动态（dynamic）更适应流量波动：
- 在 www.conf 中设置：
pm = dynamic
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_children = 120（按内存估算：12G 内存 ÷ 30MB/进程 ≈ 400，但建议留余量，120–200 更稳妥） - 避免 pm.max_requests 过小（如默认 500），设为 10000 或 0（无限），防止子进程频繁重启导致空档期
- 用 ps aux | grep php-fpm | wc -l 实时观察活跃进程数，若长期接近 max_children，说明需扩容
同步优化超时与缓冲参数
Nginx 和 PHP-FPM 的超时必须协同，否则一方已断，另一方还在等：
立即学习“PHP免费学习笔记（深入）”；
- 在 nginx.conf 的 http 或 server 块中增加：
fastcgi_connect_timeout 60s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
（注意：fastcgi_read_timeout 是从 PHP-FPM 开始发响应起计时，必须覆盖最慢接口的执行时间） - 在 www.conf 中设置：
request_terminate_timeout = 300（单位秒，优先级高于 php.ini 的 max_execution_time） - 若日志出现 "upstream sent too big header"，增大缓冲：
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
排查资源瓶颈与日志线索
不靠猜，靠日志定位真实瓶颈：
- 紧盯 /var/log/nginx/error.log，典型线索包括：
• "upstream timed out" → 超时类问题
• "connect() to ... failed (111: Connection refused)" → PHP-FPM 未监听
• "recv() failed (104: Connection reset by peer)" → PHP 子进程崩溃退出 - 查看 /var/log/php8.2-fpm.log，关注：
• WARNING script timed out → request_terminate_timeout 触发
• NOTICE [pool www] child 1234 exited on signal 15 (SIGTERM) → 进程被主动终止 - 检查系统级限制：
ulimit -n 应 ≥ 65535；
若大量 TIME_WAIT，可调优 net.ipv4.tcp_tw_reuse = 1
