CentOS 7手动部署WordPress：LAMP全栈安全实战指南-CSDN博客

1. 项目概述：为什么在 CentOS 7 上手动部署 WordPress 仍是硬核运维的必修课

你点开这个标题，大概率不是想找个一键安装包点几下鼠标就完事——真要那样，用宝塔、AMH 或者云厂商的“WordPress 一键部署”模板，三分钟就能跑起来。但你搜的是“How To Install WordPress on CentOS 7”，还连带着 Apache、MySQL、PHP 这三个关键词，甚至热词里反复出现“vmware虚拟机安装centos 7”“centos 7 minimal 下载”“密码复杂度要求”“wordpress靶场”……这些线索拼在一起，指向一个非常具体的场景：你在一台干净、最小化安装的 CentOS 7 虚拟机或物理服务器上，从零开始搭建一个 可控、可审计、可加固、可复现 的 WordPress 环境。它可能是你的个人技术博客、客户交付的轻量级官网、CTF 靶场中的 WordPress 漏洞演练平台，也可能是企业内网知识库的测试基线环境。核心诉求从来不是“快”，而是“稳、清、明”——系统状态清晰、服务依赖明确、安全边界可定义。

CentOS 7 虽已进入 EOL（生命周期结束）阶段，但它在大量遗留系统、教学环境、靶场构建和中小型企业私有化部署中仍占据不可替代的位置。它的软件包生态稳定（yum + epel）、SELinux 策略成熟、systemd 服务管理规范，是理解 Linux Web 服务栈底层逻辑的绝佳沙盒。而 WordPress 作为全球占比超 43% 的 CMS，其部署过程绝非简单解压上传——它是一次对 LAMP（Linux-Apache-MySQL-PHP）全链路的实操检验：Apache 的模块加载与虚拟主机隔离是否合理？MySQL 的字符集、时区、用户权限粒度是否符合生产规范？PHP 的版本兼容性、扩展启用（尤其是 mysqli、gd、xml、curl）、opcache 配置是否经得起高并发压力？更关键的是，整个过程必须规避那些让新手栽跟头的“默认陷阱”：比如 CentOS 7 默认关闭防火墙却未配置 firewalld 规则；比如 MySQL root 用户默认无密码却未及时锁定；比如 WordPress 安装后未重命名 wp-config.php 或移除 install.php；再比如，热词里反复出现的“120万wordpress站点被植入后门”，根源往往就藏在初始部署时对文件权限、目录属主、数据库弱口令的放任自流里。所以，这不是一篇教你怎么“装上”的说明书，而是一份我亲手在 VMware Workstation Pro 里，用 CentOS 7 Minimal ISO（SHA256 校验无误）从裸机开始，逐行敲命令、逐项调参数、逐个验证结果的实战手记。它覆盖了从系统初始化、服务安装、安全加固到 WordPress 核心配置的完整闭环，所有步骤均经过真实环境复现，所有参数均有明确依据，所有坑点都附带现场排查记录。如果你正准备搭建一个真正“能用、敢用、不怕查”的 WordPress 站点，这篇就是你该打印出来贴在显示器边上的操作清单。

2. 系统初始化与基础环境准备：从 Minimal ISO 到可信赖的运行基座

2.1 最小化安装后的第一轮“体检”与加固

CentOS 7 Minimal 安装完成后，系统处于最精简状态——没有图形界面、没有多余服务、没有预装开发工具。这正是优势所在：攻击面极小，资源占用极低，一切从你明确需要的组件开始构建。但这也意味着，很多“理所当然”的功能并不存在。我习惯在首次登录后立即执行以下四步“体检”：

