Nginx 跑通 PHP-FPM：避开常见坑，把环境配稳

刚接手新服务器或者迁移项目时，Nginx 和 PHP-FPM 联调往往是最磨人的环节。页面直接下载 .php 文件，或者干脆弹出 502 Bad Gateway，这种场景太熟悉了。别急着复制粘贴网上的通用模板，把两者之间的通信链路理顺，一次配准能省下大量排查时间。

Nginx 自身不懂 PHP，它只负责接收请求并把流量转交给 PHP-FPM 进程池。定位到站点的 server 区块，在 location 指令里加上正则匹配：

location ~ \.php$ {
}

这一步的作用是精准拦截所有以 php 结尾的请求。很多新手在这里漏掉末尾的 $，导致静态资源也被强行转发，直接拖垮整个站点的加载速度。

流量接住后，得告诉 Nginx 往哪儿送。根据实际部署情况选对通信方式。同机部署优先用 Unix Socket，减少网络协议开销；跨机或容器化环境则用 TCP。对应配置写为： Socket 方式： fastcgi_pass unix:/run/php/php8.2-fpm.sock; TCP 方式： fastcgi_pass 127.0.0.1:9000; 路径或端口必须和 php-fpm.conf 里的 listen 设置完全一致，差一个斜杠就会直接阻断请求。

请求到达 PHP-FPM 后，需要明确具体要执行哪个文件。最关键的参数其实是 SCRIPT_FILENAME。不要依赖模糊的系统变量，直接在配置块里声明绝对路径： fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 顺手把内置参数表引入进来，能一次性补齐 QUERY_STRING、REQUEST_METHOD 等必要字段。写入 include fastcgi_params;（或 fastcgi.conf）即可，注意文件名拼写。

配完别急着重启服务，检查语法错误是基本功。执行 nginx -t 确认无误后再平滑重载。启动顺序也有讲究：先拉起 PHP-FPM 守护进程，再 reload Nginx。如果站点依然白屏或 502，打开 Nginx 的 error.log，按时间戳滚动查看。绝大多数问题都藏在权限拒绝、路径缺失或 FPM 工作进程被 OOM Killer 终止的记录里。

环境跑通只是第一步，后续的平稳运行还得看进程池的调度。编辑 www.conf 调整 pm.max_children 和 pm.start_servers，让内存占用和并发峰值相匹配。PHP-FPM 默认监听套接字权限多归 root，建议改为 web 服务运行的普通用户，避免后期文件上传产生归属权冲突。遇到表单提交被吞或大文件传不上去，优先检查 php.ini 里的 post_max_size 和 upload_max_filesize，再联动调高 Nginx 的 client_max_body_size，按照应用层到网关层的顺序排查，逻辑会更清晰。

把 Nginx 和 PHP-FPM 当作独立协作的微服务来维护，划清职责边界，环境就不会反复折腾。扎实的基础配置配合常态化的日志巡检，比临时抱佛脚来得从容得多。