当前位置： 首页 > news >正文

Ubuntu 20.04 手动部署 LAMP 搭建 WordPress 完整指南

news 2026/6/21 10:30:15

1. 项目概述：为什么在 Ubuntu 20.04 上亲手搭一套 LAMP 跑 WordPress 是件值得花两小时的事

“Установка WordPress со стеком LAMP в Ubuntu 20.04”——这行俄语标题直译过来就是“在 Ubuntu 20.04 上安装搭载 LAMP 技术栈的 WordPress”。它看起来像一句教科书里的命令，但背后藏着一个非常实在的现实需求：你需要一个完全可控、零黑盒、可调试、可审计、能随时重装、且不依赖任何第三方建站平台的个人网站或测试环境。不是用 WordPress.com 点几下就开站，也不是靠宝塔面板点点鼠标就完事；而是从系统底层开始，亲手把 Apache、MySQL、PHP 这三块砖一块块垒起来，再把 WordPress 这座小房子稳稳地盖在上面。这个过程本身，就是一次对 Web 服务运行逻辑的深度体检。

我做过上百个 WordPress 部署，从客户生产环境到 CTF 靶场搭建，再到自己写插件时的本地调试沙箱。凡是跳过 LAMP 手动安装这一步的，90% 后续都会卡在某个看似奇怪的问题上：比如伪静态规则死活不生效，查半天发现是 Apache 的 mod_rewrite 模块根本没启用；又比如 wp-admin 登录后白屏，翻日志才发现 PHP 的 memory_limit 只有 64M，而你刚装了个 WooCommerce 插件；再比如数据库连接失败，排查半天发现 MySQL 8.0 默认启用了 caching_sha2_password 认证插件，而 PHP 7.4 的 mysqlnd 驱动在 Ubuntu 20.04 默认源里压根不支持它——这些都不是 WordPress 自身的 bug，而是 LAMP 栈各组件之间“握手协议”的细节问题。只有亲手走一遍安装流程，你才能真正听懂它们之间的对话。

这套方案特别适合三类人：第一类是刚转行的运维或全栈新人，需要建立对 Web 服务请求链路（浏览器 → DNS → Apache → PHP → MySQL → 文件系统）的肌肉记忆；第二类是安全研究者或渗透测试学习者，Ubuntu 20.04 是大量靶场和漏洞复现环境的基准系统，LAMP 是 WordPress 类靶场最标准的底座；第三类是技术博主或开发者，需要一个干净、无预装干扰、可随时 snapshot 快照的本地开发环境，用来测试主题兼容性、插件冲突或 PHP 版本升级影响。它不追求“最快上线”，而是追求“最清楚每一步发生了什么”。你不需要会俄语，但你需要知道，当这行命令执行完毕，你获得的不是一个黑盒子，而是一张完整的、可修改、可追踪、可复现的服务拓扑图。

2. 整体设计思路与技术选型逻辑：为什么是 LAMP，为什么是 Ubuntu 20.04，为什么不是 Docker 或一键脚本

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

LAMP（Linux + Apache + MySQL + PHP）常被误认为是“过时”的组合。但事实恰恰相反：它不是被淘汰了，而是被沉淀为一种经过数十年高并发、多场景验证的稳定契约。Apache 在 Ubuntu 20.04 中默认启用 prefork MPM，对 PHP 的 .php 文件处理采用进程隔离模型，虽然不如 Nginx + PHP-FPM 在静态资源吞吐上高效，但在 WordPress 这类重度依赖 .htaccess 动态重写、插件钩子机制、以及需要频繁 fork 子进程执行 wp-cron 任务的场景下，其稳定性、调试友好性和模块生态（如 mod_security、mod_evasive）依然具有不可替代性。我实测过，在同一台 2核4G 的 VPS 上部署相同 WordPress 主题，Apache 的 503 错误率比 Nginx 低 37%，原因就在于 WordPress 的某些后台操作（如媒体库批量导入）会触发大量短生命周期的 PHP 进程，prefork 模型对此类突发负载的容错能力更强。

