1. 项目概述：在 CentOS 6 上部署 WordPress 的真实意义与现实约束

你搜到“如何在 CentOS 6 上安装 WordPress”，大概率不是为了写一篇怀旧技术考古报告，而是手头正有一台跑着 CentOS 6 的老服务器——可能是公司里那台三年没重启过、但业务系统还在跑的物理机，也可能是某次迁移遗留下来的虚拟机镜像，又或者是在做安全靶场复现时必须还原的历史环境。我试过三次：第一次是帮客户维护一套老旧的内部审批系统，Apache 2.2 + PHP 5.3 是硬性要求；第二次是在搭建 WordPress 漏洞靶场时，必须复现 CVE-2017-8295（WordPress 4.7.4 的密码重置绕过）所依赖的原始运行栈；第三次纯粹是测试兼容性边界——当所有新教程都在说“PHP 8.2+”“MySQL 8.0+”时，你得知道，把 WordPress 5.0 跑在 PHP 5.4 上到底会报什么错、哪里卡住、怎么绕过去。

CentOS 6 发布于 2011 年，EOL（生命周期终止）早在 2020 年底就已正式到来。这意味着官方不再提供任何安全更新、漏洞修复或软件包升级。你今天在它上面装 Apache、MySQL、PHP，用的全是最后冻结的版本快照：Apache 2.2.15、MySQL 5.1.73、PHP 5.3.3。这不是“过时”，而是“被时间封印”。所以这篇内容不教你“怎么装”，而是告诉你“为什么只能这么装”“装完之后哪些地方会悄悄出问题”“别人教程里没写的三处致命陷阱，你踩进去就会丢数据”。核心关键词 wordpress、centos、apache、mysql、php 不是标签，而是五道锁：每一道都卡在版本兼容性的咽喉上。适合谁？运维老手用来快速救火，安全研究员搭建可复现靶场，中小企业的 IT 兼职人员接手历史遗产，以及所有不想被“一键脚本”坑进坑里的真实使用者。它解决的不是“能不能装”的问题，而是“装完能不能活过三天”的问题。

2. 整体设计思路：为什么必须放弃“最新版”幻想，回归最小可行栈

2.1 版本锁定逻辑：不是选择，而是服从

很多人看到“CentOS 6”第一反应是“升级系统”，但现实往往不允许。我接手过一个案例：客户生产环境跑着定制化 Oracle 11g RAC，内核模块强依赖 CentOS 6.5 的特定 patch level，升级意味着整套数据库集群停机验证，成本远超维持现状。这种情况下，“安装 WordPress”不是功能需求，而是合规需求——审计要求所有对外服务必须有独立 Web 层，而他们只肯批一台 CentOS 6 虚拟机。所以我们的设计起点不是“用最新技术”，而是“用最稳的冻结组合”。

我们最终锁定的栈是：

• Web 服务器 ：Apache 2.2.15（系统默认源自带，不升级）
• 数据库 ：MySQL 5.1.73（系统默认源自带，不升级）
• 语言环境 ：PHP 5.3.3（系统默认源自带，不升级）
• WordPress 版本 ： 5.0.17 （最后一个明确支持 PHP 5.3 的官方发布版）

这个组合不是拍脑袋定的。我做了三轮验证：第一轮查 WordPress 官方文档的 PHP 兼容性矩阵，确认 5.0.x 是最后支持 PHP 5.3 的大版本；第二轮翻 GitHub 上 wordpress-develop 仓库的 wp-includes/compat.php 文件，发现 PHP 5.4+ 的 json_last_error_msg() 等函数调用在 5.0.17 中尚未引入；第三轮实测——把 WordPress 5.1 压缩包解压到环境里，访问首页直接报 Fatal error: Call to undefined function json_last_error_msg() 。这说明，版本锁定不是保守，而是数学意义上的必要条件。

提示：网上大量教程推荐“用 IUS 或 Remi 源装 PHP 5.4/5.5”，这是危险操作。IUS 的 PHP 5.4 包依赖 libzip.so.2 ，而 CentOS 6 默认只有 libzip.so.1 ，强行安装会破坏 yum 工具链，导致后续无法更新任何系统包。我曾因此让一台服务器的 rpm 命令彻底失效，重装了整个系统。

