Ubuntu 18.04 手动部署 LAMP+WordPress 全流程详解

1. 项目概述：为什么在 Ubuntu 18.04 上手动搭建 LAMP + WordPress 仍是硬核建站的必修课

“Comment installer WordPress avec LAMP sur Ubuntu 18.04”——这句法语标题直译过来就是“如何在 Ubuntu 18.04 上安装 WordPress（使用 LAMP 环境）”。它看似是一条陈旧的技术指令，毕竟 Ubuntu 18.04 已于 2023 年 4 月结束标准支持，官方安全更新也早已终止。但恰恰是这个“过时”的组合，至今仍被大量中小型企业、独立开发者、渗透测试教学团队和 WordPress 安全研究者反复部署。原因很实在：LAMP（Linux + Apache + MySQL + PHP）不是抽象概念，而是一套可触摸、可调试、可审计、可复现的完整技术栈；Ubuntu 18.04 则是那个承上启下的稳定锚点——它既兼容 PHP 7.2–7.4 的主流 WordPress 版本（5.0–5.8），又未引入 systemd-resolved 等新机制带来的 DNS 解析干扰，更关键的是，它的软件源结构清晰、包依赖关系透明，对新手理解“服务如何真正启动、配置如何真正生效、权限如何真正约束”具有不可替代的教学价值。

我带过十几期 Web 运维实训班，每次开课第一周，我都坚持让学员亲手敲完这整套命令，而不是用一键脚本或 Docker Compose。为什么？因为当你执行sudo systemctl start apache2后去/var/log/apache2/error.log里看到AH00558: apache2: Could not reliably determine the server's fully qualified domain name这行警告时，你才真正开始思考“域名解析”与“虚拟主机配置”的边界；当你把wp-config.php的数据库密码写错，浏览器只显示“Error establishing a database connection”，而你必须回到终端用mysql -u root -p手动验证 MySQL 是否监听、用户权限是否正确、socket 路径是否匹配时，你才真正建立起“应用层错误”与“基础设施层状态”的映射能力。这不是怀旧，而是基建思维的肌肉记忆训练。尤其在当前 WordPress 面临大规模后门植入（如你提到的“120万站点被植入”事件）背景下，一个能从 Apache 模块加载顺序、PHPopen_basedir限制、MySQL 用户最小权限原则逐层加固的运维者，远比只会点鼠标开通宝塔面板的人更能守住业务底线。本文不讲“最快安装”，只讲“最透安装”——每一个命令背后是什么、每一步失败意味着什么、每一处配置为什么这样写，全部摊开给你看。

2. 整体设计思路与方案选型逻辑：为什么是 LAMP，而不是 LNMP 或容器化？

2.1 LAMP 栈的不可替代性：不是历史包袱，而是工程确定性

很多人一看到“Ubuntu 18.04 + LAMP”，下意识觉得“太老了，该换 Nginx 了”。但真实生产环境里，LAMP 的生命力恰恰来自它的“笨重感”。Apache 的.htaccess文件支持、.htpasswd认证、mod_rewrite规则的直观语法、以及VirtualHost配置中对DocumentRoot和Directory的显式隔离，构成了 WordPress 生态最原生的运行土壤。WordPress 官方推荐的伪静态规则（即你热词里提到的“wordpress伪静态规则”）默认就是 Apache 的RewriteRule语法：

RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]

这段代码如果硬塞进 Nginx 的location ~ \.php$块里，不仅需要额外转换为try_files逻辑，还极易因fastcgi_split_path_info配置失误导致 PHP 文件被直接下载——这是我在客户现场处理过的最高频故障之一。而 Apache 下，你只需把这段粘贴进站点配置文件，a2enmod rewrite启用模块，systemctl reload apache2，立刻生效。这种“所见即所得”的调试体验，对排查“wordpress产品-排序-按类别过滤不显示”这类前端 JS 报错掩盖的真实后端路由问题，效率高出一倍不止。

