502错误主因是fastcgi_pass与PHP-FPM listen地址不匹配：必须严格一致，包括unix:前缀、完整路径（如/run/php/php8.2-fpm.sock）、无多余空格或版本号错误；同时检查SCRIPT_FILENAME拼写、socket权限及opcache缓存干扰。
fastcgi_pass 必须严格匹配 PHP-FPM 的 listen 地址
502 Bad Gateway 几乎全因这个错配导致。PHP 8.2.12 的 FPM 默认监听 unix:/run/php/php8.2-fpm.sock，不是 php-fpm.sock 或 /var/run/php/php8.2-fpm.sock。Nginx 配置里漏掉 unix: 前缀、路径多空格、版本号写成 8.212 或 8.2.12（FPM 配置文件名不带小数点后两位），都会连不上。
确认方式：
- 运行
sudo systemctl status php8.2-fpm看服务是否 active - 查监听地址：
sudo grep '^listen =' /etc/php/8.2/fpm/pool.d/www.conf - Nginx 中对应写：
fastcgi_pass unix:/run/php/php8.2-fpm.sock;（一字不差）
虚拟目录（alias）下 SCRIPT_FILENAME 计算会失效
用 alias 定义 PHP 路径时，$document_root 不再指向站点根目录，而是空或错误值，导致 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 拼出的路径根本不存在——结果是 404、空白页，甚至直接输出 PHP 源码。
正确做法是手动拼路径：
立即学习“PHP免费学习笔记（深入）”；
- 若 Nginx 配置为
alias /var/www/app/public/; - 则必须写：
fastcgi_param SCRIPT_FILENAME /var/www/app/public$fastcgi_script_name; - 不能依赖
$document_root，也不能硬写成/var/www/html（和实际目录不符） - 同时确保
index包含index.php，否则try_files可能跳过它
socket 文件权限必须允许 Nginx worker 进程读写
即使地址对、路径对，Nginx 还是报 502 或 503，大概率是权限问题。PHP-FPM 创建的 socket 文件属主/组默认是 root:www-data，但 Nginx worker 进程可能以 nginx 用户运行（尤其非 Debian/Ubuntu 系统）。
检查并修复：
- 运行
ls -l /run/php/php8.2-fpm.sock，看输出类似srw-rw---- 1 root www-data - 查 Nginx 用户：
ps aux | grep nginx | grep master，找 USER 列（常见www-data或nginx） - 若不一致，改 PHP-FPM 配置：
sudo nano /etc/php/8.2/fpm/pool.d/www.conf，设：listen.owner = nginxlisten.group = nginx
（或对应用户） - 重启：
sudo systemctl restart php8.2-fpm
PHP 8.2.12 的 opcache 和 realpath_cache 要留意
虚拟目录 + 符号链接 + opcache 启用时，PHP 可能缓存了旧的 realpath 结果，导致 require 或自动加载失败，报 “No such file” 却文件明明存在。
临时排查可加：
- 在
php.ini中关掉：opcache.enable=0、realpath_cache_size=0 - 生产环境别长期关闭，应调大
realpath_cache_ttl（如 7200），并确保部署时清 opcache：sudo systemctl reload php8.2-fpm或调opcache_reset() - 注意：Nginx 本身不缓存 PHP 脚本，所有路径解析和文件查找都在 PHP-FPM 进程内发生
Nginx 和 PHP-FPM 是两个独立进程，它们之间只靠 socket 和参数传递协作；任何一环的路径、权限、版本号偏差，都会在请求到达时立刻暴露——不是延迟报错，而是直接 502 或 404。最麻烦的不是配不起来，而是配“差不多”却行为诡异，比如部分页面正常、部分 require 失败，这种往往卡在 alias 下的 SCRIPT_FILENAME 或 realpath_cache 上。