2.2 架构取舍：拒绝 Nginx，坚持 Apache 的底层原因

你可能疑惑：为什么不用更轻量的 Nginx？答案藏在 WordPress 的 .htaccess 伪静态规则里。CentOS 6 时代的 WordPress 部署，90% 以上依赖 Apache 的 mod_rewrite 模块实现 SEO 友好的 URL（如 /about/ 而非 /index.php?p=123 ）。Nginx 虽然也能做 rewrite，但规则语法完全不同，且 WordPress 后台的“固定链接”设置页面，生成的是 Apache 专用的 .htaccess 内容。如果你硬上 Nginx，每次在后台点一下“保存更改”，WordPress 就会尝试往根目录写一个它自己都读不懂的 .htaccess 文件，然后报错。这不是配置问题，是生态断层。

更关键的是权限模型。Apache 在 CentOS 6 上以 apache 用户身份运行，其 httpd.conf 中的 User apache 和 Group apache 设置，与系统默认的文件属主模型天然契合。而 Nginx 默认用 nginx 用户，你需要手动修改 /etc/nginx/nginx.conf ，再调整所有 WordPress 目录的 chown -R nginx:nginx ，稍有不慎， wp-content 下的插件上传、主题编辑功能就会因权限拒绝而失效。我实测过，在同一台机器上并行部署 Apache 和 Nginx，用 Apache 托管 WordPress，用 Nginx 反向代理静态资源，性能提升微乎其微（<3%），但运维复杂度翻倍。所以，坚持 Apache 不是守旧，而是用最短路径解决最痛问题。

2.3 安全妥协的底线：不装 EPEL，不启 SELinux，但必须做三件事

CentOS 6 默认的 base 源软件包极其精简。很多教程会建议你先 yum install epel-release ，然后从 EPEL 源装 php-mysql 、 php-gd 等扩展。但 EPEL 的 PHP 扩展包，编译时链接的是 EPEL 自带的 PHP 运行时，而系统默认的 php 命令来自 base 源，两者 ABI（应用二进制接口）不兼容，会导致 php -m | grep mysql 显示模块已加载，但 WordPress 连接 MySQL 时仍报 Call to undefined function mysql_connect() 。这是典型的“看起来装上了，其实没生效”。

SELinux 更是隐形杀手。CentOS 6 默认启用 enforcing 模式，而 Apache 访问 /var/www/html/wordpress/wp-config.php 这类敏感配置文件时，SELinux 策略会拦截，报 Permission denied ，但错误日志里只显示 AH00027: No protocol handler was valid for the URL / 这种误导性信息。我花了一下午才定位到是 httpd_can_network_connect_db 布尔值未开启。

所以我们的安全妥协底线是：

1. 不启用 EPEL 源 ，所有 PHP 扩展用 yum --enablerepo=base install php-mysql php-gd php-xml php-mbstring 从 base 源安装；
2. 临时禁用 SELinux ： setenforce 0 ，并在 /etc/selinux/config 中设为 SELINUX=disabled ，重启生效（生产环境如需开启，必须额外配置 semanage fcontext 规则）；
3. 必须做三件事 ：给 wp-config.php 设 600 权限、禁用 allow_url_fopen 、关闭 register_globals （虽 PHP 5.3 已默认关闭，但需双重确认）。

这三件事不是锦上添花，而是防止 WordPress 被批量挂马的基础防线。2017 年那波 120 万站点后门事件，主因就是大量站点 wp-config.php 权限为 644 ，且 allow_url_fopen 开启，攻击者通过注入恶意代码，用 file_get_contents() 直接读取配置文件内容。

3. 核心细节解析：从系统初始化到 WordPress 可用的七步实操要点

3.1 系统初始化：清理残留、校验源、关闭无用服务

很多故障源于“以为干净，其实混乱”。我见过最离谱的情况：一台标称“全新安装 CentOS 6.5”的服务器， /etc/yum.repos.d/ 下竟有 7 个自定义 repo 文件，其中 3 个指向已下线的镜像站， yum update 直接卡死。所以第一步永远是“归零”。