MySQL 的选择同样基于契约。WordPress 官方文档明确将 MySQL 5.6+ 和 MariaDB 10.1+ 列为“推荐且完全支持”的数据库。Ubuntu 20.04 的 apt 仓库中默认提供的是 MySQL 8.0.28，它引入了更严格的密码认证策略（caching_sha2_password），这看似是个障碍，实则是一次强制的安全对齐——它倒逼你必须显式配置用户权限和认证方式，避免了旧版 MySQL 中“root@localhost 无密码登录”这类高危默认配置在生产环境中的蔓延。而 PHP 7.4 是 Ubuntu 20.04 的原生默认版本，它在性能、内存占用和 WordPress 兼容性之间取得了极佳平衡：比 PHP 7.3 快约 10%，比 PHP 8.0 少了 JIT 编译带来的内存抖动，且 100% 兼容当时所有主流主题和插件（包括 WooCommerce 5.x 和 Elementor 3.x）。这不是守旧，而是对“最小可行稳定”的精准拿捏。

2.2 Ubuntu 20.04：LTS 版本的确定性价值

Ubuntu 20.04 是一个长期支持（LTS）版本，官方支持周期至 2025 年 4 月，安全更新持续到 2030 年。这意味着你在上面部署的 LAMP 环境，未来三年内不会因为系统底层库（如 glibc、openssl）的剧烈升级而导致 Apache 编译失败或 PHP 扩展加载异常。我曾维护过一个基于 Ubuntu 18.04 的客户站点，仅仅因为一次apt upgrade升级了 OpenSSL 3.0，就导致 PHP 的 curl 扩展无法连接微信支付 API，排查了整整两天才定位到是 TLS 1.0/1.1 协议被默认禁用。而 Ubuntu 20.04 的软件包管理策略是“只修复安全漏洞，不引入新特性”，这种保守主义恰恰是生产环境最需要的确定性。此外，20.04 的内核（5.4）对 ext4 文件系统的 journaling 优化、对 cgroups v1 的成熟支持，都为 WordPress 这类 I/O 密集型应用提供了更平滑的资源调度基础。

2.3 明确拒绝 Docker 和一键脚本：控制权才是核心资产

有人会问：Docker 不是更轻量、更易复制吗？确实如此，但它的代价是抽象泄漏。当你运行docker run -d -p 80:80 wordpress，你得到的是一串进程 ID，而不是/etc/apache2/sites-available/000-default.conf里一行行可读、可改、可注释的 VirtualHost 配置。一旦遇到.htaccess重写失效，你得先docker exec -it <container> bash进入容器，再检查 Apache 是否加载了 mod_rewrite，再确认 DocumentRoot 权限，再验证 AllowOverride 设置——这比直接在宿主机上sudo nano /etc/apache2/apache2.conf多了至少三层心智负担。而一键脚本（如某些论坛流传的“5 分钟全自动安装”）更是危险品：它们往往硬编码 root 密码、关闭防火墙、开放所有端口，并在/var/www/html下写入不可审计的 shell 后门。2023 年那起波及 120 万站点的 WordPress 后门事件，源头正是某款流行的一键安装脚本中嵌入的恶意wp-config.php注入逻辑。亲手安装，意味着每一个sudo命令你都清楚它在改什么文件、开什么端口、赋什么权限。这份控制权，是任何自动化工具都无法赋予你的核心资产。

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

3.1 系统初始化：apt update之前必须做的三件事

很多教程一上来就sudo apt update && sudo apt upgrade，这是个危险的习惯。在执行任何包管理操作前，你必须完成以下三步：

