CentOS 8 LEMP 部署实战：dnf、SELinux 与 systemd 深度适配指南

1. 为什么在 CentOS 8 上部署 LEMP 不是“照着命令敲一遍”就能完事？

LEMP（Linux, Nginx, MySQL, PHP）这个缩写，对老手来说像呼吸一样自然；但对刚从 Windows 环境转过来、或第一次在生产级服务器上搭 Web 环境的人来说，它背后藏着一整套 系统级协作逻辑 ，而不是四个独立软件的简单拼接。我见过太多人卡在“Nginx 启动了但打不开页面”“PHP 文件直接下载不执行”“MySQL 能连上但 PHP 里 mysqli_connect() 报错”，最后翻遍教程才发现——问题根本不在某一行命令写错了，而在于没理解 CentOS 8 的底层机制切换。

最核心的断层点，就藏在标题里的那个词： CentOS 8 。它不是 CentOS 7 的简单升级版，而是整个系统哲学的转向。CentOS 8 在 2019 年发布时，正式将 dnf （Dandified YUM）作为默认包管理器，彻底取代了沿用多年的 yum；同时，它把 systemd 的服务管控逻辑推到了极致，连传统的 /etc/init.d/ 脚本都成了“兼容性遗产”；更关键的是，它默认启用了 SELinux 的 enforcing 模式 ，且策略比以往更严格——这意味着你哪怕把 Nginx 配置文件改得再完美，只要 PHP-FPM 进程试图读取 /var/www/html 下的 .php 文件，SELinux 就可能默默拦截并记一条 audit 日志，而你的浏览器只显示一个冰冷的 502 Bad Gateway。

这直接导致一个现实后果：网上大量标着“CentOS 7 LEMP 教程”的内容，在 CentOS 8 上照搬运行，十有八九会失败。不是命令过时，而是 上下文失效 。比如 yum install php-fpm 在 CentOS 8 上会报错，因为 php-fpm 已被拆进 php-fpm 和 php-common 等多个子包；再比如 firewall-cmd --permanent --add-service=http 这条命令看似没变，但如果你没顺手加 --add-service=https ，又或者忘了 firewall-cmd --reload ，那 HTTPS 站点永远对外不可见——而这些细节，90% 的速成教程根本不会提。

所以，这篇内容不叫“LEMP 安装教程”，它是一份 CentOS 8 系统环境下的 LEMP 协同部署手册 。它要回答的不是“怎么装”，而是“为什么必须这样装”“装完之后哪些地方最容易出哑巴故障”“当 Nginx 显示 502 时，你该按什么顺序查日志”。它面向的不是想“快速跑个 demo”的人，而是准备把这套环境用于真实项目、需要长期维护、甚至要向团队交付标准化部署方案的开发者和运维人员。关键词里没有填任何内容，恰恰说明——这不是一个带营销属性的泛泛而谈，而是一个需要你沉下心来、逐行理解、亲手验证的技术动作。

提示：本文所有命令均基于 CentOS 8.5 Minimal 安装镜像实测通过。如果你用的是 CentOS Stream 或 Rocky Linux / AlmaLinux（它们是 CentOS 8 的精神继承者），命令完全一致；但若你还在用 CentOS 7，请立刻停止阅读，去查专为 7 设计的文档——混用会导致系统包管理器混乱，修复成本远高于重装。

2. 环境初始化：三步封死 CentOS 8 的“默认陷阱”

很多教程跳过这一步，直接开装 Nginx，结果后面三天都在排查权限和防火墙问题。在 CentOS 8 上， 环境初始化不是可选项，而是强制前置步骤 。它包含三个相互咬合的动作，缺一不可，我称之为“三步封死”。

2.1 第一步：确认并锁定 dnf 源与 EPEL 扩展仓库

CentOS 8 默认的 baseos 和 appstream 仓库只提供最基础、最稳定的软件包。像 Nginx 的最新稳定版（1.20+）、PHP 7.4/8.0、以及 MySQL 8.0 的完整客户端工具，都藏在 EPEL（Extra Packages for Enterprise Linux） 仓库里。但 EPEL 不是默认启用的，而且它的启用方式在 CentOS 8 和 7 上完全不同。

在 CentOS 8 中，你不能像以前那样 yum install epel-release 。正确姿势是：

# 先清理可能残留的旧仓库缓存
sudo dnf clean all

# 安装 EPEL 仓库元数据包（注意：不是 epel-release，而是 centos-linux-release）
sudo dnf install -y epel-release

# 验证是否成功启用
sudo dnf repolist | grep -E "(epel|appstream|baseos)"

执行完后，你应该看到类似这样的输出：

appstream          CentOS Linux 8 - AppStream
baseos             CentOS Linux 8 - BaseOS
epel               Extra Packages for Enterprise Linux 8 - x86_64

为什么这一步必须做？因为 dnf install nginx 如果只走 baseos 仓库，装出来的可能是 Nginx 1.14（CentOS 8 默认源里的版本），它缺少 stream 模块（用于 TCP/UDP 代理），也缺乏对 HTTP/2 的完整支持。而 EPEL 提供的是 Nginx 1.20.x，这才是现代 Web 服务的基准线。我曾帮一个客户排查慢查询，最后发现根源就是 Nginx 版本太老，HTTP/2 握手耗时比预期多出 300ms——这种坑，完全可以通过初始化时选对仓库避免。

2.2 第二步：永久关闭 NetworkManager 对防火墙的干扰

CentOS 8 默认启用 NetworkManager，它会自动管理网络接口，包括防火墙规则。但 firewall-cmd 是 firewalld 的命令行接口，而 firewalld 又依赖于底层的 nftables。NetworkManager 有时会“好心办坏事”，在你手动添加端口后，又悄悄把它删掉，导致服务明明启动了却无法访问。

解决方法不是禁用 NetworkManager（它负责 DHCP、WiFi 等核心功能），而是告诉它：“别碰防火墙”。

# 编辑 NetworkManager 配置
sudo nano /etc/NetworkManager/NetworkManager.conf

在 [main] 段落下方，添加这一行：

[main]
firewall-backend=none

然后重启 NetworkManager：

sudo systemctl restart NetworkManager

注意：这行配置的意思是“让 NetworkManager 完全不参与防火墙管理”，把控制权 100% 交给 firewalld。这是 CentOS 8 的最佳实践，也是 Red Hat 官方文档明确推荐的配置。跳过这步，你后续用 firewall-cmd 添加的规则可能在下次网络重连后消失。

2.3 第三步：预设 SELinux 策略，避免 PHP-FPM 成为“透明人”

SELinux 是 CentOS 的安全基石，但在 Web 服务部署中，它常常是那个“看不见的凶手”。默认情况下，SELinux 会阻止 Nginx 主进程（运行在 httpd_t 域）去执行 PHP 脚本，也会阻止 PHP-FPM 子进程（运行在 php_fpm_t 域）去读取网站根目录下的文件（默认标签是 system_u:object_r:httpd_sys_content_t:s0 ）。结果就是： .php 文件不解析，Nginx 返回 403 或 502。

最稳妥的做法，不是粗暴地 setenforce 0 （这等于卸掉盔甲上战场），而是给 Web 内容目录打上正确的 SELinux 标签，并允许必要的网络连接：

# 给网站根目录（假设是 /var/www/html）设置标准 Web 内容标签
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"

# 应用标签变更（-R 表示递归）
sudo restorecon -Rv /var/www/html

# 允许 PHP-FPM 连接网络（例如访问 MySQL）
sudo setsebool -P httpd_can_network_connect_db 1

# 允许 Nginx 执行