# 1. 清理所有非官方 repo（保留 CentOS-Base.repo 和 CentOS-Media.repo）
ls /etc/yum.repos.d/ | grep -v "CentOS-Base\|CentOS-Media" | xargs -I {} rm -f /etc/yum.repos.d/{}

# 2. 强制刷新 yum 缓存，校验 base 源可用性
yum clean all
yum makecache

# 3. 检查当前 kernel 和系统版本，确认无降级风险
uname -r
cat /etc/redhat-release

# 4. 关闭无关服务，释放端口和内存
service iptables stop
chkconfig iptables off
service ip6tables stop
chkconfig ip6tables off
service postfix stop
chkconfig postfix off

注意： iptables 关闭不是放弃防火墙，而是避免它干扰安装过程中的端口连通性测试。安装完成后，我们会用 iptables -A INPUT -p tcp --dport 80 -j ACCEPT 单独放行 HTTP 端口，再 service iptables start 。 postfix 关闭是因为它默认监听 25 端口，而某些 WordPress 插件（如 WP Mail SMTP）在调试邮件发送时，会误判本地 SMTP 服务异常，导致后台报错。

3.2 Apache 部署：从默认配置到 WordPress 友好型改造

CentOS 6 的 Apache 默认配置 ( /etc/httpd/conf/httpd.conf ) 对 WordPress 极不友好。它默认禁止 .htaccess 文件覆盖，且 DocumentRoot 指向 /var/www/html ，而 WordPress 需要该目录具备 .htaccess 解析能力。

# 1. 安装 Apache 及基础模块
yum install httpd -y

# 2. 修改主配置，允许 .htaccess 覆盖
sed -i '/<Directory "\/var\/www\/html">/,/<\/Directory>/s/AllowOverride None/AllowOverride All/' /etc/httpd/conf/httpd.conf

# 3. 确保 mod_rewrite 模块已加载（CentOS 6 默认已加载，但需确认）
grep "LoadModule rewrite_module" /etc/httpd/conf/httpd.conf
# 若无输出，则手动添加：LoadModule rewrite_module modules/mod_rewrite.so

# 4. 启动并设开机自启
service httpd start
chkconfig httpd on

关键细节在于 AllowOverride All 的位置。它必须写在 <Directory "/var/www/html"> 这个区块内，而不是全局配置。因为 Apache 的配置是继承式覆盖，如果只在全局加 AllowOverride All ，子目录的 Deny from all 规则仍会生效。我曾因此调试了两小时，最后发现是区块嵌套层级错了。

3.3 MySQL 配置：初始化、加固、创建专用数据库

CentOS 6 的 MySQL 5.1.73 安装后， root 密码为空，且默认允许 root@localhost 无密码登录。这是最大安全隐患。

# 1. 安装 MySQL 服务端
yum install mysql-server -y

# 2. 启动 MySQL 并设开机自启
service mysqld start
chkconfig mysqld on

# 3. 运行安全初始化脚本（关键！）
/usr/bin/mysql_secure_installation
# 按提示：设置 root 密码（必选）、删除匿名用户（Y）、禁止 root 远程登录（Y）、删除 test 数据库（Y）、重载权限表（Y）

# 4. 登录 MySQL，创建 WordPress 专用数据库和用户
mysql -u root -p
> CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
> CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'StrongPass123!';
> GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
> FLUSH PRIVILEGES;
> EXIT;

实操心得： mysql_secure_installation 脚本必须运行。它不只是改密码，更重要的是执行 DELETE FROM mysql.user WHERE User=''; 删除匿名用户，以及 DROP DATABASE test; 清除测试库。这两步能堵住 80% 的弱口令爆破入口。另外， GRANT 语句中必须指定 'wpuser'@'localhost' ，不能写 'wpuser'@'%' ，否则会允许任意 IP 连接，违背最小权限原则。

3.4 PHP 环境构建：扩展安装、配置调优、致命参数修正

CentOS 6 的 PHP 5.3.3 默认不包含 MySQL 扩展，必须手动安装。同时，WordPress 对 memory_limit 、 upload_max_filesize 等参数有硬性要求。

# 1. 安装 PHP 及必需扩展（全部从 base 源）
yum install php php-mysql php-gd php-xml php-mbstring -y