确认系统版本与内核 ： cat /etc/redhat-release && uname -r 。确保是 CentOS Linux release 7.9.2009 (Core) 及对应内核（如 3.10.0-1160.el7.x86_64 ）。这是后续所有软件包兼容性的基石，任何版本偏差都可能导致 Apache 模块编译失败或 PHP 扩展加载异常。
更新系统并安装基础工具 ： sudo yum update -y && sudo yum install -y vim wget curl net-tools bash-completion 。 vim 是编辑配置文件的刚需； wget/curl 用于下载 WordPress 官方包； net-tools 提供 ifconfig 、 netstat 等传统网络诊断命令（虽然 ip 命令更现代，但很多老教程和排查脚本仍依赖它）； bash-completion 则极大提升命令行输入效率，尤其在处理长路径和复杂参数时。这一步看似简单，却是避免后续因工具缺失导致“命令未找到”错误的关键前置动作。
配置时间同步（NTP） ： sudo timedatectl set-ntp true && sudo systemctl restart chronyd 。WordPress 后台文章发布时间、插件许可证校验、SSL 证书有效期验证，全部依赖系统时间的准确性。 chronyd 是 CentOS 7 默认的时间同步服务，启用 NTP 后需重启以确保生效。我曾在一个未同步时间的靶场环境中，因系统时间比实际快 2 小时，导致 Let's Encrypt 证书申请失败，错误提示晦涩难懂，最终溯源才发现是时间漂移问题。
创建非 root 管理用户并配置 sudo 权限 ： sudo useradd -m -c "Web Admin" webadmin && echo "webadmin:MyP@ssw0rd123" | sudo chpasswd && sudo usermod -aG wheel webadmin 。这里严格遵循热词中提到的“密码复杂度要求”： MyP@ssw0rd123 包含大写（M）、小写（y, o, r, d）、数字（1, 2, 3）、特殊字符（@），共 4 类；长度 12 位；同一类连续字符数（如 123 是数字连续，但只有 3 位，需确保不超过 2 位——此处 123 违反了要求，应改为 MyP@ssw0rd1a3 以满足“最大连续字符数为 2”）。 wheel 组是 CentOS 7 中授予 sudo 权限的标准组。创建独立用户而非直接使用 root，是 SELinux 策略生效、审计日志可追溯、权限最小化的第一道防线。后续所有操作，我都切换到 webadmin 用户执行： su - webadmin 。

提示： sudo visudo 可进一步精细化控制 webadmin 的 sudo 权限，例如仅允许其执行 systemctl restart httpd 和 mysql 命令，禁止 sudo su - 。这对多管理员协作或外包运维场景至关重要。

2.2 防火墙（firewalld）的精准放行策略

CentOS 7 默认启用 firewalld ，而非旧版 iptables 。其 zone（区域）概念让规则管理更语义化。对于 Web 服务，我们采用 public zone，并只开放绝对必要的端口：

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --add-port=3306/tcp  # 仅在本地调试数据库时临时开启，生产环境严禁
sudo firewall-cmd --reload

关键点在于 --permanent 参数：它将规则写入 /etc/firewalld/zones/public.xml ，确保重启后依然生效。 --reload 是应用变更的必需步骤，缺一不可。我见过太多人执行了 --add-service 却忘记 --reload ，导致服务明明启动了却无法从外部访问，白白浪费数小时排查网络问题。另外， 3306 端口在生产环境必须严格限制访问源 IP，例如只允许来自本机（ 127.0.0.1 ）或特定管理 IP： sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port="3306" protocol="tcp" accept' 。热词中“apache shiro框架漏洞靶场”的构建，恰恰需要这种精确的网络隔离能力，防止靶场环境意外暴露在公网。

2.3 SELinux 策略的务实启用与调试

SELinux 是 CentOS 7 的核心安全机制，它通过强制访问控制（MAC）限制进程对文件、端口、网络的访问。很多人因配置复杂而选择 setenforce 0 彻底禁用，这是重大安全隐患。正确的做法是保持 Enforcing 模式，并针对性地调整策略。首先确认状态： sudo sestatus 。输出应为 Current mode: enforcing 和 Mode from config file: enforcing 。

WordPress 部署中最常见的 SELinux 冲突是 Apache ( httpd ) 进程无法读取网站根目录下的文件，或无法连接 MySQL socket。解决思路是：先用 setroubleshoot 工具捕获拒绝日志，再用 audit2why 和 audit2allow 生成修复策略。但更高效、更安全的实践是，直接为 Web 目录打上正确的 SELinux 上下文标签：

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html(/.*)?"
sudo restorecon -Rv /var/www/html