再看 MySQL。你热词里反复出现“mysql安装配置教程”“mysql设置唯一已经有重复数据库”，这恰恰暴露了一个事实：WordPress 的数据模型极度依赖 MySQL 的事务一致性与外键约束（尽管 WP 核心很少显式建外键，但插件如 WooCommerce 大量使用）。Ubuntu 18.04 自带的 MySQL 5.7.33 是最后一个默认启用STRICT_TRANS_TABLES模式的版本，它会强制拒绝INSERT INTO wp_posts (post_status) VALUES ('')这类空字符串插入——而很多粗制滥造的主题或插件正是靠这种“宽松模式”苟活。当你在 18.04 上部署时，这些隐患会第一时间暴露在mysql_error()日志里，逼你去修复代码，而不是等上线后突然发现订单表数据错乱。这就是 LAMP 的“确定性红利”：它不隐藏错误，只放大问题。

2.2 为什么坚持 Ubuntu 18.04？三个硬核理由

第一，PHP 版本兼容性黄金窗口。WordPress 5.6（2020年12月发布）是最后一个官方声明支持 PHP 7.2 的大版本，而 Ubuntu 18.04 的php7.2包是经过 Canonical 严格 QA 的稳定二进制。我实测过：在 20.04 上装 PHP 7.4 运行同一套 WP 插件，mbstring扩展的mb_detect_encoding()函数在处理 GBK 编码的旧主题时，会因 ICU 库版本升级导致字符检测失败，引发整个后台白屏；而在 18.04 的 PHP 7.2 环境下，同样的代码稳如磐石。这不是版本越新越好，而是“匹配度”决定稳定性。

第二，Apache 配置路径的绝对一致性。Ubuntu 18.04 的 Apache 配置树是教科书级的清晰：

• 主配置：/etc/apache2/apache2.conf
• 站点配置：/etc/apache2/sites-available/000-default.conf（启用后软链到sites-enabled）
• 模块配置：/etc/apache2/mods-available/rewrite.load
• 日志路径：/var/log/apache2/下固定access.log和error.log

对比 22.04 的apache2包，它默认启用了mpm_event模块并强制要求libapache2-mod-php与php-fpm协同，配置分散在/etc/apache2/mods-enabled/php8.1.conf和/etc/php/8.1/apache2/php.ini两处，新手极易漏改其中一处导致 PHP 不解析。18.04 的“单一入口”设计，让你一眼就能定位到LoadModule php7_module /usr/lib/apache2/modules/libphp7.2.so这行核心加载指令。

第三，安全加固的实操教学价值。你热词里提到的“wordpress靶场”“apache shiro框架漏洞靶场”，其底层原理都基于对服务配置的深度操控。比如要模拟“wordpress手机端跳转到国外网站”这类劫持攻击，你必须精准修改 Apache 的RedirectMatch规则或利用.htaccess的RewriteCond %{HTTP_USER_AGENT} "Android|iPhone"实现 UA 分流；而要防御“120万站点被植入后门”，你必须在 Apache 配置中加入：

<Directory "/var/www/html/wp-content"> php_flag engine off <Files "*.php"> Require all denied </Files> </Directory>

这种基于目录粒度的 PHP 执行禁用，在 18.04 的 Apache 2.4.29 环境下，Require all denied语法稳定可靠；而在新版 Apache 中，若未正确设置AllowOverride None，.htaccess可能被忽略，导致防护失效。所以，18.04 不是终点，而是理解 Web 服务安全边界的起点。

2.3 明确排除的方案及原因：为什么不用一键脚本、Docker 或宝塔？

• 一键脚本（如某些 GitHub 上的lamp-install.sh）：我试过 7 个主流脚本，6 个在apt update阶段因网络超时失败，剩下 1 个成功安装后，mysql_secure_installation步骤被静默跳过，root 密码仍是空——这意味着你的 WordPress 数据库裸奔在公网。脚本省掉的是键盘敲击，换来的是对系统状态的完全失察。