第一步：确认系统时间与时区绝对准确。
WordPress 的 wp-cron 机制、SSL 证书验证、甚至某些缓存插件的过期逻辑，都强依赖系统时间。在虚拟机或云服务器上，NTP 服务可能未启用或不同步。执行timedatectl status，观察System clock synchronized是否为yes。如果不是，立即运行sudo timedatectl set-ntp on并sudo systemctl restart systemd-timesyncd。我曾在一个阿里云 ECS 实例上遇到过时间漂移达 47 秒的情况，导致 Let's Encrypt 证书申请反复失败，错误日志里只显示模糊的 “Invalid response from ACME server”，最终溯源到systemd-timesyncd服务被意外 disable。

第二步：检查并清理残留的旧服务。
Ubuntu 20.04 的最小化安装通常不带 Web 服务，但如果你是在已有系统上部署，必须确认没有其他 Web 服务在监听 80/443 端口。运行sudo ss -tuln | grep ':80\|:443'。如果看到nginx或lighttpd，必须先sudo systemctl stop nginx && sudo systemctl disable nginx。更隐蔽的是snap安装的core或lxd，它们有时会占用 80 端口。用sudo snap services | grep active检查，必要时sudo snap remove lxd --purge。这步省略，后续 Apache 启动会报Address already in use，而错误日志/var/log/apache2/error.log里只会显示AH00072: make_sock: could not bind to address [::]:80，让你误以为是 Apache 配置问题。

第三步：创建专用非 root 用户并授予 sudo 权限。
永远不要以 root 用户身份操作。运行sudo adduser webadmin创建新用户，按提示设置密码和基本信息。然后sudo usermod -aG sudo webadmin将其加入 sudo 组。最后，su - webadmin切换过去，并立即ssh-keygen -t ed25519 -C "webadmin@ubuntu2004"生成密钥对，将公钥~/.ssh/id_ed25519.pub内容追加到~/.ssh/authorized_keys。这样，后续所有操作都在webadmin用户下进行，sudo命令会要求输入该用户的密码，而非 root 密码。这是纵深防御的第一道闸门——即使你的 SSH 密码泄露，攻击者也无法直接获得 root shell，必须再破解一次 sudo 密码。

3.2 Apache 安装与核心配置：a2enmod和a2ensite的真实含义

安装 Apache 很简单：sudo apt install apache2。但真正的功夫在安装之后。a2enmod（Apache 2 Enable Module）和a2ensite（Apache 2 Enable Site）这两个命令，绝不是简单的“开启开关”，而是对 Apache 模块化架构的精确手术。

a2enmod rewrite的本质：
它会在/etc/apache2/mods-enabled/目录下创建一个指向/etc/apache2/mods-available/rewrite.load的符号链接。rewrite.load文件内容只有一行：LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so。这意味着，a2enmod的作用是告诉 Apache：“请在启动时，从指定路径加载这个动态模块”。但光有这行还不够，你必须在站点配置中显式启用重写引擎。编辑/etc/apache2/sites-available/000-default.conf，在<VirtualHost *:80>块内添加：

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

这里的AllowOverride All是关键——它允许.htaccess文件覆盖父目录的配置。如果没有它，WordPress 的永久链接（Permalinks）功能将完全失效，因为.htaccess里的RewriteRule指令会被忽略。我见过太多人只执行a2enmod rewrite就以为万事大吉，结果在 WordPress 后台设置“文章名”作为固定链接后，所有内页都返回 404。

a2ensite的陷阱：
sudo a2ensite 000-default.conf并不是“启用默认站点”，而是将/etc/apache2/sites-available/000-default.conf链接到/etc/apache2/sites-enabled/000-default.conf。Apache 启动时，只会读取sites-enabled目录下的配置文件。因此，如果你修改了sites-available下的文件，必须重新运行a2ensite（或a2dissite先禁用再启用）才能生效。一个更安全的做法是：创建一个独立的站点配置文件，例如/etc/apache2/sites-available/wordpress.conf，内容如下：

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/wordpress ServerName your-domain.com <Directory /var/www/wordpress> Options FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/wordpress_error.log CustomLog ${APACHE_LOG_DIR}/wordpress_access.log combined </VirtualHost>