# 2. 修改 php.ini（路径：/etc/php.ini）
sed -i 's/memory_limit = 128M/memory_limit = 256M/' /etc/php.ini
sed -i 's/upload_max_filesize = 2M/upload_max_filesize = 64M/' /etc/php.ini
sed -i 's/post_max_size = 8M/post_max_size = 128M/' /etc/php.ini
sed -i 's/;date.timezone =/date.timezone = Asia\/Shanghai/' /etc/php.ini
sed -i 's/allow_url_fopen = On/allow_url_fopen = Off/' /etc/php.ini
sed -i 's/;cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/' /etc/php.ini

# 3. 重启 Apache 生效
service httpd restart

这里 cgi.fix_pathinfo=0 是关键。PHP 5.3 默认为 1 ，这会导致一个严重安全漏洞：当请求 /wp-content/uploads/image.jpg/xxx.php 时，PHP 会尝试将 image.jpg 当作 PHP 脚本执行（因为 xxx.php 在路径中），攻击者可上传图片马并绕过文件类型检查。设为 0 后，PHP 只认文件后缀，彻底杜绝此路。这个参数在绝大多数 WordPress 安全指南里被忽略，但它在 CentOS 6 + PHP 5.3 组合下是必改项。

3.5 WordPress 核心部署：下载、解压、权限设置、配置生成

WordPress 官方已停止提供 5.0.x 的直接下载链接，需从官方 SVN 或存档站获取。我们采用最稳妥的 wget 方式。

# 1. 进入 Web 根目录
cd /var/www/html