• Docker（docker-compose.yml部署 LAMP）：它确实快，但当你遇到“wordpress统计代码”埋点不触发时，你得先docker exec -it wordpress bash进容器，再查 Apache 日志，再确认卷挂载路径是否把/var/www/html映射对了，再检查宿主机防火墙是否放行了容器端口……一层层穿透下来，调试时间比原生部署多三倍。Docker 适合交付，不适合学习。

• 宝塔面板：它的图形界面确实友好，但所有操作最终都转化为后台 Shell 命令。而宝塔的“智能优化”功能会自动修改php.ini的memory_limit=512M，却忘了 WordPress 在处理高清图片上传时，upload_max_filesize和post_max_size必须同步调高，否则你永远卡在“媒体库上传失败”。这种“自动化黑箱”，恰恰剥夺了你建立参数关联思维的机会。

所以，本文的方案选择逻辑非常朴素：用最原始的手动方式，暴露最多的技术细节，换取最扎实的理解深度。接下来的所有步骤，你都能在终端里实时看到命令返回值、日志滚动、进程变化——这才是工程师该有的工作台。

3. 核心细节解析与实操要点：从系统初始化到服务校验的 12 个关键动作

3.1 系统初始化：别跳过这 3 个基础但致命的步骤

在敲任何apt install之前，请务必完成以下三步。它们耗时不到 2 分钟，但能避免 80% 的后续故障。

第一步：更新系统并设置时区
Ubuntu 18.04 默认时区是Etc/UTC，而 WordPress 的wp_options表中timezone_string字段（如Asia/Shanghai）必须与系统时区一致，否则文章发布时间、计划任务（wp-cron）全部错乱。执行：

sudo apt update && sudo apt upgrade -y sudo timedatectl set-timezone Asia/Shanghai # 验证：timedatectl status | grep "Time zone"

提示：timedatectl是 systemd 时代管理时区的唯一权威命令。不要用ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime这种老方法，它在 18.04 上会导致systemd-timesyncd服务冲突。

第二步：创建专用部署用户并赋予 sudo 权限
绝对禁止用root用户直接操作。创建webadmin用户：

sudo adduser webadmin sudo usermod -aG sudo webadmin # 切换用户并验证 su - webadmin sudo whoami # 应输出 root

注意：adduser命令会交互式要求输入密码和用户信息，全程回车即可跳过非必要字段。usermod -aG sudo中的-aG是关键——-a表示追加（append），-G指定用户组，漏掉-a会导致用户被踢出sudo组原有成员资格。

第三步：配置防火墙（UFW）开放必要端口
Ubuntu 18.04 默认禁用 UFW，但生产环境必须开启。只放行 HTTP（80）、HTTPS（443）和 SSH（22）：

sudo ufw enable sudo ufw allow OpenSSH sudo ufw allow 'Apache Full' # 这会同时开放 80 和 443 sudo ufw status verbose # 验证状态，应显示 Active 且规则列表正确

实操心得：ufw allow 'Apache Full'比ufw allow 80更安全，因为它会自动适配 Apache 配置中实际监听的端口（比如你改成了 8080，这条规则也会生效）。而硬编码端口号，一旦服务迁移就成安全隐患。

3.2 Apache 安装与核心配置：不只是a2enmod，更要懂模块加载顺序

Apache 的强大在于模块化，但模块加载顺序错了，整个服务就起不来。Ubuntu 18.04 的 Apache 2.4.29 默认启用mpm_prefork（多进程模型），这是 PHP 7.2 的最佳搭档。

安装与基础验证：

sudo apt install apache2 -y sudo systemctl start apache2 sudo systemctl enable apache2 curl -I http://localhost # 应返回 HTTP/1.1 200 OK

关键配置文件解读：

• /etc/apache2/apache2.conf：全局主配置，定义ServerRoot、Timeout、KeepAlive等核心参数。
• /etc/apache2/ports.conf：监听端口配置，默认Listen 80，若需 HTTPS，此处添加Listen 443。
• /etc/apache2/sites-available/000-default.conf：默认虚拟主机，DocumentRoot /var/www/html是 WordPress 的根目录。

必须启用的 3 个核心模块：

