502错误本质是Nginx未从PHP-FPM获取有效响应，需优先查error.log中“upstream timed out”等报错，核对fastcgi_pass与listen一致性、超时参数匹配（如fastcgi_read_timeout=300且request_terminate_timeout≥300）、socket权限及SCRIPT_FILENAME路径真实性。
先确认 PHP-FPM 真正在跑且能响应
别只看 systemctl status php-fpm 显示 active，要验证它是否真在监听、能处理请求：
- 查监听状态：
ss -tlnp | grep ':9000'（或你配置的 socket/port），确认有 php-fpm 进程绑定； - 直连测试：
curl -I http://127.0.0.1:9000/health（如果用了 HTTP 模式）或用fastcgi_params配合SCRIPT_FILENAME测试基础响应； - 更可靠的是走 Unix Socket：
SCRIPT_NAME=/info.php SCRIPT_FILENAME=/var/www/html/info.php REQUEST_METHOD=GET cgi-fcgi -bind -connect /run/php/php8.4-fpm.sock，能输出 PHP info 就说明 FPM 核心可用。
检查 Nginx 和 PHP-FPM 的通信方式是否匹配
PHP 8.4 默认可能启用了新特性（如 JIT、更严格的错误报告），但 Nginx 配置若还沿用老模板，容易失联：
- 确认
fastcgi_pass地址与 php-fpm.conf 中listen完全一致：是127.0.0.1:9000就别写localhost:9000（DNS 解析延迟可能触发超时）；是/run/php/php8.4-fpm.sock就确保 Nginx worker 用户（通常是www-data）对该 socket 文件有读写权限； - 检查
fastcgi_param SCRIPT_FILENAME路径是否真实存在、Nginx 可读；常见坑是路径写成$document_root$fastcgi_script_name，但$document_root拼错或软链接未解析； - PHP 8.4 若启用
opcache.validate_permission=1或opcache.restrict_api，可能拒绝非预期路径的脚本执行，临时注释掉测试。
调宽关键超时和缓冲参数
PHP 8.4 在处理复杂逻辑或加载新扩展时启动稍慢，Nginx 默认 60 秒常不够：
- 在 location 块中显式加大超时：
fastcgi_connect_timeout 300;<br> fastcgi_send_timeout 300;<br> fastcgi_read_timeout 300; - 增大缓冲区防 header 截断：
fastcgi_buffer_size 128k;<br> fastcgi_buffers 4 256k;<br> fastcgi_busy_buffers_size 256k; - 同步检查 PHP 层：
max_execution_time = 300、request_terminate_timeout = 300s（php-fpm pool 配置里）也得跟上。
盯紧错误日志里的具体线索
/var/log/nginx/error.log 和 /var/log/php8.4-fpm.log 要一起看：
立即学习“PHP免费学习笔记（深入）”；
- 出现
upstream timed out→ 超时或 PHP 卡死； - 出现
no live upstreams→ 所有 PHP 进程被健康检查标记为失效（即使它们还在）； - 出现
recv() failed (104: Connection reset by peer)→ PHP 进程崩溃退出，常见于扩展兼容问题（如某些旧 xdebug 版本不兼容 PHP 8.4）； - PHP 日志里若有
Segmentation fault、Allowed memory size exhausted或Failed to load extension，基本锁定是 PHP 侧初始化失败。