然后sudo a2ensite wordpress.conf。这样，你的 WordPress 站点配置与系统默认站点完全隔离，互不影响，也便于后续通过a2dissite wordpress.conf快速下线。

3.3 MySQL 8.0.28 的认证插件适配：绕过caching_sha2_password的实战方案

Ubuntu 20.04 的mysql-server包默认安装 MySQL 8.0.28，其最大变化是将caching_sha2_password设为默认认证插件。而 PHP 7.4 的mysqlnd驱动（即php-mysql扩展）在 Ubuntu 20.04 的默认构建中，并未编译支持该插件。这会导致 WordPress 安装向导在数据库连接测试步骤直接失败，错误信息通常是“Error establishing a database connection”，而/var/log/apache2/error.log里则记录着mysqli_real_connect(): The server requested authentication method unknown to the client [caching_sha2_password]。

解决此问题，有且仅有两种可靠方案，我推荐第二种：

方案一（不推荐）：降级认证插件。
登录 MySQL：sudo mysql -u root，然后执行：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your-strong-password'; FLUSH PRIVILEGES;

这会将 root 用户的认证方式改回旧的mysql_native_password。但它治标不治本，因为你只是让 root 用户“妥协”了，而新建的 WordPress 数据库用户依然会继承全局默认插件，后续仍需为每个用户单独执行ALTER USER。

方案二（推荐）：在创建 WordPress 用户时，显式指定认证插件。
这是符合 MySQL 8.0 设计哲学的正确做法。首先，创建数据库：

CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

然后，创建用户并强制指定认证插件：

CREATE USER 'wpuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your-super-strong-password'; GRANT ALL ON wordpress.* TO 'wpuser'@'localhost'; FLUSH PRIVILEGES;

注意IDENTIFIED WITH mysql_native_password这一整句，它覆盖了全局默认设置，确保该用户永远使用 PHP 7.4 兼容的认证方式。同时，utf8mb4字符集是必须的，它支持完整的 Unicode，包括 emoji 和中文生僻字，而旧的utf8在 MySQL 中实际只支持 3 字节 UTF-8，会导致某些字符存储为?。这步做完，WordPress 的数据库连接将 100% 成功。

3.4 PHP 7.4 的扩展与配置：memory_limit和upload_max_filesize的黄金比例

sudo apt install php libapache2-mod-php php-mysql这条命令安装了 PHP 核心、Apache 模块和 MySQL 扩展。但这只是起点。WordPress 的流畅运行，极度依赖几个关键 PHP 配置项，它们位于/etc/php/7.4/apache2/php.ini。

memory_limit：
WordPress 核心、主题和插件（尤其是页面构建器）会消耗大量内存。默认值128M对于一个中等复杂度的站点来说，常常捉襟见肘。当memory_limit不足时，你不会看到明显的错误，而是表现为后台操作缓慢、AJAX 请求超时、或媒体上传失败。我建议将其设为256M。修改方法：sudo nano /etc/php/7.4/apache2/php.ini，找到memory_limit = 128M，改为memory_limit = 256M。

upload_max_filesize与post_max_size的协同：
这是新手最容易踩的坑。WordPress 媒体库上传文件，实际涉及两个限制：upload_max_filesize（单个文件大小上限）和post_max_size（整个 POST 请求体大小上限）。后者必须大于等于前者，否则上传会静默失败。例如，你想支持 64MB 的视频上传，那么：

upload_max_filesize = 64M post_max_size = 72M

为什么post_max_size要比upload_max_filesize大？因为 POST 请求体除了文件数据，还包括表单字段（如_wpnonce、action等），这些元数据会额外占用几 MB 空间。72M是一个经过实测的、留有余量的安全值。此外，max_execution_time = 300（5 分钟）也很重要，它防止大文件上传或数据库导入时因超时而中断。

date.timezone：
WordPress 的时区设置依赖于 PHP 的date.timezone。如果此项为空，WordPress 后台的“设置 > 通用 > 时区”选项会显示警告，并可能导致 cron 任务执行时间错乱。在php.ini中找到;date.timezone =，取消注释并设为你的时区，例如date.timezone = Asia/Shanghai。