1. rewrite：支撑 WordPress 伪静态，a2enmod rewrite后，检查/etc/apache2/mods-enabled/rewrite.load是否存在符号链接。
2. headers：用于设置X-Frame-Options、X-Content-Type-Options等安全头，a2enmod headers。
3. ssl：即使暂不启用 HTTPS，也建议提前启用，避免后续配置 SSL 时模块缺失报错，a2enmod ssl。

提示：模块启用后，必须sudo systemctl reload apache2（而非 restart），因为 reload 会平滑重启子进程，不影响正在处理的请求。我曾在线上环境误用restart，导致 3 秒内 200+ 个并发请求丢失，教训深刻。

3.3 MySQL 安装与安全加固：从mysql_secure_installation到最小权限实践

Ubuntu 18.04 的mysql-server包安装的是 MySQL 5.7.33，其root用户默认使用auth_socket插件认证，这意味着你无法用密码登录mysql -u root -p，只能通过sudo mysql进入。这是安全设计，但对 WordPress 部署不友好，必须切换为密码认证。

安装与 root 密码重置：

sudo apt install mysql-server -y sudo mysql # 以 socket 方式进入

在 MySQL 提示符下执行：

-- 查看 root 用户认证方式 SELECT user,authentication_string,plugin,host FROM mysql.user WHERE user='root'; -- 将认证方式改为 mysql_native_password 并设置强密码（替换 'YourStrongPass123!'） ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YourStrongPass123!'; FLUSH PRIVILEGES; EXIT;

执行安全脚本：

sudo mysql_secure_installation # 依次回答：Y（切换密码验证策略）→ Y（设置 root 密码）→ Y（移除匿名用户）→ Y（禁止 root 远程登录）→ Y（移除 test 数据库）→ Y（重载权限表）

为 WordPress 创建专用数据库与用户（最小权限原则）：

sudo mysql -u root -p

-- 创建数据库（指定 UTF8MB4 字符集，兼容 emoji） CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建用户（仅允许本地连接，用户名密码自定义） CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'WpUserPass456!'; -- 授予数据库所有权限（注意：不是 GRANT ALL ON *.*） GRANT ALL ON wordpress.* TO 'wpuser'@'localhost'; -- 刷新权限 FLUSH PRIVILEGES; EXIT;

注意事项：GRANT ALL ON wordpress.*是精确授权，它只给wordpress数据库下所有表赋权，绝不能写成GRANT ALL ON *.*——后者等于把整个 MySQL 实例的 root 权限交出去。我见过太多被黑站点，根源就是安装时图省事用了通配符授权。

3.4 PHP 及扩展安装：为什么必须锁定 7.2，以及 5 个 WordPress 强依赖扩展

Ubuntu 18.04 默认仓库提供php7.2，但 WordPress 5.6+ 要求php-mysql、php-curl、php-gd、php-mbstring、php-xml、php-xmlrpc、php-soap、php-intl、php-zip等至少 9 个扩展。其中php-xmlrpc是 WordPress 自动更新和 Pingback 功能的基础，php-intl支撑多语言日期格式化，php-zip是主题/插件一键安装的必备。

安装命令：

sudo apt install php7.2 libapache2-mod-php7.2 php7.2-mysql php7.2-curl php7.2-gd php7.2-mbstring php7.2-xml php7.2-xmlrpc php7.2-soap php7.2-intl php7.2-zip -y

验证 PHP 解析：
在/var/www/html/下创建info.php：

echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/info.php

访问http://your-server-ip/info.php，页面应完整显示 PHP 7.2 信息，并在“Loaded Modules”中确认mysqli、curl、gd等扩展已启用。

实操心得：libapache2-mod-php7.2这个包名必须精确匹配。如果你误装libapache2-mod-php（无版本号），APT 会默认安装 PHP 7.3，导致php7.2-mysql与libapache2-mod-php版本冲突，Apache 启动失败。Ubuntu 的包管理器对版本号极其敏感，宁可多打几个字符，也不要依赖模糊匹配。

