nginx和php-fpm的配合，像极了两个性格迥异的搭档。nginx是个急性子，收到请求立马处理，处理完就撒手不管。php-fpm则是个慢性子，它得先把php代码跑起来，把变量算清楚，把数据库查完，才能给出结果。

我见过太多人把这两个进程混为一谈，以为它们是一体的。实际上，nginx只是站在门口迎宾，php-fpm才是真正干活的厨师。nginx把静态文件直接端上桌，遇到php请求就递给php-fpm，自己继续接待下一位客人。这种分工让nginx能同时应付成千上万的连接，而php-fpm慢慢算它的。

有次我调一个线上问题，页面加载慢得像蜗牛爬。查了半天，发现php-fpm的max_children设置得太小，请求全堵在队列里。nginx那边急得团团转，可php-fpm这边就俩进程在干活。改个参数，重启一下，速度立马就上来了。这种问题在日志里根本看不出来，得看php-fpm的status接口才行。

配置这两个家伙的时候，有个细节特别容易踩坑。nginx的fastcgi_pass要写成unix:/run/php/php7.4-fpm.sock，可php-fpm的listen配置也得是同一个socket路径。两边但凡有一个对不上，nginx就会报502 Bad Gateway。这错误太常见了，我几乎每周都能在技术群里看到有人问。

还有个有意思的现象——很多人觉得nginx处理php请求是“直接执行”，其实根本不是那么回事。nginx收到php请求后，只是按照fastcgi协议把请求转发给php-fpm，然后等着响应。整个过程就像你点了外卖，nginx是外卖平台，php-fpm才是厨房。平台不会帮你炒菜，它只负责接单和送餐。

调优的时候，我习惯先看php-fpm的slow log。它会把执行超过指定时间的请求记下来，这样就能知道是哪个接口拖后腿了。配合nginx的access log，把响应时间超过1秒的请求捞出来，基本就能定位到问题。两个日志一交叉，比什么监控工具都直观。

最后说个我自己的习惯——每次改完nginx配置，我都会先执行nginx -t检查语法，再平滑重载。php-fpm那边也一样，改完配置先php-fpm -t，没问题再重启。这俩步骤看着多余，但真能避免不少线上事故。毕竟，这俩搭档配合得好，网站才能跑得顺溜。