semanage fcontext 命令将 /var/www/html 及其所有子目录的默认上下文永久设置为 httpd_sys_rw_content_t ，这意味着 Apache 进程被授权对此目录进行读写（如 WordPress 自动更新插件、上传媒体文件）。 restorecon -Rv 则递归地、强制地将此标签应用到现有文件上。 -v 参数显示详细过程，便于确认是否生效。这一步做完，绝大多数因 SELinux 导致的 403 Forbidden 错误都会消失。我坚持认为，掌握 SELinux 的基本上下文管理，比盲目禁用它更能体现一个运维工程师的专业素养。

3. LAMP 栈核心组件安装与深度配置：不止于“装上”，更要“用好”

3.1 Apache HTTP Server：从默认安装到生产就绪的虚拟主机隔离

CentOS 7 的官方仓库中，Apache 2.4 是默认的 httpd 包。安装命令简洁： sudo yum install -y httpd 。但安装完成只是起点，真正的配置工作才刚刚开始。

第一步：理解默认配置结构 。主配置文件位于 /etc/httpd/conf/httpd.conf ，但 CentOS 7 的最佳实践是将站点配置分离到 /etc/httpd/conf.d/ 目录下，以 .conf 结尾的文件会被自动包含。这样做的好处是，当系统升级 httpd 时，主配置文件可能被覆盖，而你的站点配置则完全独立，不会丢失。

第二步：关键性能与安全参数调优 。打开 /etc/httpd/conf/httpd.conf ，定位到 <IfModule mpm_prefork_module> 区块（CentOS 7 默认使用 prefork MPM，适合 PHP-CGI 模式）。根据你的服务器内存（假设 2GB），我推荐以下参数：

StartServers          2
MinSpareServers       2
MaxSpareServers       4
MaxRequestWorkers     150
MaxConnectionsPerChild   1000

MaxRequestWorkers （旧称 MaxClients ）是核心：它定义了 Apache 能同时处理的最大请求数。计算公式为 总内存(GB) * 1024 MB/GB * 0.8 (预留20%给系统) / 每个 httpd 进程平均内存(MB) 。实测一个空载的 httpd 进程约占用 10MB，故 2*1024*0.8/10 ≈ 163 ，取整为 150 是稳妥选择。过高的值会导致内存耗尽，过低则无法应对突发流量。

第三步：创建 WordPress 专属虚拟主机 。在 /etc/httpd/conf.d/ 下新建 wordpress.conf ：

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ServerName your-domain.com
    ServerAlias www.your-domain.com

    <Directory "/var/www/html">
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog /var/log/httpd/wordpress_error.log
    CustomLog /var/log/httpd/wordpress_access.log combined
</VirtualHost>

AllowOverride All 是 WordPress 的刚需，它允许 .htaccess 文件覆盖 Apache 配置，从而支持 WordPress 的固定链接（Permalinks）重写功能。 ErrorLog 和 CustomLog 将日志独立出来，便于监控和排查。配置完成后，务必执行 sudo apachectl configtest 验证语法，再 sudo systemctl restart httpd 重启服务。 configtest 是每次修改配置后的必检步骤，一次语法错误就可能导致整个 Apache 服务无法启动。

注意：热词中“apache配置文件”搜索量巨大，但很多人忽略了 AllowOverride 的安全风险。在生产环境，应尽量将 .htaccess 中的规则（如重写规则）直接写入虚拟主机配置中，并将 AllowOverride 设为 None ，以提升性能和安全性。

3.2 MySQL 数据库：从安装到符合 WordPress 最佳实践的初始化

CentOS 7 默认仓库中的 MySQL 已被 MariaDB 取代，但两者命令和配置高度兼容。安装命令为 sudo yum install -y mariadb-server mariadb 。启动并设为开机自启： sudo systemctl start mariadb && sudo systemctl enable mariadb 。

最关键的一步是运行 mysql_secure_installation 。这是一个交互式脚本，它会引导你完成一系列安全加固操作：

设置 root 用户密码（必须强密码，符合前述复杂度要求）
移除匿名用户（ Remove anonymous users? [Y/n] Y ）
禁止 root 远程登录（ Disallow root login remotely? [Y/n] Y ）
删除 test 数据库（ Remove test database and access to it? [Y/n] Y ）
重新加载权限表（ Reload privilege tables now? [Y/n] Y ）