3.5 WordPress 核心文件部署：解压、权限、所有权的三重铁律

下载 WordPress 不是wget一下就完事。它的文件权限模型是安全基石。

下载与解压：

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

rsync -avP比cp -r更可靠：-a保留权限和符号链接，-v显示详细过程，-P显示进度条，避免大文件传输中断。

设置正确所有权与权限：

# 设置所有者为 www-data（Apache 运行用户），组为 webadmin（你的部署用户） sudo chown -R www-data:webadmin /var/www/html/ # 设置目录权限为 755（所有者读写执行，组和其他人读执行） sudo find /var/www/html/ -type d -exec chmod 755 {} \; # 设置文件权限为 644（所有者读写，组和其他人只读） sudo find /var/www/html/ -type f -exec chmod 644 {} \; # 特殊文件：wp-config.php 必须 600（仅所有者可读写），防止被 Web 访问读取 sudo chmod 600 /var/www/html/wp-config.php

关键原理：Apache 进程以www-data用户身份运行，它需要read+execute权限才能遍历目录、读取 PHP 文件；而你作为webadmin用户，需要read+write权限来编辑主题、上传插件。chown www-data:webadmin实现了“服务可读、人可写”的平衡。如果设成chown -R webadmin:www-data，Apache 会因无执行权限无法进入目录，报 403 Forbidden。

4. 实操过程与核心环节实现：从 wp-config.php 配置到 WordPress 安装向导的完整闭环

4.1 wp-config.php 的手动生成：超越向导的 7 个关键配置项

WordPress 安装向导（/wp-admin/install.php）虽方便，但它生成的wp-config.php是最简配置，缺乏安全加固和性能优化。我们必须手动编写。

第一步：复制模板并编辑

sudo cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php sudo nano /var/www/html/wp-config.php

第二步：填入数据库连接信息（第 19-24 行）：

// ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define('DB_NAME', 'wordpress'); /** MySQL database username */ define('DB_USER', 'wpuser'); /** MySQL database password */ define('DB_PASSWORD', 'WpUserPass456!'); /** MySQL hostname */ define('DB_HOST', 'localhost'); /** Database Charset to use in creating database tables. */ define('DB_CHARSET', 'utf8mb4'); /** The Database Collate type. Don't change this if in doubt. */ define('DB_COLLATE', '');

注意：DB_HOST写localhost而非127.0.0.1。前者走 Unix socket（更快更安全），后者走 TCP loopback，可能触发 MySQL 的skip-networking限制。

第三步：添加安全密钥（第 45-52 行）：
访问 https://api.wordpress.org/secret-key/1.1/salt/ ，复制生成的 8 组密钥，完整覆盖wp-config.php中// Change these to different unique phrases!下方的define()行。这些密钥用于加密 cookies 和 nonce，是防 CSRF 攻击的第一道防线。

第四步：强制 HTTPS（即使未配置 SSL）：
在/* That's all, stop editing! Happy publishing. */之前添加：

// 强制后台和登录页使用 HTTPS（若已配置 SSL） // define('FORCE_SSL_ADMIN', true); // define('FORCE_SSL_LOGIN', true); // 若未配置 SSL，但希望未来无缝迁移，启用此行（WP 5.7+） define('WP_HOME','http://your-domain.com'); define('WP_SITEURL','http://your-domain.com');

第五步：启用对象缓存（为后续 Redis 预留）：

// 启用对象缓存（需安装插件如 Redis Object Cache） define('WP_REDIS_HOST', '127.0.0.1'); define('WP_REDIS_PORT', 6379); define('WP_REDIS_TIMEOUT', 1); define('WP_REDIS_READ_TIMEOUT', 1); define('WP_REDIS_RETRY_INTERVAL', 100);

提示：这几行只是定义常量，不会报错。即使你还没装 Redis，它们也不会影响 WordPress 启动，但为后续性能优化埋下伏笔。

4.2 Apache 虚拟主机配置：解决“wordpress手机端跳转到国外网站”的根源

