php nginx centos

一台CentOS服务器上，PHP和Nginx的搭配像一对磨合多年的老搭档。PHP-FPM进程池在后台默默等待，Nginx收到请求后，把PHP相关的URI转发给9000端口——这个动作快得几乎察觉不到延迟。我见过太多新手把PHP处理写成proxy_pass http://127.0.0.1:9000;，结果静态文件也走PHP，服务器负载直接飙升。正确做法是用location ~ \.php$匹配，正则里带个结尾符，别让.css或.js文件误闯进来。

调优这件事，得从实际访问量出发。有一次给一个日活两万的论坛做优化，默认的pm.max_children设成5，高峰期PHP响应时间直接飙到3秒。改成动态模式，pm.max_children设为50，pm.start_servers设20，配合pm.max_requests设500防止内存泄漏，响应时间降到200毫秒以内。但你要给个日活几百的小站配50个进程，纯属浪费内存——每进程吃30MB，50个就是1.5GB，小内存机器直接OOM。

Nginx的fastcgi_params文件里有个坑。默认配置不带SCRIPT_FILENAME，很多人手动加的时候写错路径，导致所有PHP请求返回404。正确写法是fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;。别问我是怎么知道的——排查了一下午，最后发现是$document_root变量在alias目录下失效，换成绝对路径才解决。

CentOS的SELinux是另一个隐形杀手。你权限配得再好，SELinux enforcing模式下，Nginx进程就是没法连接PHP-FPM的unix socket。要么setsebool -P httpd_can_network_connect 1，要么干脆用TCP方式监听127.0.0.1:9000。我习惯用TCP，虽然unix socket理论上更快，但TCP模式在排查问题时更直观，netstat -an | grep 9000一眼能看到连接状态。

版本搭配讲究个门当户对。CentOS 7自带的PHP 5.4太老，好多新语法不支持。用Remi仓库装PHP 7.4或8.0，性能提升立竿见影——PHP 7比5.6快两倍不是吹的。Nginx同理，EPEL源里版本旧，直接加官方nginx仓库拿最新稳定版。但别追新，8.1刚出时我试过，跟某些老扩展不兼容，生产环境老老实实待在主流的7.4或8.0上。

日志是诊断问题的第一现场。Nginx的error.log里出现connect() failed (111: Connection refused)，八成是PHP-FPM没启动。而upstream sent too big header则说明fastcgi缓冲区太小，调大fastcgi_buffer_size和fastcgi_buffers就行。我见过有人遇到502就重启服务，治标不治本——先看日志，再动手，省得瞎折腾。

写到这里，突然想起一个经典场景。你改了php.ini后reload PHP-FPM，但Nginx那边还缓存着旧的fastcgi参数——这种玄学问题多半是没重启Nginx。两个服务都得平滑重启，kill -USR2 $(cat /var/run/php-fpm.pid)配合nginx -s reload，才算真正让配置生效。这套组合拳打熟练了，CentOS上跑PHP应用，基本能睡个安稳觉。