502错误主因是PHP-FPM子进程耗尽或超时失配，需先查进程状态与Nginx错误日志，再调优pm.max_children、request_terminate_timeout（≥fastcgi_read_timeout）、pm.max_requests等核心参数，并校验socket路径与权限。
网站频繁出现502，大概率不是Nginx本身的问题，而是PHP-FPM在高并发、长耗时或配置失配下无法稳定响应。关键不在“重启服务”，而在精准识别瓶颈并调整php-fpm.conf中真正起作用的几项参数。
确认是否是子进程耗尽导致的502
这是最常见原因：请求量上升后，所有PHP子进程都被占用，新请求进来时Nginx找不到可用上游，直接返回502。
- 检查当前活跃子进程数：
sudo systemctl status php8.1-fpm | grep "active (running)"，再用ps -ef | grep php-fpm | wc -l看实际进程总数 - 查看Nginx错误日志中是否有
upstream sent no valid response或no live upstreams——这类提示基本锁定为进程池枯竭 - 若
pm.max_children设为50，而服务器内存充足（如8GB以上），可先试调至200～300；但必须同步估算单个PHP进程内存占用（通常60～100MB），避免OOM Kill
匹配超时设置，避免Nginx与PHP-FPM“互相放弃”
502常发生在Nginx等不及、PHP-FPM又没及时退出的夹缝中。两者超时值必须逻辑自洽。
- Nginx端需明确设置三个超时（写在
location ~ \.php$块内）：fastcgi_connect_timeout 30;fastcgi_send_timeout 300;fastcgi_read_timeout 300; - PHP-FPM端对应池配置（如
/etc/php/8.1/fpm/pool.d/www.conf）中必须满足：request_terminate_timeout >= fastcgi_read_timeout（建议设为310或360）request_slowlog_timeout = 10s（开启慢日志辅助定位卡死脚本） - 切忌把
request_terminate_timeout设为0——看似不限制，实则容易因file_get_contents、cURL无超时等导致进程僵死
选用合适的进程管理模型并控制再生频率
静态（static）适合负载稳定的小站；动态（dynamic）更适应流量波动，但需合理设定空闲阈值。
立即学习“PHP免费学习笔记（深入）”；
- 推荐使用
pm = dynamic，并按以下比例配置（以max_children = 200为基准）：pm.start_servers = 40（启动即加载，防冷启洪峰）pm.min_spare_servers = 20pm.max_spare_servers = 60 -
pm.max_requests = 1000值得保留——它能定期回收可能内存泄漏的进程，防止长期运行后因内存碎片化引发崩溃 - 若发现502集中在某次部署后高频出现，检查是否引入了未设超时的远程调用或数据库长事务
验证socket权限与监听路径一致性
即使服务在跑，权限不对或路径错一位，Nginx照样连不上，报502。
- 确认Nginx配置中的
fastcgi_pass和PHP-FPM池里的listen完全一致，包括路径、协议（unix:/run/php/php8.1-fpm.sock）、结尾斜杠 - 检查socket文件属主与权限：
ls -l /run/php/php8.1-fpm.sock
应为root:www-data或www-data:www-data，权限建议srw-rw---- - 若用Unix socket，确保
listen.owner和listen.group设为Nginx worker用户（通常是www-data），否则连接被拒绝