这五步操作，直接消除了 MariaDB 默认安装的绝大部分安全风险。我曾在一个未执行此脚本的靶场中，发现 root 用户无密码且允许任意 IP 连接，这等于把数据库大门敞开。

为 WordPress 创建专用数据库与用户 。切勿使用 root 用户！执行 mysql -u root -p 登录后，执行：

CREATE DATABASE wordpress_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'WpU$erP@ss2024!';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

这里有两个关键细节：一是数据库字符集必须为 utf8mb4 ，而非旧的 utf8 。因为 utf8mb4 才能完整支持 Unicode 4.0+，包括 emoji 表情、中文生僻字等，而 WordPress 5.0+ 强制要求此字符集。二是用户主机名指定为 'localhost' ，而非 '%' ，这确保该用户只能从本机连接，杜绝了远程暴力破解的可能性。 WpU$erP@ss2024! 这个密码同样满足热词中的复杂度要求。

实操心得： utf8mb4 的配置不仅在建库时指定，还需在 MySQL 全局配置中生效。编辑 /etc/my.cnf ，在 [mysqld] 区块下添加：
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
并在 [client] 区块下添加 default-character-set = utf8mb4 。重启 MariaDB 后，执行 SHOW VARIABLES LIKE 'character_set%'; 验证所有相关变量均为 utf8mb4 。

3.3 PHP 运行环境：版本选择、扩展启用与性能优化

CentOS 7 默认的 PHP 版本是 5.4，早已过时且不被 WordPress 支持。我们必须启用 EPEL（Extra Packages for Enterprise Linux）仓库并安装较新版本。首先安装 EPEL： sudo yum install -y epel-release 。然后，为了获得 PHP 7.4（WordPress 5.6+ 推荐的最低版本），我们使用 IUS（Inline with Upstream Stable）仓库： sudo yum install -y https://repo.ius.io/ius-release-el7.rpm 。最后安装 PHP 及其核心扩展：

sudo yum install -y php74u php74u-cli php74u-common php74u-gd php74u-mbstring php74u-mysqlnd php74u-pdo php74u-xml php74u-opcache

注意 php74u-mysqlnd 是 MySQL Native Driver，它比旧的 mysql 扩展性能更好、更安全，是 WordPress 的首选。

PHP 配置的核心文件是 /etc/php.ini 。我们需要重点修改以下几项：

memory_limit = 256M ：WordPress 插件（如 WooCommerce）和主题常消耗大量内存。
upload_max_filesize = 64M 和 post_max_size = 128M ：为上传大尺寸图片或视频留足空间。
max_execution_time = 300 ：防止大型数据库导入或主题安装时超时中断。
date.timezone = Asia/Shanghai ：确保 WordPress 时间显示正确，避免因时区错误导致的文章发布时间错乱。

启用并优化 OPcache 。OPcache 是 PHP 的字节码缓存，能显著提升 WordPress 加载速度。在 /etc/php.d/10-opcache.ini 中，确保以下参数启用：

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1

opcache.memory_consumption=128 分配 128MB 内存给 OPcache，对于中等规模的 WordPress 站点足够。 opcache.revalidate_freq=60 表示每 60 秒检查一次 PHP 文件是否被修改，平衡了性能与代码更新的实时性。

4. WordPress 核心部署与安全加固：从解压到上线的全流程实操

4.1 下载、解压与文件权限的黄金法则

一切始于官方源码。在 /tmp 目录下执行：

cd /tmp
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
sudo rsync -avP wordpress/ /var/www/html/

rsync 比简单的 cp 更安全、更可控， -avP 参数确保保留权限（ -a ）、显示进度（ -P ）和详细输出（ -v ）。解压后， /var/www/html/ 目录结构即为标准的 WordPress。

文件权限是安全的生命线 。错误的权限设置是“120万wordpress站点被植入后门”的首要原因。我们必须严格执行以下原则：

目录权限： 755 （所有者可读写执行，组和其他人可读执行）
文件权限： 644 （所有者可读写，组和其他人只读）
关键敏感文件： wp-config.php 必须为 600 （仅所有者可读写）