默认的000-default.conf无法满足生产需求。我们创建一个专用配置，解决两个高频问题：一是 WordPress 伪静态失效，二是移动端异常跳转。

创建配置文件：

sudo nano /etc/apache2/sites-available/wordpress.conf

填入以下内容（关键点已注释）：

<VirtualHost *:80> ServerAdmin webmaster@localhost ServerName your-domain.com ServerAlias www.your-domain.com DocumentRoot /var/www/html # 启用 .htaccess 覆盖 <Directory /var/www/html> Options Indexes FollowSymLinks AllowOverride All # 允许 .htaccess 覆盖，伪静态必需 Require all granted </Directory> # 防止 WordPress 核心文件被直接访问 <Files "wp-config.php"> Require all denied </Files> <Files "wp-includes/*.php"> Require all denied </Files> # 解决“wordpress手机端跳转到国外网站”问题：禁止恶意 RewriteRule # 如果你发现 .htaccess 中有类似 RewriteRule .* http://malicious-site.com [R=301,L] 的规则， # 删除它，并在此处添加防护 <IfModule mod_rewrite.c> RewriteEngine On # 拒绝所有外部重定向到非本站域名的请求 RewriteCond %{HTTP_HOST} !^your-domain\.com$ [NC] RewriteCond %{HTTP_HOST} !^www\.your-domain\.com$ [NC] RewriteRule ^(.*)$ http://your-domain.com/$1 [R=301,L] </IfModule> ErrorLog ${APACHE_LOG_DIR}/wordpress_error.log CustomLog ${APACHE_LOG_DIR}/wordpress_access.log combined </VirtualHost>

启用配置并重启：

sudo a2dissite 000-default.conf sudo a2ensite wordpress.conf sudo systemctl reload apache2

实操心得：AllowOverride All是双刃剑。它让 WordPress 的.htaccess伪静态规则生效，但也给了恶意插件篡改服务器行为的入口。因此，我强烈建议在wp-config.php中添加define('DISALLOW_FILE_EDIT', true);，彻底禁用后台的主题/插件编辑器，从源头杜绝.htaccess被注入恶意重定向代码。

4.3 WordPress 安装向导执行与首屏配置：避开 3 个隐形陷阱

现在访问http://your-server-ip，应该看到 WordPress 安装向导。但这里藏着三个新手必踩的坑：

陷阱一：“无法创建 wp-config.php”错误
原因：/var/www/html/目录权限不对，或wp-config.php文件已存在但权限为 600（向导无法写入）。解决方案：临时改为sudo chmod 644 /var/www/html/wp-config.php，安装完成后再sudo chmod 600。

陷阱二：数据库连接失败
即使你确认用户名密码正确，仍可能失败。检查点：

• sudo netstat -tulpn | grep :3306确认 MySQL 在监听127.0.0.1:3306；
• sudo mysql -u wpuser -p -h 127.0.0.1手动测试连接；
• 检查wp-config.php中DB_HOST是否误写为localhost（socket）而 MySQL 配置为bind-address = 127.0.0.1（TCP），此时必须统一为127.0.0.1。

陷阱三：安装完成后登录 404
这是伪静态未生效的典型症状。检查：

• sudo a2enmod rewrite是否执行；
• wordpress.conf中AllowOverride All是否在<Directory>块内；
• /var/www/html/.htaccess文件是否存在且内容正确（向导会自动生成）。

首屏配置建议：

• 站点标题：避免使用“WordPress Site”，换成具体业务名（如“TechBlog”），利于 SEO；
• 管理员用户名：绝对不要用 admin，改用techadmin等不易猜测的名称；
• 密码：使用pwgen -s -y 16生成 16 位强密码，保存在密码管理器中；
• 邮箱：填写真实邮箱，用于找回密码和接收通知。

安装完成后，立即执行：

sudo rm /var/www/html/wp-config-sample.php sudo rm /var/www/html/readme.html sudo rm /var/www/html/license.txt

删除这些文件，减少信息泄露面。

4.4 基础安全加固：5 分钟完成的 4 层防护

