1. 项目概述为什么在 Ubuntu 12.04 上用 nginx 部署 WordPress 仍值得深挖你点开这个标题大概率不是为了怀旧——没人会主动选一个 2012 年发布的、2017 年就终止标准支持的 Ubuntu 12.04 系统来搭新站。但现实很具体我去年接手的三套老系统里有两套跑着金融行业内部文档平台数据库是 MySQL 5.5PHP 是 5.3.10内核是 3.2.0-23-generic所有补丁都打到最后一刻但就是不能升还有一套是某高校实验室的嵌入式教学演示环境整套镜像固化在 ARM 开发板 SD 卡里重刷等于重写实验手册。它们共同的关键词是稳定压倒一切变更必须零风险而 nginx WordPress 在这个组合里是唯一被反复验证过十年不崩的轻量栈。这不是教你怎么“装个 WordPress”而是带你回到那个还没有 Docker、没有一键脚本、没有宝塔面板的时代亲手把 nginx 的 worker 进程绑进 CPU 亲和性把 PHP-FPM 的静态子进程数算到小数点后一位把 WordPress 的 .htaccess 伪静态逻辑一比一翻译成 nginx 的 location rewrite 规则。Ubuntu 12.04 的 apt 源早已归档官方镜像站只保留 security 和 updates 两个通道这意味着你不能apt-get install nginx-full就完事——你得确认nginx-light是否带http_rewrite_module得手动编译pcre库避免正则崩溃得把php5-fpm的 socket 权限从/var/run/php5-fpm.sock改到/tmp/php5-fpm.sock才能绕过 AppArmor 对/var/run的严格限制。这些细节现在搜“WordPress 安装教程”根本不会提因为主流教程默认你用的是 Ubuntu 22.04 或 CentOS Stream但恰恰是这些被时代甩下的细节决定了老系统能不能多撑三年、会不会在某个凌晨三点因一次日志轮转而 silently crash。我实测过 12.04 上的三种部署路径直接 apt 安装最快但模块缺失、源码编译 nginx最稳但耗时、用 dotdeb.org 的第三方源折中但需校验 GPG 密钥。最终上线的那套金融文档系统选择的是第三种——不是因为它最先进而是因为它的nginx-extras包里预编译好了http_geoip_module而我们恰好要用 IP 归属地做访问白名单。这种“功能倒逼选型”的决策逻辑在现代云原生环境里几乎消失但在存量系统运维中它每天都在发生。所以这篇内容的核心价值不在于教你复刻一个过时环境而在于训练一种能力当技术栈被锁定、当升级路径被堵死、当你只能在螺丝钉大小的缝隙里做文章时如何用最原始的工具链打出最可靠的组合拳。它适合三类人还在维护政企老旧系统的运维工程师、需要复现 CVE 漏洞环境的安全研究员、以及想真正理解 Web 服务底层耦合关系的开发者——因为只有亲手把fastcgi_pass指向一个不存在的 socket 文件并看它报什么错你才会明白“502 Bad Gateway”背后到底是哪一层在掉链子。2. 整体架构设计与方案选型逻辑2.1 为什么坚持用 nginx 而非 Apache很多人看到 Ubuntu 12.04 就默认上 Apache2毕竟apt-get install apache2一行命令搞定.htaccess也天然支持。但我在金融文档系统上线前做了三组压力测试用ab -n 1000 -c 50模拟并发请求分别压测 Apache2prefork MPM和 nginxevent MPM结果很反直觉——Apache2 在 50 并发下平均响应时间 186ms内存占用 42MBnginx 同配置下响应时间 93ms内存仅 14MB。差距不是一倍而是三倍。原因在于 12.04 的内核调度机制对 Apache 的 prefork 模型极度不友好每个请求独占一个进程进程创建销毁开销大而 nginx 的 event loop 在单线程内处理数千连接对老旧硬件的 CPU 缓存更友好。更关键的是安全隔离。Apache2 默认以www-data用户运行整个服务而 WordPress 插件常需写入wp-content目录一旦插件存在任意文件写入漏洞攻击者就能直接拿到www-data权限执行系统命令。nginx 则不同——它本身不解析 PHP只把请求转发给独立的php5-fpm进程池而php5-fpm可以配置为以wordpress用户运行这样即使 PHP 层被攻破攻击者也无法读取/etc/shadow或写入/var/log/。我在某次渗透测试中复现过这个场景用公开的 WordPress 插件 RCE 漏洞上传 webshellApache 环境下 shell 能直接执行cat /etc/passwd而 nginx php5-fpm非 www-data 用户环境下cat命令返回 Permission denied。这个差异在等保二级测评里就是“高危项”和“中危项”的分水岭。2.2 为什么拒绝 Nginx 官方源坚持用 DotdebUbuntu 12.04 官方源里的nginx-light包体积仅 380KB但它阉割了http_ssl_module、http_gzip_static_module和最关键的http_rewrite_module。而 WordPress 的固定链接Permalink功能依赖 rewrite 模块将/2024/06/post-name/这类 URL 重写为index.php?year2024monthnum06namepost-name。没有 rewrite你只能用?p123这种丑陋的 ID 链接SEO 直接归零。有人建议自己编译 nginx但 12.04 的gcc版本是 4.6.3编译新版 nginx 会报error: ‘__sync_fetch_and_add_4’ was not declared in this scope必须降级 pcre 到 8.21而 pcre 8.21 又存在正则回溯 DOS 漏洞CVE-2015-2325。Dotdeb 的解决方案是提供预编译的nginx-extras包它基于 nginx 1.4.612.04 兼容性最佳版本内置所有模块且已打过 pcre 补丁。我对比过 Dotdeb 的nginx-extras和自己编译的版本前者启动时间 0.12s后者 0.38s因为 Dotdeb 关闭了调试符号并启用了-O2优化。在资源紧张的老服务器上这 0.26 秒就是多承载 12 个并发用户的物理极限。2.3 PHP-FPM 的进程管理策略静态模式才是 12.04 的最优解12.04 的php5-fpm默认配置是dynamic模式pm.max_children 5pm.start_servers 2pm.min_spare_servers 1pm.max_spare_servers 3。这套参数在现代 SSD 服务器上没问题但在 12.04 常见的 SATA 机械盘 2GB 内存机器上会导致频繁的 fork() 和 kill() 进程震荡。我用vmstat 1监控过每分钟有 17 次fork()调用每次 fork() 需要复制整个 PHP 进程内存页而 12.04 的copy-on-write机制在低内存下效率极低导致siswap-in值飙升到 120KB/s。换成static模式后pm staticpm.max_children 8pm.max_requests 500。8 这个数字怎么来的计算公式是可用内存 × 0.7 ÷ 单个 PHP 进程平均内存。用ps aux --sort-%mem | head -5查到php5-fpm进程平均占 28MB2GB 内存 × 0.7 1400MB1400 ÷ 28 50但实际不能这么激进——因为还要留 512MB 给 MySQL 和系统缓存所以最终定为 8。pm.max_requests 500是防内存泄漏的关键WordPress 插件常有未释放的全局变量跑满 500 次请求后自动重启子进程比等 OOM killer 杀进程优雅得多。3. 核心组件安装与配置详解3.1 Ubuntu 12.04 环境初始化绕过已失效的源和证书陷阱Ubuntu 12.04 的默认源archive.ubuntu.com在 2017 年后已重定向到old-releases.ubuntu.com但很多教程没更新直接apt-get update会卡在Waiting for headers。正确做法是先备份原源列表sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup然后用 sed 一键替换所有源地址sudo sed -i s/archive.ubuntu.com/old-releases.ubuntu.com/g /etc/apt/sources.list sudo sed -i s/security.ubuntu.com/old-releases.ubuntu.com/g /etc/apt/sources.list但光换域名还不够——12.04 的ca-certificates包太老无法验证 HTTPS 证书。比如https://dotdeb.org的证书链用的是 SHA-256而 12.04 默认只信任 SHA-1。解决方法是手动下载并安装新版证书包wget http://archive.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.12.04.1_all.deb sudo dpkg -i ca-certificates_20160104ubuntu0.12.04.1_all.deb sudo update-ca-certificates这步做完apt-get update才能真正成功。我见过太多人卡在这里三天最后重装系统——其实只是证书过期这个“看不见的墙”在作祟。3.2 Dotdeb 源的添加与 GPG 密钥验证安全与可用的平衡Dotdeb 的 GPG 密钥在 2020 年已过期但它的软件包签名依然有效。直接apt-key add会报gpg: WARNING: This key has expired!导致apt-get update失败。正确姿势是强制信任该密钥wget https://www.dotdeb.org/dotdeb.gpg sudo apt-key add dotdeb.gpg # 强制标记密钥为有效 sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 89DF5277 sudo apt-key adv --edit-key 89DF5277 trust EOF 5 EOF然后添加源echo deb http://packages.dotdeb.org precise all | sudo tee /etc/apt/sources.list.d/dotdeb.list echo deb-src http://packages.dotdeb.org precise all | sudo tee -a /etc/apt/sources.list.d/dotdeb.list注意precise是 Ubuntu 12.04 的代号千万别写成trusty14.04或xenial16.04否则 apt 会报404 Not Found。添加完后apt-get update你会看到 dotdeb 的包出现在列表里。这里有个经验不要apt-get upgrade全局升级因为 dotdeb 的mysql-server-5.5会覆盖 Ubuntu 自带的mysql-client-core-5.5导致mysql命令失效。应该只安装明确需要的包sudo apt-get install nginx-extras php5-fpm php5-mysql php5-curl php5-gd php5-intl php5-mcrypt php5-xmlrpc3.3 nginx 配置文件深度解析从默认站点到 WordPress 专用规则Ubuntu 12.04 的 nginx 默认配置在/etc/nginx/sites-available/default但直接改它风险太大。最佳实践是新建一个独立配置文件sudo nano /etc/nginx/sites-available/wordpress-site核心配置如下逐行解释server { listen 80; server_name example.com; # 必须填你的域名不能用 localhost root /var/www/wordpress; # WordPress 根目录 index index.php; # 关键禁止访问敏感文件 location ~ /\. { deny all; } location ~ ^/(wp-config\.php|readme\.html|license\.txt) { deny all; } # WordPress 伪静态规则把 /post-name/ 重写为 index.php location / { try_files $uri $uri/ /index.php?$args; } # PHP 处理必须用 unix socket比 TCP 更快且绕过防火墙 location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/var/run/php5-fpm.sock; # 注意路径12.04 默认是这个 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; } # 静态文件缓存浏览器缓存 1 年减少服务器压力 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control public, immutable; } }重点讲三个易错点fastcgi_pass必须用unix:/var/run/php5-fpm.sock不能写127.0.0.1:9000。因为 12.04 的 AppArmor 配置默认禁止 nginx 访问网络端口但允许访问/var/run/下的 socket。try_files $uri $uri/ /index.php?$args中的$args不能省略否则 WordPress 的搜索功能?skeyword会失效。add_header Cache-Control这行必须加否则某些老旧手机浏览器如 Android 4.4 的 WebView会反复请求 CSS导致页面闪烁。启用配置sudo ln -sf /etc/nginx/sites-available/wordpress-site /etc/nginx/sites-enabled/wordpress-site sudo rm /etc/nginx/sites-enabled/default sudo service nginx reload提示service nginx reload比restart更安全它会检查配置语法再平滑切换避免因配置错误导致服务中断。用nginx -t可手动验证输出syntax is ok且test is successful才算通过。3.4 PHP-FPM 用户与权限精细化控制安全边界的最后一道门默认的php5-fpm配置以www-data用户运行这是最大安全隐患。必须为 WordPress 创建独立用户sudo adduser --disabled-password --gecos wordpress sudo usermod -a -G www-data wordpress然后编辑/etc/php5/fpm/pool.d/www.conf; 注释掉默认的 user/group ; user www-data ; group www-data ; 改为 wordpress 用户 user wordpress group wordpress ; socket 文件权限必须匹配 nginx 用户 listen.owner www-data listen.group www-data listen.mode 0660 ; 关键设置进程工作目录防止跨目录访问 chdir /var/www/wordpress重启服务sudo service php5-fpm restart sudo service nginx restart验证是否生效ps aux | grep php5-fpm应该显示wordpress用户而不是www-data。再检查 socket 权限ls -l /var/run/php5-fpm.sock输出应为srw-rw---- 1 www-data www-data。如果权限不对WordPress 会报502 Bad Gateway因为 nginx 无法向 socket 写入请求。4. WordPress 核心部署与生产级调优4.1 WordPress 安装包获取与完整性校验拒绝“来路不明”的 zip别用wget https://wordpress.org/latest.tar.gz——这个链接在 12.04 的wget版本1.13.4下会因 TLS 协议不兼容而失败。正确方式是下载特定版本的 tarball并用 GPG 校验# 下载 WordPress 4.9.22最后一个完全支持 PHP 5.3 的版本 wget https://wordpress.org/wordpress-4.9.22.tar.gz wget https://wordpress.org/wordpress-4.9.22.tar.gz.md5 wget https://wordpress.org/wordpress-4.9.22.tar.gz.asc # 校验 MD5 md5sum -c wordpress-4.9.22.tar.gz.md5 # 导入 WordPress GPG 密钥需提前安装 gnupg gpg --import wordpress-pubkey.asc gpg --verify wordpress-4.9.22.tar.gz.asc wordpress-4.9.22.tar.gz解压后必须修改wp-config.php的数据库连接方式。12.04 的 MySQL 5.5 不支持mysqli的长连接所以DB_HOST不能写localhost它会走 socket必须写127.0.0.1强制走 TCPdefine(DB_HOST, 127.0.0.1:3306); define(DB_USER, wordpress); define(DB_PASSWORD, your_strong_password); define(DB_NAME, wordpress_db);注意DB_PASSWORD一定要用强密码12.04 的mysql_secure_installation脚本不完善容易漏掉匿名用户。手动清理mysql -u root -p -e DELETE FROM mysql.user WHERE User; FLUSH PRIVILEGES;4.2 WordPress 固定链接Permalink的 nginx 实现原理WordPress 后台设置固定链接为/year/month/day/postname/后Apache 用.htaccess的RewriteRule实现而 nginx 必须手动写location。很多人照抄网上的规则却失败原因是没理解try_files的执行顺序。正确逻辑是先查$uri是否对应真实文件如/wp-content/themes/twentytwenty/style.css再查$uri/是否对应真实目录如/wp-admin/都不命中则交给/index.php?$args处理所以location /块必须放在location ~ \.php$之前否则.php文件会被优先匹配导致index.php本身也被重写形成无限循环。我在某次部署中就因此触发了 nginx 的rewrite or internal redirection cycle错误日志里全是*1122348 rewrite or internal redirection cycle while internally redirecting to /index.php。解决方法是在location /里加一个显式排除location / { try_files $uri $uri/ wordpress; } location wordpress { fastcgi_pass unix:/var/run/php5-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/index.php; }这样就把重写逻辑和 PHP 执行彻底分离万无一失。4.3 生产环境必备的 WordPress 配置加固在wp-config.php末尾追加以下加固代码非插件纯配置// 禁用文件编辑功能防止后台被黑后直接改主题 define(DISALLOW_FILE_EDIT, true); // 设置自动更新为仅核心小版本12.04 的 PHP 不支持大版本更新 define(WP_AUTO_UPDATE_CORE, minor); // 数据库错误不显示在前端避免泄露表结构 define(WP_DEBUG, false); define(WP_DEBUG_DISPLAY, false); define(WP_DEBUG_LOG, true); // 日志写入 wp-content/debug.log // 设置 Cookie 安全标志即使没 HTTPS 也要加 define(COOKIE_DOMAIN, example.com); define(COOKIEPATH, /); define(SITECOOKIEPATH, /); define(ADMIN_COOKIE_PATH, /wp-admin/); define(PLUGINS_COOKIE_PATH, /wp-content/plugins/); define(COOKIEHASH, md5(example.com)); // 关键禁用 XML-RPC12.04 的 WordPress 4.9.22 的 xmlrpc.php 是 DDoS 攻击入口 add_filter(xmlrpc_enabled, __return_false);最后一条add_filter必须加——2016 年的 WordPress XML-RPC 暴力破解攻击system.multicall在 12.04 环境下尤其致命因为它的max_connections默认值是 100而攻击脚本能瞬间发起 500 并发直接拖垮 MySQL。加了这行/xmlrpc.php返回 403攻击流量自然消散。5. 常见问题排查与独家避坑指南5.1 “502 Bad Gateway” 的七层排查法这是 12.04 nginx WordPress 环境下最高频的错误。我整理了一张速查表按发生概率从高到低排序排查层级检查命令正常输出异常表现解决方案1. PHP-FPM 进程是否存活sudo service php5-fpm statusphp5-fpm start/running, process 1234php5-fpm stop/waitingsudo service php5-fpm start2. Socket 文件是否存在ls -l /var/run/php5-fpm.socksrw-rw---- 1 www-data www-dataNo such file or directorysudo service php5-fpm restart3. Socket 权限是否正确ls -l /var/run/php5-fpm.socksrw-rw---- 1 www-data www-datasrw-rw---- 1 root root修改/etc/php5/fpm/pool.d/www.conf的listen.owner/group4. nginx 配置语法是否正确sudo nginx -tsyntax is ok,test is successfulunknown directive fastcgi_pass检查location ~ \.php$块是否在http块内且未被注释5. WordPress 目录权限是否正确ls -ld /var/www/wordpressdrwxr-xr-x 5 wordpress www-datadrwx------ 5 root rootsudo chown -R wordpress:www-data /var/www/wordpress6. MySQL 是否可连接mysql -u wordpress -p -h 127.0.0.1 wordpress_dbWelcome to the MySQL monitorCant connect to MySQL server检查bind-address 127.0.0.1是否在/etc/mysql/my.cnf中7. AppArmor 是否拦截sudo aa-status | grep nginxnginx (enforce)nginx (complain)sudo aa-disable /usr/sbin/nginx临时或修改/etc/apparmor.d/usr.sbin.nginx实操心得我遇到过最诡异的一次 502是php5-fpm进程明明在运行socket 文件也存在但curl -I http://127.0.0.1一直超时。最后发现是/etc/apparmor.d/usr.sbin.php5-fpm里有一行deny /proc/*/status r,被错误启用导致 PHP-FPM 无法读取自身状态自动退出。删掉这行sudo service apparmor reload问题立解。这种问题官方文档绝不会写只有在/var/log/syslog里翻apparmorDENIED才能找到线索。5.2 WordPress 后台“无法建立到 WordPress.org 的连接”终极修复12.04 的curl版本太老7.22.0无法验证 WordPress.org 的 HTTPS 证书。后台更新插件时总提示“无法连接”但ping api.wordpress.org是通的。根本原因是curl缺少 SNIServer Name Indication支持而 WordPress.org 的 CDN 要求 SNI。解决方案是强制 WordPress 用fsockopen替代curl在wp-config.php加// 强制 WordPress 用 fsockopen兼容 12.04 if (!defined(ALTERNATE_WP_CRON)) define(ALTERNATE_WP_CRON, true); if (!defined(WP_HTTP_BLOCK_EXTERNAL)) define(WP_HTTP_BLOCK_EXTERNAL, false); if (!defined(WP_ACCESSIBLE_HOSTS)) define(WP_ACCESSIBLE_HOSTS, api.wordpress.org,downloads.wordpress.org);然后在wp-includes/class-http.php的request()方法开头加// 强制使用 fsockopen12.04 兼容 if (extension_loaded(openssl) version_compare(PHP_VERSION, 5.6.0, )) { $args[sslverify] false; // 老版 OpenSSL 不验证证书 }注意sslverify false只影响 WordPress 自身的 HTTP 请求不影响前台用户访问所以安全风险可控。这是在“可用”和“绝对安全”之间做的务实妥协。5.3 nginx 日志分析实战从 access.log 挖掘真实攻击行为12.04 的默认 nginx 日志格式太简陋log_format combined只记录$remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent但攻击者常伪造User-Agent或用代理 IP。必须自定义日志格式在/etc/nginx/nginx.conf的http块里加log_format custom $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $request_time $upstream_response_time $pipe;然后在server块里用access_log /var/log/nginx/wordpress-access.log custom;重启 nginx 后用以下命令分析日志# 查找 5 分钟内同一 IP 的 POST 请求超过 10 次疑似暴力破解 awk $6\POST\ {ip[$1]} END {for (i in ip) if (ip[i]10) print i, ip[i]} /var/log/nginx/wordpress-access.log # 查找访问 xmlrpc.php 的异常 UA如 python-requests grep xmlrpc.php /var/log/nginx/wordpress-access.log | grep -i python\|curl\|wget # 查找 404 页面中的可疑路径如 /wp-admin/admin-ajax.php?actionxxx awk $9404 {print $7} /var/log/nginx/wordpress-access.log | sort | uniq -c | sort -nr | head -10我用这套方法在金融系统里抓到过一个持续 3 个月的扫描器它每天凌晨 2 点用sqlmap的 UA 访问/wp-content/plugins/xxx/readme.txt试图枚举插件版本。加了location ~ /wp-content/plugins/.*/readme\.txt { return 403; }后扫描流量直接归零。6. 性能压测与长期稳定性验证6.1 使用 abApacheBench进行基准测试12.04 的真实承载力ab是 12.04 自带的压测工具无需额外安装。但默认参数会误导你——ab -n 1000 -c 100测试时如果服务器响应慢ab会堆积大量连接导致结果失真。必须加-k启用 Keep-Alive和-H模拟真实 UAab -n 5000 -c 100 -k -H User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 http://example.com/关键指标解读Time per request平均响应时间低于 200ms 为优秀300~500ms 为可接受超过 800ms 需优化Requests per secondQPS12.04 nginx PHP5-FPM 的理论极限是 120 QPS2GB 内存 SATA 硬盘Failed requests必须为 0否则说明有资源瓶颈如 MySQL 连接数超限我实测过当max_children 8时QPS 稳定在 112Time per request189ms当max_children 12时QPS 降到 98Time per request升到 320ms因为内存交换开始频繁。这证明 8 是 2GB 内存下的黄金值。6.2 长期运行监控用 sysstat 抓取 7×24 小时资源曲线12.04 自带sysstat但默认不启用。启用后它每 10 分钟记录一次 CPU、内存、IO 数据sudo apt-get install sysstat sudo sed -i s/ENABLEDfalse/ENABLEDtrue/g /etc/default/sysstat sudo service sysstat restart数据存于/var/log/sysstat/用sar查看# 查看昨天的 CPU 使用率 sar -u -f /var/log/sysstat/sa$(date -d yesterday %d) # 查看过去一小时的内存使用单位 MB sar -r -s $(date -d 1 hour ago %H:%M:%S) -e $(date %H:%M:%S) # 查看磁盘 IO 等待时间iowait 20% 说明硬盘是瓶颈 sar -q -f /var/log/sysstat/sa$(date %d)我曾用这个方法发现一个隐藏问题某天凌晨 3 点iowait突然飙升到 45%但top显示 MySQL 进程 CPU 占用只有 5%。深入查iotop发现是rsyslogd在疯狂写/var/log/kern.log因为某个内核模块日志级别设成了 debug。关掉 debugiowait回归正常。这种问题不靠长期监控根本发现不了。6.3 WordPress 插件兼容性黑名单哪些插件在 12.04 上必然崩溃不是所有 WordPress 插件都适配 PHP 5.3 和 MySQL 5.5。我整理了一份 12.04 环境下的插件黑名单附原因插件名称崩溃原因替代方案WP Super Cache依赖file_put_contents()的FILE_APPEND标志PHP 5.3.10 有 bug 导致缓存文件写入失败改用W3 Total Cache其 0.9.2.4 版本专为 PHP 5.3 优化Yoast SEO4.0 版本要求 PHP 5.6用??空合并操作符降级到Yoast SEO 3.7.4最后一个支持 PHP 5.3 的版本Wordfence Security7.0 版本用password_hash()函数PHP 5.3 不支持改用iThemes Security其 4.0.22 版本兼容 PHP 5.3Jetpack依赖 WordPress REST API而 12.04 的 WordPress 4.9.22 的 REST API 有 CORS 问题完全禁用用wp-cli手动同步统计实操心得插件更新前务必在测试环境wp-cli plugin update --dry-run检查依赖。我吃过一次亏某次wp plugin update --all后wp-cron.php报Fatal error: Call to undefined function password_hash()整个后台瘫痪。恢复方法是 FTP 进入wp-content/plugins/重命名出问题的插件文件夹再用wp plugin activate逐个启用测试。7. 安全加固与应急响应预案7.1 防止 WordPress 被植入后门的三道防线“120 万 WordPress 站点被植入后门”事件中90% 的受害者是因弱口令 未禁用 XML-RPC。针对 12.04 环境我部署了三层防护第一道Web 层过滤nginx在server块里加# 禁止访问 .php 文件以外的可执行脚本 location ~ \.(php|php5|phtml|pl|py