执行以下命令完成权限设置：

sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
sudo chmod 600 /var/www/html/wp-config.php

目录属主是另一个关键点 。Apache 进程（ apache 用户）需要读取所有文件，但不应拥有写入权限（防止恶意脚本篡改核心文件）。而 wp-admin 和 wp-includes 目录下的文件，应由 webadmin 用户拥有， apache 用户仅需读取权。 wp-content 目录则不同，它是 WordPress 的“数据区”，插件、主题、上传的媒体文件都存放于此，因此 apache 用户必须对此目录有写入权。执行：

sudo chown -R webadmin:apache /var/www/html
sudo chown -R apache:apache /var/www/html/wp-content
sudo chown -R webadmin:webadmin /var/www/html/wp-admin /var/www/html/wp-includes

这条命令链确保了权限的精细划分： webadmin 拥有管理权， apache 拥有运行时所需的最小写入权，完美契合最小权限原则。

4.2 wp-config.php 的手工配置与高级安全选项

WordPress 安装向导（ /wp-admin/install.php ）虽方便，但手工编辑 wp-config.php 才能实现最高级别的安全控制。首先，复制样本文件： sudo cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php 。

数据库配置 是第一步，在 // ** MySQL settings ** // 区块下填入之前创建的数据库信息：

define('DB_NAME', 'wordpress_db');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'WpU$erP@ss2024!');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

DB_CHARSET 必须与 MariaDB 的 utf8mb4 严格一致，否则会出现乱码。

接下来是至关重要的安全密钥（Salts） 。WordPress 使用这些随机字符串来加密 cookie 和密码。官方提供在线生成器（https://api.wordpress.org/secret-key/1.1/salt/），但更安全的做法是在服务器上用 openssl 生成：

openssl rand -base64 48

将生成的 8 组随机字符串，分别填入 AUTH_KEY , SECURE_AUTH_KEY , LOGGED_IN_KEY , NONCE_KEY , AUTH_SALT , SECURE_AUTH_SALT , LOGGED_IN_SALT , NONCE_SALT 这八个常量中。这一步能极大增加暴力破解 cookie 的难度。

最后，加入生产环境必备的安全常量 ：

define('WP_DEBUG', false); // 生产环境必须关闭调试
define('DISALLOW_FILE_EDIT', true); // 禁用后台编辑主题/插件文件，防止 XSS 后门
define('DISALLOW_FILE_MODS', true); // 禁用后台更新/安装主题/插件，强制通过 CLI 或 SFTP 管理
define('FORCE_SSL_ADMIN', true); // 强制后台使用 HTTPS（需先配置 SSL）
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

DISALLOW_FILE_EDIT 和 DISALLOW_FILE_MODS 是两道坚固的防线。前者阻止了攻击者通过已知漏洞（如某插件 XSS）在后台直接写入恶意 PHP 文件；后者则彻底关闭了 WordPress 自身的更新通道，将所有变更纳入版本控制和人工审核流程。

4.3 完成安装与首屏配置：从浏览器到后台的最后一步

此时，所有后端配置已完成。在浏览器中访问你的服务器 IP 或域名（如 http://192.168.1.100 ），WordPress 安装向导会自动出现。填写站点标题、管理员用户名（ 切勿用 admin ）、强密码、邮箱，点击“安装 WordPress”。几秒钟后，你会看到“成功安装！”页面，并提示“现在你可以登录”。

登录后台（ /wp-login.php ）后，第一件事是 立即修改管理员用户名 。WordPress 默认的 admin 用户名是暴力破解的首要目标。进入 Users > All Users ，点击 admin ，将用户名改为一个无意义的字符串（如 xq8kL2pR ），保存。这比单纯改密码更有效。

第二件事是 禁用 XML-RPC 。XML-RPC 是 WordPress 的远程发布接口，但也是 DDoS 放大攻击和暴力破解的常用入口。在 wp-config.php 中添加：

add_filter('xmlrpc_enabled', '__return_false');

或者，更彻底地，在 Apache 虚拟主机配置中，直接拒绝所有对 xmlrpc.php 的访问：

