Nginx 1.26.2 反代 PHP 8.4.1 启动失败的根本原因是 PHP-FPM（或 php-cgi）未运行或与 Nginx 配置不匹配：PHP-FPM 必须手动启动且 listen 地址需与 fastcgi_pass 完全一致；location ~ .php$ 块必须存在并正确配置 fastcgi_pass 和 SCRIPT_FILENAME；HTTPS 下证书路径、格式及权限须合规；还需排除 PID 残留、端口占用和 BOM 等隐形问题。
phpenv 下 Nginx 1.26.2 反代 PHP 8.4.1 启动失败，根本不是 phpenv 本身的问题，而是 Nginx 与 PHP-FPM（或 php-cgi）之间“对接断了”。phpenv 只管切换 PHP CLI 版本，它不启动、不配置、也不管理 PHP-FPM 进程——这个责任完全落在你手动配置的 Nginx 和 PHP 运行环境上。
PHP-FPM 没起来，Nginx 就只能干等
Nginx 的 fastcgi_pass 指令（比如 fastcgi_pass 127.0.0.1:9000 或 fastcgi_pass unix:/run/php/php8.4-fpm.sock）本质是“发请求”，不是“拉进程”。如果 PHP-FPM 根本没运行，Nginx 就会报 connect() failed (111: Connection refused)，服务自然启动失败或请求直接 502。
- Linux/macOS：运行
sudo systemctl status php8.4-fpm或ps aux | grep php-fpm确认进程是否存在 - Windows（phpEnv 场景）：phpenv 不自动启 php-cgi.exe，需手动执行
C:\php\php-cgi.exe -b 127.0.0.1:9000，并用 RunHiddenConsole 后台驻留 - 检查 PHP-FPM 配置文件（如
/etc/php/8.4/fpm/pool.d/www.conf）中listen地址是否与 Nginx 的fastcgi_pass完全一致（含 IP、端口、socket 路径、权限）
Nginx 配置里藏着几个致命细节
哪怕 PHP-FPM 正常运行，Nginx 一句写错，照样无法转发 .php 请求：
-
location ~ \.php$块必须存在且未被注释，且内部必须包含fastcgi_pass+fastcgi_param SCRIPT_FILENAME -
SCRIPT_FILENAME拼接必须精准：Linux 常用$document_root$fastcgi_script_name；Windows 必须用正斜杠或双反斜杠，例如C:/www$fastcgi_script_name - 若用 socket 方式（
unix:/path/to.sock），确保 Nginx 主进程用户（如 www-data）对该 socket 文件有读写权限，且 socket 路径目录可访问 - 别漏掉
include fastcgi_params;—— 缺少它，QUERY_STRING、REQUEST_METHOD等关键参数全为空
证书、路径、权限三座隐形大山
HTTPS 场景下，错误更隐蔽：
立即学习“PHP免费学习笔记（深入）”；
- SSL 证书路径写错、私钥带密码、或 PEM 文件格式不合规（如含 BOM、中间证书缺失），会导致 Nginx
nginx -t直接报emerg错误，服务连加载都失败 - 网站根目录（
root）、日志路径、临时上传目录（upload_tmp_dir）在 Windows 上若含中文、空格或使用 OneDrive/同步盘路径，PHP 和 Nginx 都可能静默拒绝访问 - Linux 下，确保
/var/log/nginx/、/var/cache/nginx/、PHP session 目录等，对 Nginx 用户（非 root）可写
别让旧残留和端口抢走你的启动权
看似重启，实则“假死”：
- 上一次异常退出后，
/usr/local/nginx/logs/nginx.pid或/run/nginx.pid可能残留，导致新启动被判定为“重复运行”而退出 - Apache、Skype、IIS、甚至 Python 的简易服务器，都可能抢先绑定 80/443 端口，Nginx 日志只显示
bind() to 0.0.0.0:80 failed，不告诉你谁占的 - Windows 下 vhost 配置文件若保存为 UTF-8 with BOM，Nginx 会报
unknown directive “server”类似错误，实际是 BOM 字节被当成了非法字符