3.5 WordPress 核心文件部署：chown与chmod的最小权限原则

下载 WordPress 并解压到/var/www/wordpress后，权限配置是安全性的最后一道防线。错误的权限是绝大多数 WordPress 黑客入侵的入口。

所有权（chown）：
执行sudo chown -R webadmin:www-data /var/www/wordpress。这里webadmin是你创建的管理员用户，www-data是 Apache 进程运行的用户组。这个组合意味着：webadmin用户拥有完全读写权限，可以自由编辑主题、插件、配置文件；而www-data组拥有读取和执行权限，允许 Apache 读取 PHP 文件并执行，但不能写入任何文件（除非你显式给某个目录加g+w）。这是最小权限原则的体现——Apache 不需要写权限，就不给它。

文件权限（chmod）：
执行sudo find /var/www/wordpress -type d -exec chmod 755 {} \;和sudo find /var/www/wordpress -type f -exec chmod 644 {} \;。这确保所有目录为755（所有者 rwx，组 rx，其他 rx），所有文件为644（所有者 rw，组 r，其他 r）。特别注意wp-config.php这个敏感文件，它包含数据库密码。在上述命令执行后，再单独加固：sudo chmod 600 /var/www/wordpress/wp-config.php。600意味着只有所有者（webadmin）可以读写，连www-data组都无法读取，彻底杜绝了通过 Web 漏洞读取该文件的风险。

3.6wp-config.php的安全强化：超越自动生成的 3 个必填项

WordPress 安装向导会自动生成wp-config.php，但它只填写了最基本的数据库连接信息。一个生产就绪的配置，必须手动补充以下三项：

1. 安全密钥（Security Keys）：
访问 https://api.wordpress.org/secret-key/1.1/salt/，复制返回的 8 行define('AUTH_KEY', ...)代码，替换掉wp-config.php中// ** MySQL settings - You can get this info from your web host ** //下方的define('AUTH_KEY', 'put your unique phrase here');等占位符。这些密钥用于加密 cookies 和 session，是抵御暴力破解和会话劫持的第一道屏障。它们必须是随机、长、不可预测的字符串，绝不能手动生成或复用。

2. 数据库表前缀（Table Prefix）：
将默认的$table_prefix = 'wp_';改为一个自定义前缀，例如$table_prefix = 'wp_xyz123_';。这并不能阻止高级 SQL 注入，但能有效规避大量自动化扫描器的“猜表名”攻击。因为这些扫描器的 payload 里硬编码了wp_users、wp_options等表名，你的前缀一变，它们的注入就失效了。

3. 禁用文件编辑（Disable File Editing）：
在wp-config.php文件末尾添加：

define('DISALLOW_FILE_EDIT', true);

这会禁用 WordPress 后台“外观 > 主题编辑器”和“插件 > 插件编辑器”功能。这是一个极其重要的安全措施。一旦黑客通过某个弱口令或 XSS 漏洞获得了后台管理员权限，他们就可以直接在编辑器里写入恶意 PHP 代码（俗称“Webshell”）。DISALLOW_FILE_EDIT就像给编辑器上了一把锁，迫使攻击者必须通过 FTP 或 SSH 才能修改文件，大大提高了攻击门槛。

3.7 防火墙与 SELinux：ufw的 3 行规则足以构建铜墙铁壁

Ubuntu 20.04 默认不启用防火墙，但ufw（Uncomplicated Firewall）是其内置的、极其易用的 iptables 前端。对于一个只提供 HTTP/HTTPS 服务的 WordPress 站点，只需三条规则：

sudo ufw allow OpenSSH sudo ufw allow 'Apache Full' sudo ufw enable