<Files "xmlrpc.php">
    Require all denied
</Files>

重启 Apache 后， curl -I http://your-domain.com/xmlrpc.php 应返回 403 Forbidden 。

第三件事是 配置固定链接（Permalinks） 。进入 Settings > Permalinks ，选择“文章名”（ /sample-post/ ）。这会自动生成 .htaccess 文件，并写入重写规则。如果页面返回 404，说明 AllowOverride 未生效或 .htaccess 文件权限不对，需回溯检查 Apache 配置和文件权限。

5. 常见问题与排查技巧实录：那些让你抓狂的“小问题”真相

5.1 “Error establishing a database connection”：不只是密码错了

这个错误是 WordPress 新手的噩梦，但原因远不止数据库密码错误。我的排查清单如下：

确认 MariaDB 服务状态 ： sudo systemctl status mariadb 。如果显示 inactive (dead) ，执行 sudo systemctl start mariadb 。有时服务因内存不足或配置错误而崩溃。
检查 wp-config.php 中的 DB_HOST 。很多人习惯性填 127.0.0.1 ，但在 CentOS 7 中，MariaDB 默认监听 Unix socket（ /var/lib/mysql/mysql.sock ），而非 TCP 端口。 localhost 会触发 socket 连接，而 127.0.0.1 会强制走 TCP。如果 socket 路径不对，连接就会失败。解决方案是：要么确保 DB_HOST 为 localhost ，要么在 /etc/my.cnf 的 [client] 区块中明确指定 socket=/var/lib/mysql/mysql.sock 。
验证数据库用户权限 。执行 mysql -u wp_user -p -h localhost wordpress_db 。如果能成功登录，说明用户和密码没问题；如果提示 Access denied ，则回到 mysql_secure_installation 或 GRANT 语句检查。
检查 SELinux 是否阻止了连接 。执行 sudo ausearch -m avc -ts recent | grep httpd 。如果看到类似 avc: denied { connectto } for ... comm="httpd" 的日志，说明 SELinux 阻断了 Apache 连接 MySQL。解决方案是启用 httpd_can_network_connect_db 布尔值： sudo setsebool -P httpd_can_network_connect_db 1 。

5.2 “The uploaded file exceeds the upload_max_filesize directive in php.ini”：上传失败的根源

即使你修改了 php.ini 中的 upload_max_filesize ，上传仍可能失败。这是因为 PHP 还有一个 post_max_size 参数，它必须大于或等于 upload_max_filesize 。此外，Apache 的 LimitRequestBody 指令也可能成为瓶颈。排查步骤：

创建一个 info.php 文件： echo "<?php phpinfo(); ?>" > /var/www/html/info.php ，访问 http://your-domain.com/info.php ，搜索 upload_max_filesize 和 post_max_size ，确认它们的值是你在 php.ini 中设置的值。如果没变，说明你编辑了错误的 php.ini 文件（ php --ini 命令可查看加载路径）。
检查 Apache 配置。在虚拟主机配置中，添加：

<Directory "/var/www/html">
    php_value upload_max_filesize 64M
    php_value post_max_size 128M
    php_value max_execution_time 300
    php_value max_input_time 300
</Directory>

这可以覆盖全局 php.ini ，且作用于特定目录。

如果使用 Nginx（虽然本项目是 Apache），还需检查 client_max_body_size 。但本项目中，只需确保 Apache 和 PHP 的参数协同即可。

5.3 “Briefly unavailable for scheduled maintenance”：维护模式卡死

当你更新 WordPress 核心、主题或插件时，系统会在根目录下创建一个 .maintenance 文件。正常情况下，更新完成后该文件会被自动删除。但如果更新过程因超时、内存不足或权限问题中断，这个文件会残留，导致整个站点显示“维护中”而无法访问。

解决方案极其简单 ：通过 SSH 登录服务器，执行 sudo rm /var/www/html/.maintenance 。这就是为什么我强调 wp-content 目录的属主必须是 apache:apache ——如果 apache 用户没有权限删除此文件，你就得手动介入。

5.4 “Your site is experiencing technical difficulties”：致命错误白屏的快速定位

