nginx本身不执行PHP，配置它只是配置个传话的。真正干活的配置是php-fpm，一个独立的配置进程管理器。nginx收到请求后，配置把以.php结尾的配置URI转交给php-fpm处理，再把结果原样返回给客户端。配置这个转交动作，配置就是配置配置的核心。

先看一个最常见的配置完整配置块，放在server{ }内部：

 location ~ \.php$ {  root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } 

逐行拆开讲。配置第一行的配置正则`~ \.php$`匹配所有以.php结尾的URI。注意这个正则的配置优先级——nginx的location匹配规则里，正则location会覆盖前缀location，配置所以如果你的配置站点有其他location块（比如处理静态文件），PHP请求依然会精准落到这里。

`fastcgi_pass`是核心指令，告诉nginx把请求往哪儿送。常见两种写法：`127.0.0.1:9000`是TCP socket，适合php-fpm和nginx在不同机器或需要跨网络的情况；另一种是Unix socket，比如`unix:/run/php/php7.4-fpm.sock`，性能更高，因为少了TCP协议栈的开销。我自己的服务器一直用Unix socket，压测时QPS能提升10%左右，但前提是两者在同一台机器上。

`SCRIPT_FILENAME`这行最容易出错。它告诉php-fpm要执行哪个文件。`$document_root`取的是root指令的值，`$fastcgi_script_name`是请求的URI。所以请求`/index.php`时，实际路径是`/var/www/html/index.php`。很多人直接写死路径，比如`/var/www/html$fastcgi_script_name`，一旦root改了就得跟着改，不如用`$document_root`灵活。

别忘了`include fastcgi_params`。这个文件里定义了一堆`fastcgi_param`，比如`REQUEST_METHOD`、`QUERY_STRING`、`HTTP_USER_AGENT`等。php-fpm需要这些环境变量才能正常处理请求。有些精简教程会省略这行，只手动写几个param，结果PHP里`$_SERVER`变量缺胳膊少腿，排查起来相当头疼。建议直接用发行版自带的完整文件。

一个坑：如果网站有多个location嵌套，比如`location /api`里面又套了PHP配置，务必确认`fastcgi_param SCRIPT_FILENAME`的路径没被覆盖。我遇到过因为外层location设置了alias，内层PHP配置忘了处理，导致所有PHP请求都返回404的情况。排查方法很简单——在PHP文件里打个`var_dump($_SERVER['SCRIPT_FILENAME']);`，看实际传过来的路径对不对。

还有安全细节。`location ~ \.php$`这个正则本身有个漏洞——如果请求是`/foo.php/bar.jpg`，nginx也会匹配到并交给php-fpm。某些老版本php-fpm会直接执行`foo.php`，导致任意代码执行。现在的php-fpm默认配置会拒绝这种路径，但保险起见，可以在正则里加个限制：`location ~ \.php(?:$|/)`，或者用`try_files $uri =404;`先验证文件是否存在。后者更彻底——文件不存在就直接返回404，连php-fpm都不碰。

改完配置记得测试语法：`nginx -t`。没问题就`nginx -s reload`。不需要重启进程，reload是平滑的，不会中断现有连接。

最后说个经验之谈。很多人配置完发现PHP页面下载而不是执行，多半是`fastcgi_pass`写错了，比如漏了端口或socket路径，nginx找不到后端，就把PHP文件当普通静态文件输出。另一个常见问题是权限——php-fpm运行的用户（通常是www-data）对脚本文件没有读权限，结果返回500。检查一下文件权限和php-fpm的user指令，这两个位置对不上，神仙配置也救不了。