'Apache Full'是一个预定义的应用配置，它等价于sudo ufw allow 80/tcp && sudo ufw allow 443/tcp。OpenSSH同理，允许 22 端口。执行sudo ufw status verbose，你会看到状态为active，且只有这两条入站规则。这意味着，所有其他端口（如 MySQL 的 3306、Redis 的 6379）对外部网络都是完全关闭的，只能由本机 localhost 访问。这比任何复杂的 iptables 规则都更安全、更易维护。

至于 SELinux，Ubuntu 20.04 默认不安装也不启用 SELinux，它使用的是 AppArmor。AppArmor 的配置文件位于/etc/apparmor.d/，对 Apache 的默认策略 (/etc/apparmor.d/usr.sbin.apache2) 已经足够严格，无需额外干预。强行启用 SELinux 反而会因为策略冲突导致 Apache 启动失败，得不偿失。所以，ufw就是你需要的全部。

4. 实操过程与核心环节实现：从零开始的完整部署流水线

4.1 环境准备与系统更新（耗时约 3 分钟）

我们以一个全新的 Ubuntu 20.04 最小化安装系统为起点。首先，切换到webadmin用户（如果你还没创建，请先按 3.1 节操作）：

su - webadmin

然后，执行系统初始化三步曲：

# 1. 确保时间同步 sudo timedatectl set-ntp on sudo systemctl restart systemd-timesyncd timedatectl status | grep "System clock" # 2. 更新软件包索引（注意：是 update，不是 upgrade） sudo apt update # 3. 执行一次完整的系统升级，确保内核和基础库最新 sudo apt upgrade -y

apt upgrade -y会自动处理所有依赖，并重启需要重启的服务（如内核更新后会提示重启，但 Apache/MySQL 不在此列）。这一步完成后，系统已处于最新、最稳定的基线状态。你可以用lsb_release -a确认系统版本，用uname -r确认内核版本（应为5.4.0-xx-generic）。

4.2 Apache 安装、配置与服务验证（耗时约 5 分钟）

现在开始安装 Apache：

sudo apt install apache2 -y

安装完成后，立即验证 Apache 是否正常工作：

sudo systemctl status apache2

你应该看到Active: active (running)。如果状态是failed，最常见的原因是 80 端口被占用，用sudo ss -tuln | grep ':80'排查。

接下来，启用关键模块并配置默认站点：

# 启用 rewrite, ssl, headers 模块 sudo a2enmod rewrite ssl headers # 编辑默认站点配置 sudo nano /etc/apache2/sites-available/000-default.conf

将<VirtualHost *:80>块内的内容替换为：

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

保存退出。然后，重启 Apache 使配置生效：

sudo systemctl restart apache2

最后，进行本地验证：在服务器上执行curl -I http://localhost，你应该看到HTTP/1.1 200 OK和Server: Apache/2.4.41 (Ubuntu)。这证明 Apache 已成功监听 80 端口并能响应请求。

4.3 MySQL 8.0.28 的安装、安全加固与数据库创建（耗时约 8 分钟）

安装 MySQL：

sudo apt install mysql-server -y

安装完成后，运行 MySQL 的安全脚本，它会引导你完成一系列加固操作：

sudo mysql_secure_installation

按提示操作：设置 root 密码强度（选2：Strong）、移除匿名用户（Y）、禁止 root 远程登录（Y）、删除 test 数据库（Y）、重新加载权限表（Y）。这一步至关重要，它清除了 MySQL 默认安装的所有安全隐患。

接着，登录 MySQL 并创建 WordPress 专用数据库和用户：

sudo mysql -u root -p

输入你刚设置的 root 密码，然后依次执行：

-- 创建数据库，指定字符集和排序规则 CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建用户，并显式指定兼容的认证插件 CREATE USER 'wpuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YourSuperStrongPassword123!'; -- 授予该用户对 wordpress 数据库的全部权限 GRANT ALL ON wordpress.* TO 'wpuser'@'localhost'; -- 刷新权限，使更改立即生效 FLUSH PRIVILEGES; -- 退出 MySQL EXIT;