安装只是开始，加固才是生存关键。以下是经实战检验的 4 层防护：

第一层：禁用 XML-RPC（防暴力破解）
在wordpress.conf的<Directory>块内添加：

# 禁用 XML-RPC，除非你明确需要（如 Jetpack 同步） <Files "xmlrpc.php"> Require all denied </Files>

然后sudo systemctl reload apache2。XML-RPC 是 WordPress 暴力破解的主要入口，关闭后可降低 70% 的登录爆破请求。

第二层：限制 wp-login.php 访问频率
在wordpress.conf中添加：

# 对登录页限速：每分钟最多 5 次请求 <Files "wp-login.php"> <IfModule mod_ratelimit.c> SetOutputFilter RATE_LIMIT SetEnv rate-limit 5 </IfModule> </Files>

需先sudo a2enmod ratelimit。这能有效拖慢暴力破解工具的速度。

第三层：隐藏 WordPress 版本号
在wp-config.php中添加：

// 隐藏版本号，减少针对性攻击 remove_action('wp_head', 'wp_generator');

并在主题的functions.php中添加：

// 移除 RSS feed 中的版本号 function remove_version() { return ''; } add_filter('the_generator', 'remove_version');

第四层：设置 PHP 安全头
在wordpress.conf的<VirtualHost>块内添加：

# 添加安全响应头 Header always set X-Frame-Options "DENY" Header always set X-Content-Type-Options "nosniff" Header always set X-XSS-Protection "1; mode=block" Header always set Referrer-Policy "no-referrer-when-downgrade"

需先sudo a2enmod headers。这些头能有效防御点击劫持、MIME 类型混淆、XSS 等常见攻击。

5. 常见问题与排查技巧实录：从 Apache 启动失败到 WordPress 白屏的 12 个真实案例

5.1 Apache 启动失败：Address already in use: AH00072: make_sock: could not bind to address [::]:80

现象：sudo systemctl start apache2返回失败，journalctl -u apache2显示端口被占用。
排查：

sudo ss -tulpn | grep ':80' # 查看哪个进程占用了 80 端口

常见原因与解决：

• Nginx 在运行：sudo systemctl stop nginx && sudo systemctl disable nginx；
• 其他 Apache 实例：ps aux | grep apache2，找到主进程 PID，sudo kill -9 PID；
• Docker 容器映射了 80 端口：docker ps查看，docker stop <container-id>；
• Skype 占用（Windows 子系统场景）：在 Skype 设置中关闭“使用端口 80 和 443”。

实操心得：ss -tulpn比netstat更快更准确，是 Ubuntu 18.04 的首选网络诊断命令。记住这个组合技，能秒杀 90% 的端口冲突问题。

5.2 MySQL 连接被拒绝：Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'

现象：sudo mysql或 WordPress 安装向导报 socket 连接失败。
排查：

sudo systemctl status mysql # 看服务是否 running sudo ls -l /var/run/mysqld/ # 看 mysqld.sock 文件是否存在

解决：

• 若服务未运行：sudo systemctl start mysql；
• 若 sock 文件不存在：sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld，然后重启 MySQL；
• 若权限错误：sudo chown mysql:mysql /var/run/mysqld/mysqld.sock。

5.3 WordPress 后台白屏（WSOD）：无任何错误提示

现象：访问/wp-admin/显示空白页面，但前台正常。
排查流程（按顺序）：

1. 检查 PHP 错误日志：sudo tail -f /var/log/apache2/error.log，刷新后台，看是否有Fatal error；
2. 临时启用 WP_DEBUG：在wp-config.php中将define('WP_DEBUG', false);改为true，并添加：

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

   错误会记录到/var/www/html/wp-content/debug.log；
3. 内存不足：在wp-config.php中增加define('WP_MEMORY_LIMIT', '256M');；
4. 插件冲突：重命名/var/www/html/wp-content/plugins为plugins.off，刷新后台，若恢复则逐个启用排查。

注意：WP_DEBUG_DISPLAY设为false是生产环境铁律，绝不能设为true，否则错误