# 2. 下载 WordPress 5.0.17（SHA256 校验值：e3a7c5b...，确保完整性）
wget https://wordpress.org/wordpress-5.0.17.zip
unzip wordpress-5.0.17.zip
mv wordpress/* ./
rmdir wordpress
rm wordpress-5.0.17.zip

# 3. 设置所有权和权限（核心！）
chown -R apache:apache /var/www/html/
find /var/www/html/ -type d -exec chmod 755 {} \;
find /var/www/html/ -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

# 4. 生成 wp-config.php（用命令行方式，避免 Web 安装向导的权限陷阱）
cp wp-config-sample.php wp-config.php
sed -i "s/database_name_here/wordpress/" wp-config.php
sed -i "s/username_here/wpuser/" wp-config.php
sed -i "s/password_here/StrongPass123!/" wp-config.php
sed -i "s/localhost/localhost/" wp-config.php

注意： chmod 600 wp-config.php 必须在 chown apache:apache 之后执行。因为 chown 会重置文件权限，如果先设 600 再 chown ， wp-config.php 的属主会变成 apache ，而 apache 用户无法写入自身文件（WordPress 后台的“更新配置”功能会失效）。正确顺序是： chown → chmod 644 全局 → chmod 600 单独设配置文件。

3.6 伪静态与固定链接： .htaccess 的手工编写与 Apache 重载

CentOS 6 的 Apache 默认不启用 mod_rewrite 的日志功能，调试 .htaccess 规则极其困难。我们必须先开启重写日志，再写规则。

# 1. 在 /etc/httpd/conf/httpd.conf 中，取消以下两行注释
# LoadModule rewrite_module modules/mod_rewrite.so
# <IfModule mod_rewrite.c>
#     RewriteLog "/var/log/httpd/rewrite_log"
#     RewriteLogLevel 3
# </IfModule>

# 2. 重启 Apache
service httpd restart

# 3. 创建并写入 .htaccess（WordPress 后台生成的规则在 CentOS 6 下需微调）
cat > /var/www/html/.htaccess << 'EOF'
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
EOF

# 4. 设置 .htaccess 权限
chmod 644 /var/www/html/.htaccess

关键点在于 RewriteBase / 。很多教程漏掉这一行，导致 WordPress 安装在子目录（如 /blog/ ）时，固定链接失效。即使你装在根目录，加上它也是最佳实践，避免未来迁移时重写规则。

3.7 最终验证：从命令行到浏览器的四层连通性测试

不要急着打开浏览器。我养成的习惯是：用四条命令，逐层验证，比盲目刷网页高效十倍。

# 第一层：Apache 是否监听 80 端口？
netstat -tuln | grep :80
# 应输出：tcp 0 0 :::80 :::* LISTEN

# 第二层：PHP 是否能解析？
echo "<?php echo 'PHP OK'; ?>" > /var/www/html/test.php
curl http://localhost/test.php
# 应输出：PHP OK

# 第三层：PHP 是否能连 MySQL？
echo "<?php \$link = mysql_connect('localhost', 'wpuser', 'StrongPass123!'); echo \$link ? 'MySQL OK' : 'MySQL FAIL'; ?>" > /var/www/html/dbtest.php
curl http://localhost/dbtest.php
# 应输出：MySQL OK（注意：这里用的是 mysql_* 函数，PHP 5.3 原生支持）

# 第四层：WordPress 基础文件是否可读？
curl -I http://localhost/wp-load.php
# 应返回 HTTP/1.1 200 OK，而非 403 或 500

这四步做完，浏览器打开 http://your-server-ip ，就能看到熟悉的 WordPress 安装向导页面。此时，你已经完成了 95% 的工作，剩下的只是填表。

4. 实操过程详解：从零开始的完整终端记录与参数决策依据

4.1 环境准备阶段：时间戳、IP 地址、初始状态快照

所有实操必须可追溯。我在一台纯净的 CentOS 6.10 虚拟机上进行，以下是初始状态记录：

# 时间戳（重要！用于回溯）
date "+%Y-%m-%d %H:%M:%S"
# 输出：2024-03-15 14:22:33

# 获取本机 IP（用于后续访问）
ifconfig eth0 | grep "inet addr" | awk '{print $2}' | cut -d: -f2
# 输出：192.168.56.101

# 查看当前 yum 源状态
yum repolist enabled | head -5
# 输出：
# Loaded plugins: fastestmirror, security
# Loading mirror speeds from cached hostfile
# repo id              repo name                                    status
# base                 CentOS-6 - Base                              6,706
# updates              CentOS-6 - Updates                           1,342

# 查看已安装的 httpd、mysql、php 版本（确认为默认源版本）
rpm -qa | grep -E "httpd|mysql|php" | sort
# 输出：
# httpd-2.2.15-69.el6.centos.1
# mysql-5.1.73-8.el6_8
# mysql-server-5.1.73-8.el6_8
# php-5.3.3-49.el6
# php-cli-5.3.3-49.el6
# php-common-5.3.3-49.el6
# php-gd-5.3.3-49.el6
# php-mbstring-5.3.3-49.el6
# php-mysql-5.3.3-49.el6
# php-xml-5.3.3-49.el6

这个快照证明：我们操作的是一台标准 CentOS 6.10，所有软件包均来自 base 和 updates 源，版本完全符合预期。没有第三方 repo，没有手动编译痕迹，这是后续所有步骤可复现的基础。

4.2 Apache 配置修改： AllowOverride 的精确作用域与测试

修改 httpd.conf 后，必须验证 AllowOverride 是否真正生效。我用一个简单的 .htaccess 测试：

# 创建测试文件
echo "Options +Indexes" > /var/www/html/.htaccess
echo "<h1>Test Directory Listing</h1>" > /var/www/html/index.html

# 重启 Apache
service httpd restart

# 用 curl 测试目录列表是否开启（应返回 200 并含文件列表）
curl -I http://localhost/
# 如果返回 403 Forbidden，说明 AllowOverride 未生效

如果失败，检查 httpd.conf 中 <Directory "/var/www/html"> 区块是否被其他配置覆盖。CentOS 6 的 /etc/httpd/conf.d/ 下可能有 welcome.conf ，它会定义另一个 <Directory> ，优先级更高。解决方案是： mv /etc/httpd/conf.d/welcome.conf /etc/httpd/conf.d/welcome.conf.bak ，再重启。

4.3 MySQL 用户权限的深度验证： SHOW GRANTS 与连接测试

创建 wpuser 后，不能只信 GRANT 语句。必须用 SHOW GRANTS 确认权限已写入：

mysql -u root -p -e "SHOW GRANTS FOR 'wpuser'@'localhost';"
# 输出应为：
# +--------------------------------------------------------------------+
# | Grants for wpuser@localhost                                        |
# +--------------------------------------------------------------------+
# | GRANT USAGE ON *.* TO 'wpuser'@'localhost' IDENTIFIED BY PASSWORD |
# | GRANT ALL PRIVILEGES ON `wordpress`.* TO 'wpuser'@'localhost'     |
# +--------------------------------------------------------------------+

然后，用 wpuser 身份连接，测试实际权限：

mysql -u wpuser -p -e "USE wordpress; SHOW TABLES;" wordpress
# 应返回空结果（因为数据库刚创建，无表），而非权限错误

这一步能提前发现 FLUSH PRIVILEGES; 是否遗漏，或 GRANT 语句语法是否有空格等隐藏错误。

4.4 PHP 配置参数的量化依据： memory_limit 为何设为 256M？

WordPress 5.0.17 的内存消耗有明确基准。我用 wp-debug 插件实测：

• 后台仪表盘：约 45MB
• 文章编辑页（含 10 个插件）：约 82MB
• 主题自定义器：约 110MB

而 PHP 默认 memory_limit = 128M ，在启用 WP Super Cache 等缓存插件时，极易触发 Allowed memory size exhausted 错误。256M 是经过压力测试的临界值：用 ab -n 1000 -c 50 http://localhost/ （Apache Bench）并发 50 请求首页，256M 下无内存溢出，128M 下约 15% 请求失败。这不是拍脑袋，而是用 phpinfo() 和 memory_get_peak_usage() 日志反复验证的结果。

4.5 WordPress 安装向导的避坑： wp-config.php 的手工生成全流程

WordPress 安装向导（ /wp-admin/install.php ）在 CentOS 6 下有个致命缺陷：它会尝试用 fopen() 创建 wp-config.php ，但前提是 Web 服务器用户（ apache ）对 /var/www/html/ 有写权限。而我们之前已执行 chown apache:apache ，看似满足，实则不然—— apache 用户无法在自己的目录下创建同名文件（ wp-config.php 已存在，由 cp 命令生成），向导会报错 Could not create config file. 。

解决方案是： 跳过 Web 向导，全程命令行操作 。

# 1. 备份原始 sample 文件
cp wp-config-sample.php wp-config-sample.php.bak

# 2. 用 sed 替换所有占位符（注意：密码中若有 / 或 & 符号，需转义）
sed -i "s/database_name_here/wordpress/" wp-config-sample.php
sed -i "s/username_here/wpuser/" wp-config-sample.php
sed -i "s/password_here/StrongPass123\!/" wp-config-sample.php
sed -i "s/localhost/localhost/" wp-config-sample.php

# 3. 重命名
mv wp-config-sample.php wp-config.php

# 4. 生成唯一密钥（从官方 API 获取，避免用默认的）
curl -s https://api.wordpress.org/secret-key/1.1/salt/ > /tmp/keys
sed -i '/AUTH_KEY/,/NONCE_SALT/{/define(/d;}' wp-config.php
sed -i '/\/\* That\'s all, stop editing!/i\' "$(cat /tmp/keys)" wp-config.php
rm /tmp/keys

这段脚本的核心是 sed 的多行删除与插入。它精准定位 wp-config.php 中 define('AUTH_KEY', ...) 到 define('NONCE_SALT', ...) 的 8 行，并用官方 API 返回的新密钥替换。这比手动复制粘贴快，且杜绝了密钥重复的风险。

4.6 固定链接生效的终极验证： curl -v 抓包分析

设置好 .htaccess 后，访问 /about/ 页面，必须用 curl -v 查看真实 HTTP 流程：

curl -v http://192.168.56.101/about/
# 关键输出：
# > GET /about/ HTTP/1.1
# < HTTP/1.1 200 OK
# < Server: Apache/2.2.15 (CentOS)
# < Content-Type: text/html; charset=UTF-8
# ...
# * Connection #0 to host 192.168.56.101 left intact

如果返回 301 Moved Permanently 或 404 Not Found ，说明 .htaccess 规则未被 Apache 加载。此时检查 error_log ：

tail -f /var/log/httpd/error_log
# 若出现：[alert] [pid 1234] /var/www/html/.htaccess: Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration
# 则证明 mod_rewrite 未加载，需检查 httpd.conf 中 LoadModule 行。

4.7 完整安装完成后的状态确认清单

安装结束，不是终点，而是运维的起点。我用一张表格固化最终状态：

检查项	命令	期望输出	说明
Apache 运行状态	service httpd status	httpd (pid 1234) is running...	PID 应为数字，非 dead
MySQL 运行状态	service mysqld status	mysqld (pid 5678) is running...	确认数据库服务存活
PHP 版本	php -v	PHP 5.3.3 (cli) ...	CLI 版本必须与 Web 版本一致
WordPress 版本	grep "wp_version =" /var/www/html/wp-includes/version.php	wp_version = '5.0.17';	确认未被意外升级
wp-config.php 权限	ls -l /var/www/html/wp-config.php	-rw-------. 1 apache apache ...	权限必须为 600
.htaccess 权限	ls -l /var/www/html/.htaccess	-rw-r--r--. 1 apache apache ...	权限必须为 644
数据库连接	mysql -u wpuser -p -e "SELECT VERSION();"	5.1.73	用 WordPress 用户连接，验证权限

这张表是我交付给客户的最终验收单。它不依赖主观判断，每一项都是可量化的命令行输出，确保“安装完成”不是一句空话。

5. 常见问题与排查技巧实录：那些教程绝不会告诉你的 7 个真实故障

5.1 故障一：“Error establishing a database connection” —— 90% 的原因不是密码错

这个错误是 WordPress 新手的第一道坎。但在我处理的 127 个案例中，只有 3 个是密码输错，其余全是以下三个原因：

1. MySQL 服务未启动 ： service mysqld status 显示 dead 。CentOS 6 的 mysqld 服务名是 mysqld ，不是 mysql ，敲错就查不到。
2. wp-config.php 中的 DB_HOST 写成 127.0.0.1 ：PHP 5.3 的 mysql_connect() 函数，当 DB_HOST 为 127.0.0.1 时，强制走 TCP 连接；而 MySQL 5.1 默认只监听 localhost （Unix socket）。解决方案： DB_HOST 必须写 localhost ，不能写 127.0.0.1 。
3. SELinux 阻断 ：即使 setenforce 0 临时关闭， /var/log/audit/audit.log 中仍有 avc: denied { name_connect } 记录。永久解决： setsebool -P httpd_can_network_connect_db 1 。

排查技巧：用 mysql -u wpuser -p -h localhost wordpress 命令行直连。如果成功，说明配置文件没问题；如果失败，再看错误提示，精准定位。

5.2 故障二：后台上传图片失败，报“HTTP 错误” —— post_max_size 的连锁反应

WordPress 后台上传图片，前端报“HTTP 错误”，后端 error_log 无记录。这是典型的 post_max_size 和 upload_max_filesize 不匹配。

• upload_max_filesize = 64M ：限制单个文件大小
• post_max_size = 128M ：限制整个 POST 请求体大小（含文件、表单字段等）

如果 post_max_size 小于 upload_max_filesize ，PHP 会静默截断请求，WordPress 收不到完整数据，就报“HTTP 错误”。解决方案： post_max_size 必须 ≥ upload_max_filesize ，且建议留 20% 余量。我设 128M ，就是为应对多图上传场景。

5.3 故障三：固定链接 404， .htaccess 写入失败 —— mod_rewrite 的加载时机

WordPress 后台点击“保存更改”时，报“请将以下规则写入您的 .htaccess 文件”，但文件内容为空。这是因为 mod_rewrite 模块在 Apache 启动时未加载。

检查 /etc/httpd/conf/httpd.conf ，找到 LoadModule rewrite_module modules/mod_rewrite.so 这一行。CentOS 6 默认是注释掉的（前面有 # ）。取消注释后，必须 service httpd restart ，不能 reload ，因为 restart 会重新加载所有模块， reload 只重读配置文件。

5.4 故障四：中文文章乱码，数据库显示问号 —— 字符集未透传

文章标题和内容显示为 ???? ，但数据库 SHOW CREATE TABLE wp_posts 显示 DEFAULT CHARSET=utf8 。问题出在连接层。

在 wp-config.php 中，必须添加：