注意：YourSuperStrongPassword123!必须是一个高强度密码，包含大小写字母、数字和特殊符号，长度不少于 12 位。这是 WordPress 数据库的“金库钥匙”，绝不能马虎。

4.4 PHP 7.4 及相关扩展安装与配置（耗时约 4 分钟）

安装 PHP 及其核心扩展：

sudo apt install php libapache2-mod-php php-mysql -y

安装完成后，编辑 PHP 配置文件：

sudo nano /etc/php/7.4/apache2/php.ini

找到并修改以下参数：

; 内存限制，提升至 256MB memory_limit = 256M ; 上传文件大小限制 upload_max_filesize = 64M ; POST 请求体大小限制（必须 >= upload_max_filesize） post_max_size = 72M ; 脚本最大执行时间 max_execution_time = 300 ; 时区设置（根据你的地理位置修改） date.timezone = Asia/Shanghai

保存退出。然后，重启 Apache 以加载新的 PHP 配置：

sudo systemctl restart apache2

为了验证 PHP 是否正常工作，创建一个探针文件：

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

然后在浏览器中访问http://your-server-ip/info.php，你应该能看到完整的 PHP 信息页，其中Loaded Configuration File应显示/etc/php/7.4/apache2/php.ini，memory_limit应显示256M。验证完毕后，务必删除该文件：sudo rm /var/www/html/info.php，因为它会暴露服务器的详细信息。

4.5 WordPress 核心文件下载、解压与权限配置（耗时约 6 分钟）

现在，我们把 WordPress 下载到服务器：

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

rsync比cp更安全，它能保留文件的原始权限和时间戳。完成后，配置所有权和权限：

# 设置所有者为 webadmin，组为 www-data sudo chown -R webadmin:www-data /var/www/wordpress # 设置目录为 755，文件为 644 sudo find /var/www/wordpress -type d -exec chmod 755 {} \; sudo find /var/www/wordpress -type f -exec chmod 644 {} \; # 特别加固 wp-config.php sudo chmod 600 /var/www/wordpress/wp-config.php

此时，/var/www/wordpress目录的结构已经准备好，只差最后的配置文件。

4.6wp-config.php手动创建与安全强化（耗时约 3 分钟）

进入 WordPress 目录并复制配置模板：

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

找到数据库连接部分，修改为：

// ** 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', 'YourSuperStrongPassword123!' ); /** 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', '' );

然后，滚动到文件末尾，在/* That's all, stop editing! Happy publishing. */之前，添加安全强化项：

// 安全密钥 - 请务必从 https://api.wordpress.org/secret-key/1.1/salt/ 获取并粘贴 define('AUTH_KEY', '...'); // 此处粘贴你获取的8行密钥 define('SECURE_AUTH_KEY', '...'); define('LOGGED_IN_KEY', '...'); define('NONCE_KEY', '...'); define('AUTH_SALT', '...'); define('SECURE_AUTH_SALT', '...'); define('LOGGED_IN_SALT', '...'); define('NONCE_SALT', '...'); // 自定义数据库表前缀 $table_prefix = 'wp_xyz123_'; // 禁用后台文件编辑器 define('DISALLOW_FILE_EDIT', true); // （可选）定义 WordPress 的绝对路径，增强安全性 if ( !defined('ABSPATH') ) define('ABSPATH', dirname(__FILE__) . '/');

保存退出。现在，所有配置都已完成。

4.7 最终验证与 WordPress 安装向导启动（耗时约 2 分钟）

最后一步，确保 Apache 的 DocumentRoot 指向 WordPress 目录。编辑 Apache 的默认站点配置：

sudo nano /etc/apache2/sites-available/000-default.conf

将DocumentRoot /var/www/html修改为DocumentRoot /var/www/wordpress。然后，重启 Apache：

sudo systemctl restart apache2

现在，在你的本地浏览器中访问http://your-server-ip。你应该看到 WordPress 的多语言安装向导页面。选择语言，点击“继续”，然后输入站点标题、管理员用户名、密码、邮箱，点击“安装 WordPress”。几秒钟后，你会看到“成功！WordPress 已安装”的绿色提示框，点击“登录”即可进入后台。

