PHP和Nginx的组合，像一对默契的老搭档。PHP是个固执的工匠，坚持自己处理逻辑；Nginx是个高效的前台，只管把请求递进去、把结果送出来。它们之间靠FastCGI协议对话——一个简单却极其稳定的约定。

我见过太多人一上来就装宝塔面板，点几下鼠标就把环境搭好了。但真要出问题，比如502 Bad Gateway，就抓瞎了。其实原理很简单：Nginx收到请求，发现是PHP文件，就通过socket或端口把请求扔给PHP-FPM进程。PHP-FPM处理完，把结果原路返回。502就是这条链路上某个环节断了——可能是PHP-FPM没启动，可能是socket路径不对，也可能是进程崩了。

有一次我排查一个线上问题，网站偶尔白屏，刷新几次又好。查了PHP错误日志，干干净净。后来盯着Nginx的error_log，发现一堆“connect() to unix:/var/run/php-fpm.sock failed”。原来是PHP-FPM的进程数设置太少，高峰期请求排队超时。改成动态模式，max_children设成合适的值，问题瞬间消失。这种坑，文档里写得明明白白，但你不踩一次，永远记不住。

Nginx处理静态文件是它的看家本领。图片、CSS、JS，直接读磁盘返回，不走PHP，速度飞快。这也是为什么它比Apache更适合高并发——Apache每个请求都开进程，Nginx用事件驱动，一个进程扛几千连接。但PHP本身是同步阻塞的，所以Nginx必须把PHP请求转发出去，自己继续干别的活。这种“异步转发”的设计，让Nginx在PHP面前像个聪明的调度员，而不是傻等的服务员。

配置上有个小细节很多人忽略：fastcgi_param里的SCRIPT_FILENAME。如果路径写错，PHP-FPM会返回“Primary script unknown”，但Nginx那边可能显示200状态码，响应体却是空的。这种问题最坑——看起来没报错，就是没内容。我习惯在Nginx配置里加上fastcgi_intercept_errors on;，这样PHP的404或500能正确传递给客户端，而不是被Nginx吞掉。

还有性能调优。PHP-FPM的pm.max_requests建议设成500或1000，让进程处理完这么多请求后自动重启，防止内存泄漏累积。Nginx的keepalive要开着，但超时时间别太长，30秒够了。这些参数不是越大越好，得看服务器内存和业务特点。我见过有人把max_children设成500，结果8G内存的机器直接OOM，MySQL都被杀了。

说实话，PHP+Nginx的组合谈不上优雅，但胜在皮实。不像Node.js那样一个进程干所有事，也不像Java那样启动就要吃1G内存。它就是个老派的搭档，各管一摊，出了问题也好排查——要么看Nginx的error_log，要么看PHP-FPM的日志，链路清晰得让人安心。

如果你还在用Apache跑PHP，建议试试Nginx。不是为了赶时髦，而是真的能省内存、扛并发。改配置的时候小心点，先备份，改完nginx -t检查语法。生产环境别直接reload，先平滑验证。这些习惯养成了，比任何所谓的“最佳实践”都管用。