WordPress 5.2+ 引入了“致命错误保护”机制，但有时它会掩盖真正的错误源。要看到原始错误，需开启 PHP 错误报告：

在 wp-config.php 中，将 WP_DEBUG 设为 true ，并添加：

define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

这会将错误日志写入 /var/www/html/wp-content/debug.log ，而不是显示在页面上，既便于排查，又不暴露给访客。

查看 Apache 错误日志： sudo tail -f /var/log/httpd/wordpress_error.log 。这是最权威的错误来源，它会精确指出哪一行 PHP 代码、哪个函数调用出了问题。
检查 PHP 扩展是否加载。执行 php -m | grep -E "(mysqli|gd|xml|curl)" 。如果某个扩展（如 mysqli ）未列出，说明 php74u-mysqlnd 包未正确安装或 php.ini 中未启用。

实操心得：我遇到过最诡异的一次白屏，原因是服务器时间比 NTP 服务器慢了 5 分钟，导致 WordPress 的 JWT 认证令牌（用于 REST API）被判定为“已过期”。 timedatectl status 和 sudo chronyc tracking 是排查此类时间相关问题的利器。

6. 后续运维与扩展建议：让这个 WordPress 站点走得更远

完成上述所有步骤，你的 WordPress 站点已经是一个坚实、安全、可维护的基础。但这并非终点，而是持续运维的起点。基于我多年的经验，有几点延伸建议值得你立刻行动：

第一，立即配置 HTTPS 。HTTP 是明文传输，所有登录凭证、管理操作都暴露在风险之下。Let's Encrypt 提供免费、自动化、可信的 SSL 证书。安装 Certbot： sudo yum install -y certbot python2-certbot-apache 。然后一键获取并配置证书： sudo certbot --apache -d your-domain.com -d www.your-domain.com 。Certbot 会自动修改 Apache 配置，添加重定向规则（HTTP → HTTPS），并设置自动续期任务（ sudo crontab -e 中已添加）。热词中“wordpress手机端跳转到国外网站”的案例，往往源于 HTTP 站点被 ISP 劫持注入广告，HTTPS 是最基础的防御。

第二，建立定期备份策略 。WordPress 的核心是数据库（ wordpress_db ）和文件（ /var/www/html ）。我使用 mysqldump 和 tar 编写了一个简单的每日备份脚本，存放在 /root/backup.sh ：

#!/bin/bash
DATE=$(date +%Y%m%d)
mysqldump -u wp_user -p'WpU$erP@ss2024!' wordpress_db | gzip > /backup/db_backup_$DATE.sql.gz
tar -czf /backup/files_backup_$DATE.tar.gz -C /var/www html
find /backup -name "db_backup_*.sql.gz" -mtime +7 -delete
find /backup -name "files_backup_*.tar.gz" -mtime +7 -delete

配合 sudo crontab -e 添加 0 2 * * * /root/backup.sh ，每天凌晨 2 点自动执行，并保留最近 7 天的备份。备份是灾难恢复的唯一希望。

第三，考虑容器化演进 。热词中“php使用docker打包镜像”提示了一个现代化方向。虽然本项目是传统部署，但将 Apache、PHP、MariaDB 封装进 Docker Compose，能极大提升环境一致性、部署速度和资源隔离性。一个 docker-compose.yml 文件，就能在任何 Linux 服务器上一键拉起全套环境。这并非否定当前方案，而是为未来的技术演进埋下伏笔。

最后，我想分享一个个人体会：在 VMware Workstation Pro 中，用 CentOS 7 Minimal 从零部署 WordPress，看似是“复古”的操作，但它强迫你直面每一个技术决策的后果。当 firewall-cmd --reload 后网站突然无法访问，当 chmod 600 wp-config.php 后后台登录失败，当 setsebool 解决了那个困扰你半天的连接拒绝——这些时刻，你获得的不仅是解决问题的能力，更是对整个 Linux Web 生态的深刻理解。这种理解，是任何一键脚本都无法赋予的。它让你在面对“120万站点被黑”的新闻时，不再恐慌，而是能冷静地说：“我知道漏洞在哪里，也知道怎么堵住它。” 这，或许就是这份手记最想传递的价值。