1. 这不是“装个博客”那么简单：为什么 Debian 9 + LEMP 是 WordPress 部署的黄金组合
你点开这个标题，大概率不是想学一句“apt install wordpress”就完事。你可能刚买了一台 VPS，看着控制台里干净的 Debian 9 命令行发愣；也可能正被客户催着三天内上线一个企业官网，而对方明确要求“必须是 WordPress，但不能用共享主机那种慢得像蜗牛的环境”；又或者，你刚在安全通报里看到“120万 WordPress 站点被植入后门”的标题，手心冒汗，开始琢磨：我自己的站，是不是也裸奔在默认配置上？——这些场景，恰恰就是 Debian 9 搭配 LEMP（Linux + Nginx + MySQL + PHP）这套组合拳真正发力的地方。
它解决的从来不是“能不能跑起来”的问题，而是“跑得稳不稳、快不快、安不安全、好不好管”的一整套生产级诉求。Debian 9（代号 Stretch）在 2017 年发布，其核心价值在于长达五年的长期支持（LTS），这意味着它的内核、基础库和关键组件都经过了海量服务器环境的锤炼，稳定性远超那些追求新特性的滚动发行版。而 LEMP 中的 Nginx，不是 Apache 的平替，它是为高并发、低内存占用而生的反向代理与 Web 服务引擎。当你面对一个日均 5000 UV 的企业站，或者一个需要承载会员系统、在线表单提交反馈的 WooCommerce 商城时，Nginx 的事件驱动模型能让你用更少的服务器资源扛住更大的流量洪峰。MySQL 5.7 提供了成熟的事务支持和查询优化能力，PHP 7.0 则是 WordPress 性能跃升的关键——它比 PHP 5.6 快了近两倍，这对一个插件动辄二三十个、主题功能堆叠的现代 WordPress 站点来说，意味着首屏加载时间能从 3 秒压到 1.2 秒。这不是参数游戏，这是真实影响用户跳出率、SEO 排名和转化率的硬指标。所以，当你选择这个方案，你选的不是一个安装教程，而是一套面向真实业务场景的、可审计、可监控、可扩展的基础设施底座。它天然适配那些对建站有基本技术认知、不愿被托管服务商锁死、同时又不想把精力耗在无休止的服务器调优上的中小团队或独立开发者。你不需要成为 Linux 内核专家，但你需要理解每个命令背后在做什么——这正是我们接下来要拆解清楚的。
2. 为什么是 LEMP，而不是 LAMP 或一键包？架构选型背后的硬逻辑
2.1 Nginx vs Apache：不只是“换了个名字”的性能博弈
很多人第一次接触 LEMP，下意识会觉得：“不就是把 Apache 换成 Nginx 吗？反正都是跑 PHP。” 这个想法会直接把你带进坑里。Apache 和 Nginx 的底层设计哲学完全不同。Apache 采用的是“进程/线程驱动模型”，每个 HTTP 请求都会分配一个独立的进程或线程。好处是模块丰富、.htaccess 规则灵活，坏处是当并发连接数上来时，内存消耗呈线性甚至指数级增长。我曾经维护过一台 2 核 4G 的 VPS，上面跑着一个带 WooCommerce 的 WordPress 站，用 Apache 默认配置，在一次促销活动期间，仅 800 个并发用户就让服务器内存使用率冲到 95%，MySQL 开始频繁报错，整个站直接“假死”。换成 Nginx 后，同样的硬件，轻松扛住了 2500+ 并发，内存占用稳定在 60% 以下。
Nginx 用的是“事件驱动、异步非阻塞”模型。它用一个主进程管理多个工作进程（worker process），每个工作进程又能通过 epoll（Linux 下的高效 I/O 多路复用机制）同时处理成千上万个连接。它不为每个连接创建新进程，而是把所有连接都挂在事件循环里，哪个连接有数据可读、可写，就去处理哪个。这就解释了为什么 Nginx 在静态文件（图片、CSS、JS）分发上天生就比 Apache 快，也解释了为什么 WordPress 的伪静态规则（比如将/post-name/这种友好 URL 映射回index.php）在 Nginx 里必须用try_files指令来写，而不是像 Apache 那样靠.htaccess文件层层递归解析——因为 Nginx 的配置是“编译时加载、运行时只读”的，它拒绝在请求过程中动态读取和解析文件，这本身就是一种性能保障和安全加固。
提示：WordPress 官方文档里那句“Nginx is not officially supported”其实是个历史遗留的误解。它的真实含义是“WordPress 核心团队不提供 Nginx 配置文件的官方维护”，而不是“Nginx 跑不了 WordPress”。恰恰相反，全球 Top 1000 的高流量 WordPress 站中，超过 65% 使用 Nginx 作为前端 Web 服务器，其中绝大多数都部署在 Debian/Ubuntu 这类稳定发行版上。
2.2 Debian 9：稳定压倒一切的“老派”智慧
为什么不是更新的 Debian 10（Buster）或 11（Bullseye）？这里有个关键的时间窗口问题。Debian 9 Stretch 的生命周期是 2017 年 6 月到 2022 年 6 月（LTS 延长至 2024 年）。这意味着，截至 2023 年底，大量仍在服役的企业级服务器、云主机镜像、甚至是某些嵌入式设备的管理后台，其默认操作系统仍是 Debian 9。它的软件源里，PHP 是 7.0，MySQL 是 5.7，Nginx 是 1.10，这些版本与 WordPress 5.x 系列（尤其是 5.0 到 5.6 这个主流稳定期）的兼容性经过了数年实战检验。而 Debian 10 引入的 PHP 7.3 虽然更新，但早期版本存在一些与特定 WordPress 插件（比如某些老版本的 WP Super Cache）的兼容性问题；Debian 11 的 PHP 8.0 则对很多未及时更新的商业主题构成了“兼容性断崖”。
更重要的是，Debian 9 的apt包管理系统极其成熟。它的依赖解析算法以“保守”著称，不会为了装一个新包而强行升级一堆底层库，从而避免了“升级一个包，崩掉整个系统”的灾难。我在给一家本地律所部署官网时，客户明确要求“服务器不能有任何意外重启，律师们随时要查案例”。我选择了 Debian 9，全程只执行了apt update && apt upgrade --dry-run来预览变更，确认没有涉及内核或关键服务的升级后，才进行实际更新。这种可控性，是很多追求“最新”的发行版无法提供的。它不是落后，而是在特定场景下，对“确定性”的极致追求。
2.3 为什么坚决不用“一键安装包”？
网络上充斥着各种“WordPress 一键安装脚本”，它们确实能在 3 分钟内给你一个能访问的首页。但代价是什么？是根目录下多出几十个权限为777的缓存文件夹；是数据库密码明文写在/var/www/html/wp-config.php里，且该文件的属主是www-data（Web 服务用户）；是 Nginx 配置里开着autoindex on，让整个网站目录结构一览无余；是 PHP 的display_errors被设为On，任何代码错误都会把数据库用户名、路径等敏感信息直接打印在网页上。这些，都是“120 万站点被植入后门”的温床。
LEMP 手动部署的核心价值，就在于“过程即安全”。每一个chmod命令，每一次chown操作，每一条location配置，都是你亲手为系统筑起的一道墙。你知道wp-content目录为什么必须是755而不是777；你知道wp-config.php文件必须600且属主是root，这样即使 Web 服务被攻破，攻击者也无法直接读取它；你知道 Nginx 的location ~ \.php$块里，fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;这一行，是为了防止“路径遍历”攻击，确保 PHP 只能执行DOCUMENT_ROOT下的文件，而不是/etc/passwd这样的系统文件。这些细节，没有一个一键包会为你解释，它们只会用最“省事”的方式，把你推向风险的边缘。
3. 从零开始：LEMP 环境搭建与 WordPress 部署全流程实操
3.1 环境初始化与系统加固（5 分钟）
在你敲下第一个apt命令之前，请先完成三件小事，它们能帮你省下未来 80% 的排查时间。
第一，更新系统时间并启用 NTP。Debian 9 默认不开启时间同步，而 SSL 证书、日志分析、甚至某些插件的授权验证，都极度依赖准确的时间。执行：
sudo timedatectl set-ntp on sudo systemctl restart systemd-timesyncd然后用timedatectl status确认状态是active (running)且System clock synchronized: yes。别小看这一步，我见过太多次，因为服务器时间比标准时间快了 5 分钟，导致 Let's Encrypt 申请 SSL 证书时反复失败，错误提示却是“域名验证超时”，让人一头雾水。
第二，创建一个非 root 的管理用户，并禁用 root 密码登录。这是 Linux 服务器安全的基石。
sudo adduser deployer sudo usermod -aG sudo deployer # 编辑 SSH 配置 sudo nano /etc/ssh/sshd_config找到PermitRootLogin这一行，将其改为PermitRootLogin no，保存退出后，务必执行sudo systemctl restart ssh。然后，立刻用新用户deployer登录一次，确认一切正常，再回到 root 用户下执行sudo passwd -l root来锁定 root 密码。这一步看似繁琐，但它能有效阻止 99% 的暴力破解攻击——黑客的扫描器扫到 22 端口，发现 root 登录被禁，往往就会转向下一个目标。
第三，配置基础防火墙。Debian 9 自带iptables，但我们用更友好的ufw（Uncomplicated Firewall）来管理。
sudo apt install ufw sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow OpenSSH sudo ufw allow 'Nginx Full' # 这会同时放行 80 和 443 端口 sudo ufw enable执行sudo ufw status verbose，你会看到一个清晰的规则列表。记住，防火墙不是“装上就完事”，它是一个活的策略。比如，如果你后续要加 Redis 缓存，就需要sudo ufw allow 6379；如果要用 Fail2ban 防爆破，它会自动在 ufw 里添加规则。现在，你的服务器已经从“完全裸奔”变成了“穿着防弹衣的战士”，可以开始真正的安装了。
3.2 安装与配置 LEMP 栈（15 分钟）
安装 Nginx：
sudo apt update sudo apt install nginx安装完成后，Nginx 会自动启动。用sudo systemctl status nginx确认状态是active (running)。此时，用浏览器访问你的服务器 IP，应该能看到 Nginx 的欢迎页。如果看不到，请检查 ufw 是否放行了 80 端口，以及云服务商的安全组是否开放了该端口。
安装 MySQL：
sudo apt install mysql-server安装过程中，MySQL 5.7 会自动生成一个随机 root 密码，并存储在/etc/mysql/debian.cnf文件里。但这个密码是给系统内部脚本用的，我们不建议直接用它。更好的做法是，安装完后立即运行sudo mysql_secure_installation。这个向导会引导你：
- 设置 root 用户的强密码（请务必记下来！）
- 删除匿名用户（
Remove anonymous users? [Y/n] Y） - 禁止 root 远程登录（
Disallow root login remotely? [Y/n] Y） - 删除测试数据库（
Remove test database and access to it? [Y/n] Y） - 重载权限表（
Reload privilege tables now? [Y/n] Y）
这五步做完，你的 MySQL 就从“实验室玩具”变成了“生产级数据库”。特别注意第二步和第三步，它们直接堵死了两个最常见的入侵入口。
安装 PHP 及其扩展：
sudo apt install php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl php-zip这里的关键是php-fpm（FastCGI Process Manager）。它不是 PHP 的一个“插件”，而是 PHP 与 Nginx 通信的桥梁。Nginx 本身不解析 PHP，它把.php请求转发给php-fpm进程，由php-fpm去执行并返回结果。php-mysql是连接 MySQL 的驱动，php-curl是很多主题和插件（如社交媒体分享、远程 API 调用）的必备项，php-gd是图像处理库，没有它，WordPress 的缩略图生成、图片裁剪功能会全部失效。php-mbstring和php-xml则是 WordPress 核心的硬性依赖，缺少它们，后台根本打不开。
安装完后，需要修改php-fpm的默认配置，让它更安全：
sudo nano /etc/php/7.0/fpm/pool.d/www.conf找到以下几行并修改：
; 修改监听方式，从 TCP 改为 Unix Socket，更快更安全 listen = /run/php/php7.0-fpm.sock ; 修改权限，确保只有 Nginx 的 worker 进程能访问 listen.owner = www-data listen.group = www-data listen.mode = 0660 ; 修改 PHP 进程的用户和组，避免以 root 身份运行 user = www-data group = www-data ; 关键！禁止 PHP 访问根目录以外的文件，防止路径遍历 php_admin_value[open_basedir] = /var/www/html/:/tmp/改完保存，然后重启服务：sudo systemctl restart php7.0-fpm。
3.3 配置 Nginx 虚拟主机与 WordPress 伪静态（10 分钟）
现在，Nginx、MySQL、PHP 都已就位，但它们还只是散落的零件。我们需要一个“蓝图”，把它们组装成一个能跑 WordPress 的整体。这个蓝图，就是 Nginx 的虚拟主机（Server Block）配置。
首先，创建网站根目录并设置权限：
sudo mkdir -p /var/www/html/example.com sudo chown -R $USER:$USER /var/www/html/example.com sudo chmod -R 755 /var/www/html注意，这里chown的是$USER（即你当前登录的用户，比如deployer），而不是www-data。这是为了后续你用 SFTP 上传文件时，不会因为权限问题而失败。www-data用户只需要有读取权限即可。
然后，创建一个全新的配置文件：
sudo nano /etc/nginx/sites-available/example.com将以下内容粘贴进去（请务必将example.com替换为你自己的域名）：
server { listen 80; listen [::]:80; root /var/www/html/example.com; index index.php index.html index.htm; server_name example.com www.example.com; # WordPress 伪静态核心规则 location / { try_files $uri $uri/ /index.php?$args; } # 禁止访问敏感文件 location ~ /\.ht { deny all; } location ~ ^/wp-content/.+\.php$ { deny all; } location ~ ^/wp-includes/.+\.php$ { deny all; } location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; } # PHP 处理块 location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.0-fpm.sock; # 关键安全补丁：防止 CVE-2019-11043 fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; } # 禁止访问 .log 文件 location ~ \.log$ { deny all; } }这段配置里，location /块里的try_files指令就是 WordPress 伪静态的灵魂。它告诉 Nginx：“当用户请求/about/时，先看看/var/www/html/example.com/about/这个目录是否存在；不存在，就看看/var/www/html/example.com/about/index.html存不存在；还不存在，那就把请求交给/var/www/html/example.com/index.php，并把原始请求的参数$args一起传过去。” 这样，WordPress 的rewrite模块才能根据这些参数，从数据库里找出正确的文章内容。
配置完后，需要启用它：
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ sudo nginx -t # 测试配置语法是否正确 sudo systemctl reload nginxnginx -t是神命令，每次修改配置后必敲。它会告诉你哪一行错了，错在哪里。我曾因为一个漏掉的分号，花了 40 分钟在日志里大海捞针，后来养成习惯，改完就t，再也没为语法错误浪费过时间。
3.4 下载、配置与安装 WordPress（10 分钟）
现在，Web 服务器已经准备好接收请求了，我们可以把 WordPress “放”进去了。
进入网站根目录：
cd /var/www/html/example.com下载并解压 WordPress（使用官方最新稳定版）：
sudo wget https://wordpress.org/latest.tar.gz sudo tar -xzf latest.tar.gz sudo mv wordpress/* ./ sudo rmdir wordpress sudo rm latest.tar.gz注意，mv wordpress/* ./这条命令是关键。它把wordpress文件夹里的所有文件（包括wp-admin,wp-includes,wp-config.php等）都移动到当前目录（即/var/www/html/example.com），而不是把整个wordpress文件夹放进去。否则，你的网站 URL 就会变成example.com/wordpress/，这显然不是我们想要的。
接下来，配置数据库。登录 MySQL：
sudo mysql -u root -p输入你之前设置的 root 密码，然后创建一个专门给 WordPress 用的数据库和用户：
CREATE DATABASE wordpress_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'your_strong_password_here'; GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost'; FLUSH PRIVILEGES; EXIT;这里用了utf8mb4字符集，而不是旧的utf8。因为utf8mb4才能完整支持 Emoji 表情、中文四字节生僻字等，这是现代网站的标配。GRANT ALL PRIVILEGES看似很宽泛，但因为我们指定了'wp_user'@'localhost'，这个用户只能从本机连接，安全性是有保障的。
最后，配置 WordPress 的wp-config.php文件：
sudo cp wp-config-sample.php wp-config.php sudo nano wp-config.php找到数据库配置部分，填入你刚才创建的信息：
define('DB_NAME', 'wordpress_db'); define('DB_USER', 'wp_user'); define('DB_PASSWORD', 'your_strong_password_here'); define('DB_HOST', 'localhost');然后，强烈建议在文件末尾添加以下几行，它们是 WordPress 安全的“定海神针”：
// 禁用文件编辑功能，防止后台被黑后直接改代码 define('DISALLOW_FILE_EDIT', true); // 启用自动更新核心（小版本） define('WP_AUTO_UPDATE_CORE', 'minor'); // 设置密钥，去 https://api.wordpress.org/secret-key/1.1/salt/ 获取 define('AUTH_KEY', 'put your unique phrase here'); // ... 其他密钥同理DISALLOW_FILE_EDIT这一行，能直接让 90% 的“后台挂马”攻击失效。因为攻击者即使拿到了管理员账号，也无法在后台的“外观 > 编辑”里修改主题或插件的 PHP 文件。
保存退出，现在，用浏览器访问http://example.com，就应该能看到熟悉的 WordPress 安装向导了。填写站点标题、管理员邮箱、用户名和密码，点击“安装 WordPress”，大功告成。
4. 部署之后的“真功夫”：安全加固、性能调优与日常运维
4.1 WordPress 安全加固：不止于“改密码”
安装完成只是起点，真正的安全防护才刚刚开始。WordPress 的安全，是一个“纵深防御”体系，需要在多个层面布防。
第一层：文件系统权限。这是最容易被忽视，也是最基础的一环。执行以下命令：
sudo find /var/www/html/example.com -type d -exec chmod 755 {} \; sudo find /var/www/html/example.com -type f -exec chmod 644 {} \; sudo chmod 600 /var/www/html/example.com/wp-config.php sudo chown -R www-data:www-data /var/www/html/example.com解释一下：所有目录设为755（所有者可读写执行，组和其他人只可读执行），所有文件设为644（所有者可读写，组和其他人只可读）。wp-config.php是皇冠上的明珠，必须600（只有所有者可读写），并且它的所有者必须是root，而不是www-data。但上面的chown命令又把它设回了www-data？没错，这是一个精妙的平衡。wp-config.php的内容（数据库密码）必须对www-data用户可读，否则 WordPress 无法连接数据库；但它的文件本身，不能让www-data用户有写权限，否则一旦 Web 服务被攻破，攻击者就能直接修改它。所以，我们用chown把它设为www-data:www-data，但用chmod 600剥夺了组和其他人的所有权限，只留下www-data用户自己能读。这是一种“最小权限原则”的实践。
第二层：禁用 XML-RPC。XML-RPC 是 WordPress 早期为移动 App 和第三方客户端提供的远程调用接口。但现在，它几乎成了暴力破解和 DDoS 放大攻击的“高速公路”。在wp-config.php文件顶部，添加：
add_filter('xmlrpc_enabled', '__return_false');或者，更彻底地，在 Nginx 配置的server块里，添加：
location ~ ^/xmlrpc\.php$ { deny all; }重启 Nginx 即可。这能瞬间关闭一个巨大的攻击面。
第三层：强制 HTTPS。即使你暂时没申请 SSL 证书，也应该为未来铺路。在 Nginx 配置中，将listen 80的server块，改为一个 301 重定向：
server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$server_name$request_uri; }然后，再新建一个listen 443 ssl http2的server块来处理 HTTPS 请求。这样，所有 HTTP 流量都会被强制跳转到 HTTPS，既安全，又为 SEO 加分。
4.2 性能调优：让 WordPress “飞”起来
一个未经优化的 WordPress 站点，就像一辆没调校过的赛车。硬件再好，也跑不出应有的速度。
PHP-FPM 进程管理调优。默认的www.conf配置是为通用场景设计的。对于一台 2 核 4G 的 VPS，我推荐这样修改：
pm = dynamic pm.max_children = 50 pm.start_servers = 10 pm.min_spare_servers = 5 pm.max_spare_servers = 15 pm.max_requests = 500pm.max_children是最大子进程数，它决定了服务器能同时处理多少个 PHP 请求。计算公式是：总内存 / 每个 PHP 进程平均内存。一个典型的 WordPress 页面，PHP 进程平均占用 30-40MB 内存。4G 内存，留出 1G 给系统和 MySQL，剩下 3G，除以 40MB，约等于 75。我们设为 50，是留出了充足的余量。pm.max_requests = 500是关键，它表示每个子进程处理完 500 个请求后就自动重启，这能有效防止内存泄漏导致的性能衰减。
Nginx 缓存配置。在server块里，添加：
# 启用 FastCGI 缓存 fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; fastcgi_cache_use_stale error timeout updating http_500 http_503; fastcgi_cache_valid 200 301 302 10m; fastcgi_cache_valid 404 1m;然后，在location ~ \.php$块里，加入：
fastcgi_cache WORDPRESS; fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache; fastcgi_cache_valid 200 301 302 10m;这相当于给 PHP 的输出结果建了一个“速食仓库”。当用户第二次访问同一个页面时，Nginx 直接从内存缓存里把 HTML 返回，完全不经过 PHP 解析和 MySQL 查询，响应时间从 300ms 降到 20ms。这是我给客户做性能报告时，最常被惊叹的一点。
WordPress 层面的轻量化。主题和插件是性能杀手。我有一个铁律：一个新站，上线前必须做到“三无”——无未启用的主题、无未启用的插件、无未使用的页面模板。在wp-content/themes和wp-content/plugins目录下，只保留一个正在用的主题和必需的插件（比如一个缓存插件、一个安全插件、一个 SEO 插件）。其他全部删除。不要想着“以后可能用得上”，它们不仅占用磁盘空间，更会在 WordPress 启动时被扫描、加载，拖慢整个系统。
4.3 日常运维：备份、更新与监控
一个健康的 WordPress 站点，离不开一套可靠的日常运维流程。
自动化备份。手动备份是不可靠的。我用一个简单的 Bash 脚本来实现每日全量备份：
#!/bin/bash DATE=$(date +%Y%m%d) BACKUP_DIR="/backup" SITE_DIR="/var/www/html/example.com" DB_NAME="wordpress_db" DB_USER="wp_user" DB_PASS="your_password" # 备份数据库 mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/db-$DATE.sql.gz # 备份网站文件 tar -czf $BACKUP_DIR/files-$DATE.tar.gz -C /var/www/html example.com # 清理 7 天前的备份 find $BACKUP_DIR -name "db-*.sql.gz" -mtime +7 -delete find $BACKUP_DIR -name "files-*.tar.gz" -mtime +7 -delete把这个脚本保存为/home/deployer/backup.sh，然后用crontab -e添加定时任务：
# 每天凌晨 2 点执行备份 0 2 * * * /home/deployer/backup.sh备份文件必须存放在与网站不同的物理位置，最好是异地对象存储（如 AWS S3、腾讯云 COS）。我见过太多次，服务器硬盘损坏，连备份文件一起丢了。
智能更新策略。WordPress 核心的小版本更新（如 6.1.1 -> 6.1.2）是安全的，可以开启自动更新。但大版本（如 6.1 -> 6.2）和主题/插件更新，必须手动操作。我的流程是：先在一个克隆的测试环境中更新，用浏览器打开所有关键页面（首页、文章页、产品页、表单页），确认功能正常、样式无错乱，再在生产环境执行。永远不要在周五下午 5 点，赶在下班前更新一个未知的商业主题。
基础监控。不需要复杂的 Zabbix 或 Prometheus。一个简单的htop命令，就能实时看到 CPU、内存、负载的使用情况。配合sudo tail -f /var/log/nginx/access.log和sudo tail -f /var/log/nginx/error.log，你可以第一时间发现异常流量（比如某个 IP 在疯狂刷/wp-login.php）或 PHP 错误（比如某个插件导致的Fatal error）。把这些日志定期归档，并用logrotate进行切割，是每个运维人员的基本功。
5. 常见问题与“踩坑”实录：那些没人告诉你的真相
5.1 “安装向导卡在最后一步，页面空白” —— 90% 是 PHP 权限问题
现象：你填完所有信息，点击“安装 WordPress”，页面就变成一片空白，或者显示500 Internal Server Error。F12 打开开发者工具，Network 标签页里，install.php这个请求的状态码是 500。
原因：几乎可以 100% 断定，是wp-config.php文件的权限或所有权出了问题。最常见的错误是，你在nano里编辑完wp-config.php后，直接Ctrl+X退出，而没有用sudo权限保存。结果，这个文件的所有者变成了你当前的用户（比如deployer），而www-data用户没有读取权限。
解决方案：立刻执行sudo chmod 600 /var/www/html/example.com/wp-config.php && sudo chown www-data:www-data /var/www/html/example.com/wp-config.php。然后，清空浏览器缓存，重新访问安装页面。如果还是不行，去 Nginx 的错误日志里找线索：sudo tail -f /var/log/nginx/error.log，里面通常会有一行PHP message: PHP Fatal error: require(): Failed opening required ...，这说明 PHP 找不到某个核心文件，大概率是wp-includes或wp-admin目录的权限不对，用sudo chmod -R 755 /var/www/html/example.com/wp-includes和sudo chmod -R 755 /var/www/html/example.com/wp-admin修复。
实操心得：我给自己立下一条铁律——所有位于
/var/www/html/目录下的文件和文件夹，其所有者必须是www-data，权限必须是755（目录）或644（文件），除了wp-config.php这个特例。这条规则，帮我避开了 95% 的“白屏”问题。
5.2 “后台上传图片失败，提示‘上传的文件类型不被允许’” —— MIME 类型校验惹的祸
现象：在 WordPress 后台，点击“媒体 > 添加新文件”，选择一张 JPG 图片，点击上传，却弹出红色错误：“上传的文件类型不被允许。”
原因：这不是 WordPress 的错，而是 Nginx 的锅。Nginx 有一个client_max_body_size指令，默认值是 1MB。如果你试图上传一个 2MB 的高清图片，Nginx 在请求到达 PHP 之前，就已经把它拦下了，并返回一个413 Request Entity Too Large错误。而 WordPress 的错误提示，只是对这个底层错误的一个“友好包装”。
解决方案：编辑 Nginx 的主配置文件sudo nano /etc/nginx/nginx.conf，在http块里，添加一行：
client_max_body_size 64M;然后，重启 Nginx：sudo systemctl restart nginx。64M 是一个比较宽松的值，足以应付绝大多数图片、PDF 和视频上传需求。如果你的业务有特殊要求，可以按需调整。
注意：这个值必须同时在 Nginx 和 PHP 里设置。PHP 也有一个
upload_max_filesize和post_max_size，它们在/etc/php/7.0/fpm/php.ini文件里。确保它们的值不小于 Nginx 的client_max_body_size，否则 PHP 层会再次拦截。
5.3 “网站打开很慢，但服务器资源占用很低” —— DNS 查询是隐形杀手
现象：你用htop看着，CPU 和内存都空空如也，但用浏览器打开网站，首屏加载要 5 秒以上。用curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" http://example.com测试，发现time_connect时间很长（比如 2 秒）。
原因：time_connect衡量的是建立 TCP 连接的时间，它包含了 DNS 解析。如果服务器的 DNS 解析服务器（/etc/resolv.conf里配置的）响应很慢，或者根本不可达，那么每次 PHP 脚本里执行一个file_get_contents()或cURL请求（比如调用天气 API、微信 JS-SDK 签名），都会在这里卡住。
解决方案：更换一个快速、可靠的 DNS 服务器。编辑
