使用 Cloudflare WAF 自定义规则，构建 WordPress 防火墙：拦截非法 PHP 请求，告别 CPU 飙升！

首页

WordPress,高级优化

今天我们来聊聊一个让所有 WordPress 站长头疼的“隐形杀手”：恶意扫描机器人。

如果你像我一样，使用 VPS + 宝塔面板自建 WordPress 站点，一定遇到过网站突然卡顿、CPU 瞬间飙升到 100% 的情况，整个服务器仿佛被“榨干”了一样，网站访问都打不开。别慌，这并非是你的网站流量太大，而是大量的非法请求和恶意扫描机器人搞的鬼。

今天，我将带你一步步用 Cloudflare 的 WAF（Web Application Firewall）自定义规则来筑起一道坚不可摧的“防火墙”，免费且高效地在源头拦截这些非法请求，彻底保护服务器资源，显著提升网站的安全性和访问速度。

问题根源：日志中的“隐形杀手”

恶意扫描是网站安全中最常见但最容易被忽视的问题。恶意机器人会持续不断地扫描您的网站，尝试访问各种不存在的、或常见的漏洞脚本文件路径。

想象一下，您的网站日志在深夜突然涌现大量记录：一个 IP（例如172.70.222.233 的机器人）在短短几分钟内，疯狂发起数百次对诸如/nonexistent.php 、/admin.php、/testscript.php 等路径的请求。

日志示例：

这些请求看似都返回了 404，但对于低配 VPS 来说，每一笔请求、每一次 404 错误处理，都在消耗 CPU、内存和磁盘 I/O。海量请求的堆积，足以瞬间将服务器性能压垮，导致正常用户无法访问。

这种扫描行为的危害不容小觑：

消耗服务器资源 (DDoS-like)： 这是一种低烈度的资源消耗攻击。它抢占了本应用于服务真实用户的带宽和计算能力，是导致 CPU 飙升到 100% 的直接原因。
探测已知漏洞： 扫描脚本通过尝试访问常见的脚本路径（如插件或主题的已知漏洞文件），旨在“摸底”您的站点，一旦发现可利用的弱点，后续将可能发起 SQL 注入、XSS 或文件上传等深度攻击。
产生垃圾日志： 大量的 404 错误日志会堆积如山，淹没正常的访问记录，给日常的日志分析、故障排查带来巨大的困难。

核心解决思路：Cloudflare WAF，源头拦截

如果您已经在使用 Cloudflare（免费套餐即拥有此功能），那么解决这个问题的关键就在于利用它的 WAF（Web Application Firewall）自定义规则。

Cloudflare WAF 允许我们设置复杂的规则来判断一个请求是否恶意。

执行位置： 规则在 Cloudflare 的边缘网络执行，位于请求和您的源服务器之间。
拦截效果： 当请求触发我们设定的恶意规则时，Cloudflare 会直接返回一个拦截页面（如 403 错误或自定义验证码），请求永远不会到达您的 VPS 服务器。

这从根本上解决了资源消耗问题，让您的 VPS 服务器可以“高枕无忧”，专注于服务正常用户。

Cloudflare 拦截示意：

恶意请求 → [ Cloudflare WAF ] → [ 规则触发：阻止 ] → [ 客户端看到拦截页 ] → （请求未到达源服务器）

实战教程：一步步创建自定义安全规则

整个过程不到 5 分钟，且无需触碰服务器代码。

步骤 1：进入 WAF 自定义规则设置页面

登录您的 Cloudflare 仪表板（dash.cloudflare.com），选择需要保护的域名。
在左侧导航栏中，依次进入安全性 > 安全规则。
点击创建规则，选择自定义规则。

2：配置规则名称、表达式与操作（灵魂所在）

配置规则是核心步骤。我们的目标是：拦截所有访问 PHP 文件的请求，但排除 WordPress 系统本身需要使用的合法核心路径。

规则名称：输入一个清晰易懂的名称，例如：“拦截 WordPress 非法 PHP 访问”。

规则表达式：

点击 “编辑表达式”，然后将以下代码复制粘贴到编辑框中。这是 Cloudflare 表达式语言的精髓：

(http.request.uri.path contains ".php" and not http.request.uri.path contains "/wp-admin/" and not http.request.uri.path contains "/wp-includes/" and not http.request.uri.path contains "/wp-content/" and not http.request.uri.path contains "/index.php" and not http.request.uri.path contains "/wp-login.php" and not http.request.uri.path contains "/wp-cron.php" and not http.request.uri.path contains "/xmlrpc.php")

【表达式详细解析】

(http.request.uri.path contains ".php")：这是拦截的前提，它匹配所有请求路径中包含.php字符串的请求（这也是恶意扫描的主要目标）。
and not (...)：这是排除项。我们要确保 WordPress 正常运行所必需的合法路径被放行。
排除目录：（后台）、（核心库）、（主题/插件/上传文件）。/wp-admin//wp-includes//wp-content/
排除核心文件：、、、（这些是 WP 正常的入口文件）。/index.php/wp-login.php/wp-cron.php/xmlrpc.php

采取措施：在下方的“然后采取措施…”中，选择 “阻止”。

（可选：您可以选择其他操作，如 “质询” ，要求机器人进行人机验证。）

部署：最后，点击 “部署”。规则将即时生效！

高级配置提示

自定义 PHP 文件： 如果您的主题或插件使用了自定义的 PHP 文件（例如：在主题根目录有一个/custom-api.php ），您需要将它添加到排除列表，例如： ... or http.request.uri.path in {"/index.php" "/wp-login.php" "/custom-api.php"}
规则优先级： 确保这条规则的优先级高于任何允许流量通过的规则（拖动规则列表，将它放在顶部）。

效果验证：确保网站“无误伤”

规则上线后，请务必进行以下测试，确保安全规则既拦截了恶意请求，又没有误伤正常访问。

正常访问测试： 用浏览器访问您的网站首页、文章页面，并尝试登录 WordPress 后台。确保所有功能和页面均能正常打开，没有出现拦截页面。
非法请求测试： 手动尝试访问一个不存在的 PHP 路径，例如：websitesoez.com/fake-script-123.php
- 如果配置成功，浏览器将显示 Cloudflare 的拦截页面（例如 403 错误或您设置的自定义验证提示），而不是您服务器返回的 404 页面。
服务器日志观察： 检查您的 VPS 服务器日志（如 Nginx/Apache 日志），确认那些频繁的非法 PHP 扫描请求已经消失，CPU 负载保持平稳。