CentOS7 下 Nginx 与 PHP-FPM 部署要点

对于许多运维工程师来说，在CentOS 7上部署Nginx与PHP-FPM的组合，听起来像是老生常谈。但恰恰是这套“经典”的LNP架构，其稳定性与性能的上限，往往取决于部署时那些容易被忽略的细枝末节。一次成功的部署，远不止于让服务“跑起来”那么简单。

软件源的选择：稳定性的第一道防线

很多人会直接使用默认的EPEL源，或者随意找一个第三方仓库。这其实埋下了隐患。Nginx官方维护的稳定版仓库和Webtatic提供的PHP 7.0仓库，之所以被广泛推荐，并非没有道理。官方仓库意味着更严格的兼容性测试和及时的安全更新，这对于生产环境至关重要。一个未经充分测试的第三方源，可能会引入与CentOS 7核心库不兼容的依赖，导致系统出现难以排查的诡异问题。

在添加源之后，一个常被遗忘的步骤是验证GPG密钥。使用rpm -import导入仓库的公钥，能确保后续安装的软件包未被篡改。听起来有点偏执？但在安全领域，偏执往往就是专业。

进程通信：Unix Socket还是TCP端口？

Nginx与PHP-FPM的通信，默认配置文件通常指向127.0.0.1:9000。这没错，但并非最优。将通信方式改为Unix Domain Socket（如/var/run/php-fpm/www.sock）能带来实实在在的性能提升。

你可以做个简单的测试：使用ab或wrk工具对两种配置进行压力测试。在大多数场景下，Unix Socket能减少TCP协议栈的开销，降低延迟，尤其是在高并发短连接的请求模式下，优势更为明显。当然，这需要确保Nginx的工作进程（通常是nginx用户）对Socket文件所在的目录有读写权限——这又是一个权限配置的坑点。

调整FPM进程管理器：static, dynamic, ondemand？

打开/etc/php-fpm.d/www.conf，pm参数的设置直接决定了服务器的资源利用模式和响应能力。

• static（静态）：固定数量的子进程。适用于流量稳定、内存充足的环境。优点是无进程创建销毁开销，响应最快；缺点是空闲时也占用内存。
• dynamic（动态）：在设定的最小和最大进程数之间动态调整。这是最常用的配置，需要在pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers之间取得平衡。设置pm.max_requests可以定期重启子进程，避免内存泄漏。
• ondemand（按需）：请求到来时才启动进程，处理完空闲一段时间后销毁。适用于低流量、且对延迟不敏感的场景，非常节省资源。

选择哪种模式，取决于你的服务器硬件和流量模型。一台2核4G的虚拟机跑一个小型WordPress站点，用dynamic模式，把pm.max_children设为30可能都绰绰有余；而一个高并发的API服务器，可能需要static模式来榨干CPU性能。

SELinux与文件上下文：那只看不见的手

很多人部署失败后，第一反应是关闭SELinux。这无异于因噎废食。SELinux是CentOS 7重要的安全屏障。正确的做法是理解并配置它。

如果您的网站根目录不在/usr/share/nginx/html，比如在/data/www，那么Nginx进程很可能因为没有权限读取该目录下的文件而返回403错误。此时，需要使用semanage fcontext和restorecon命令，为你的网站目录打上正确的SELinux文件上下文标签，例如httpd_sys_content_t。

semanage fcontext -a -t httpd_sys_content_t '/data/www(/.*)?'
restorecon -Rv /data/www

同样，如果使用Unix Socket通信，也要检查Socket文件的标签是否为httpd_var_run_t。这些细节，决定了你的服务是在安全框架内优雅运行，还是在门外磕磕绊绊。

日志：不仅仅是记录错误

部署完成后，别急着关掉终端。打开/var/log/nginx/access.log和/var/log/php-fpm/www-error.log。前者告诉你用户是如何访问的，后者则揭示了应用内部的运行状况。将PHP-FPM的slowlog功能打开，设置一个合理的超时时间（如5秒），它能帮你捕捉到那些拖慢整个池子的“慢请求”，是性能调优的利器。

说到底，在CentOS 7上部署Nginx和PHP-FPM，拼的不是谁记得命令多，而是谁对这套协作体系的理解更透彻。每一个参数背后，都是对资源、安全与效率的权衡。