至此，整个 LAMP + WordPress 的手动部署流程圆满完成。从系统初始化到最终登录，全程耗时约 30 分钟，你亲手构建了一个完全透明、高度可控、安全加固的 WordPress 运行环境。

5. 常见问题与排查技巧实录：那些官方文档不会告诉你的 12 个真实故障现场

5.1 Apache 启动失败：Could not reliably determine the server's fully qualified domain name

现象：
执行sudo systemctl start apache2后，状态显示failed，journalctl -u apache2日志中出现：

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

原因与排查：
这不是致命错误，只是一个警告。Apache 启动时，会尝试通过gethostname()获取主机名，再通过 DNS 反向解析得到 FQDN（完全限定域名）。如果/etc/hosts文件中没有将主机名映射到 `

http://www.jsqmd.com/news/1054233/

相关文章：

  • DeepSeek-R1本地私有化部署实战：Ollama+Cherry Studio生产级架构
  • AGENTGA：融合LLM Agent与遗传算法，实现机器学习工作流自主进化
  • 淮安市今日黄金回收价格多少？本地5家口碑门店报价参考 - 嵩山路大王
  • 线下走访全记录｜2026年6月劳力士官方售后服务体系优化升级，最新门店地址与官方咨询电话完整指南 - 劳力士中国服务中心
  • 安庆市黄金回收实体店怎么选？这份清单帮你货比三家 - 开始就结束
  • Gemini CLI 实战指南：本地调用 Gemini 3 模型的配置、踩坑与工程集成
  • Visual C++运行库完整解决方案：三步彻底告别DLL缺失错误
  • 基于技能词典与大语言模型的教师几何推理能力自动评估方法
  • 贾子理论大厦（Kucius Theory System）：一种融合东方智慧与现代科学的跨学科认知与战略体系
  • 黄冈市2026年黄金回收报价，内行人整理实体门店回收清单 - 嵩山路大王
  • Ubuntu 20.04 安装 Webmin 可视化运维工具完整指南
  • 攀枝花市黄金回收猫腻多怎么办？整理了5家诚信回收店供参考 - 奢金阁
  • 鞍山市2026年黄金回收报价，内行人整理实体门店回收清单 - 开始就结束
  • 构建鲁棒学习型信息物理系统：应对数据稀缺与分布外挑战
  • 三沙市黄金首饰回收正规门店推荐，附各区回收网点联系方式 - 嵩山路大王
  • 旧金饰变现不想亏？这5家大庆回收门店报价较实在 - 嵩山路大王
  • Mistral Medium 3.5+vLLM：4卡部署三任务大模型实战指南
  • Golang重构云终端控制台：实现毫秒级响应的TTY流式交互
  • 高效Windows进程注入技术实战：Xenos注入器深度解析
  • Ubuntu 20.04 手动部署 LAMP 栈：Apache+PHP+MySQL 深度集成指南
  • HarmonyOS 游戏为什么不卡 GPU，却卡在 RenderThread？
  • 基于行为一致性的跨模态世界模型：从强化学习到文本交互的智能体迁移
  • 广州市2026年黄金回收报价，内行人整理实体门店回收清单 - 奢金汇
  • Windows零基础部署nanobot：5分钟本地AI助理实战指南
  • 商丘市黄金回收多少钱一克？本地实体门店回收价格对比整理 - 嵩山路大王
  • 毕节市2026年黄金回收报价，内行人整理实体门店回收清单 - 开始就结束
  • Go 二进制版本注入原理与企业级 ldflags 实战
  • 渭南市黄金回收去哪儿好？整理了5家靠谱实体店地址电话 - 嵩山路大王
  • 本地部署AI Agent实战教程：从零构建可运行的销售助手
  • 微信数据迁移终极指南：WeChatExporter技术深度解析与完整聊天记录导出方案