如果你是自己维护 WordPress 的站长，最近大概率遇到过这种情况：服务器监控突然报警，CPU 跑满，数据库连接数飙升，网站前台打开转圈圈，甚至直接 502。你查遍插件、换过主题、升级了服务器配置，问题依旧隔三差五出现。
笔者自己经手的几个站点也遭遇过类似攻击，最后排查下来，罪魁祸首往往不是网站本身有什么漏洞，而是 WordPress 两个默认开启、年纪比很多站长做站时间还长的功能——XML-RPC 和 Pingback。它们本身是正经功能，但被黑客盯上后，就成了免费的 DDoS 打手。这篇文章，站长就把自己踩过的坑和最终落地的解决方案完整分享出来。
先搞清楚：这两个功能到底是干嘛的？
💡 推荐阅读：别再瞎折腾端口映射了！聊聊 Docker 容器间内网互通的正确打开方式
很多新手站长一听到“XML-RPC”和“Pingback”就头大，其实用大白话解释就明白了。
- XML-RPC：这是 WordPress 早期提供的一套远程调用接口。以前你用手机 App 发文章、用桌面软件管理博客，靠的就是它。但现在古腾堡编辑器、官方 App 早就换了通信方式，XML-RPC 对绝大多数站点来说已经是“僵尸功能”——开着没用，关了不影响。
- Pingback：当你文章里链接了别人的博客，WordPress 会自动发一个“通知”过去，告诉对方“我引用你啦”。对方收到通知后，会在自己文章的评论区显示一条引用记录。听起来很美好，但实际早就被垃圾评论和攻击者玩坏了。
问题在于，这两个功能默认都是开启的，而且不需要登录就能调用。攻击者只需要一个脚本，就能让你的服务器替他们干活。
高频疑问集中解答：你是不是也遇到过这些报错？
💡 延伸阅读：别再把防火墙当摆设了：从80/443到业务端口，聊聊我踩过的UFW配置坑
Q1：服务器 CPU 莫名 100%，日志里全是 wp-cron.php 和 xmlrpc.php 的请求，怎么回事？
这是最典型的 XML-RPC 被滥用场景。攻击者利用 system.multicall 方法，把成百上千次登录尝试打包成一个 HTTP 请求发给你的 xmlrpc.php。你的服务器以为只处理了一个请求，实际上在后台执行了上千次密码验证，CPU 瞬间被榨干。更狠的是，攻击者还会利用 Pingback 功能，让你的网站去请求别人的服务器，形成反射放大攻击——你的 IP 就这样成了“帮凶”。
Q2：我在 functions.php 里加了禁用代码，为什么 xmlrpc.php 还能访问？
这个问题笔者自己也踩过。很多教程只告诉你加 add_filter('xmlrpc_enabled', '__return_false');，但这行代码只是禁用了 XML-RPC 的认证功能，文件本身仍然可以被访问，攻击者依然能通过 Pingback 接口发起请求。要彻底解决，必须从 Web 服务器层面直接拦截 xmlrpc.php 的访问。
Q3：禁用 Pingback 后，我文章里的站外链接会不会受影响？
完全不会。禁用 Pingback 只是不再发送和接收引用通知，你文章里的超链接照常显示、照常跳转，读者体验没有任何变化。唯一的变化是：别人再也无法通过 Pingback 在你文章下面留垃圾引用评论了。对绝大多数站长来说，这是纯赚。
Q4：用了 Cloudflare 之类的 CDN，还需要在服务器上禁用吗？
需要，而且非常必要。CDN 只能过滤一部分恶意流量，但攻击者完全可以绕过 CDN 直接请求你的源站 IP。笔者建议的做法是：CDN 规则 + 服务器配置 + WordPress 层面三重防护，缺一不可。
根因剖析：为什么这两个功能会成为 DDoS 帮凶？
💡 深度技术指南：别再用那些老掉牙的教程了：Nginx 反代 + 免费证书自动续签，我踩过的坑都在这了
说到底，XML-RPC 和 Pingback 的设计年代太早了。那时候互联网还很单纯，没人想到会有人拿它来搞攻击。具体来说，有三个致命问题：
- 无需认证即可调用：Pingback 接口对所有人开放，攻击者可以伪造源 IP，让你的服务器向目标发起请求。
- 请求放大效应：一个 XML-RPC 请求可以触发数百次内部操作，攻击成本极低，防守成本极高。
- 默认开启且隐藏深：很多站长根本不知道这两个功能存在，更别提去关闭了。
笔者见过最夸张的案例，一个日 IP 不到 500 的小博客，被 XML-RPC 攻击打到服务器商直接发邮件警告。所以这件事，跟你网站大小无关，只要用 WordPress 就得防。
实操方案：三步彻底禁用 XML-RPC 与 Pingback
下面这套方案是笔者在多个生产环境验证过的，从服务器层到应用层全覆盖。你可以根据自己的服务器环境选择对应操作。
第一步：Nginx 环境直接拦截 xmlrpc.php
如果你用的是 Nginx，在站点的 server 配置块中加入以下代码：
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 403;
}保存后执行 nginx -t 测试配置，然后 nginx -s reload 重载。这样任何对 xmlrpc.php 的请求都会直接返回 403，连 PHP 都不会执行，性能开销为零。
第二步：Apache 环境用 .htaccess 拦截
如果你用的是 Apache，在网站根目录的 .htaccess 文件中加入：
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>如果只想允许特定 IP 访问（比如你自己用的桌面发布工具），可以把 Deny from all 改成 Deny from all 加 Allow from 你的IP。但对绝大多数站长来说，直接全禁最省心。
第三步：WordPress 层面关闭 Pingback 和自 Pingback
服务器拦截了 xmlrpc.php，但 Pingback 还有一条内部触发路径，需要在主题的 functions.php 中补充以下代码：
// 禁用 XML-RPC 认证
add_filter('xmlrpc_enabled', '__return_false');
// 移除 Pingback 相关请求
add_filter('wp_headers', function($headers) {
unset($headers['X-Pingback']);
return $headers;
});
// 关闭自 Pingback
add_action('pre_ping', function(&$links) {
$home = get_option('home');
foreach ($links as $l => $link) {
if (strpos($link, $home) === 0) {
unset($links[$l]);
}
}
});这三段代码分别对应：关闭远程发布接口、移除响应头中的 Pingback 标识、阻止文章自己 Pingback 自己。加完后记得清空一下缓存。
第四步（可选）：用插件兜底
如果你不习惯改代码，可以安装 Disable XML-RPC-API 或 Perfmatters 这类插件，一键关闭相关功能。但笔者始终建议：能自己动手就别依赖插件，少一个插件就少一个潜在漏洞。而且插件只能管 WordPress 层，服务器层的拦截还是得自己配。
预防建议：别等被打了才想起来
禁用 XML-RPC 和 Pingback 只是 WordPress 安全加固的第一步。笔者再分享几条实战经验：
- 选靠谱的云服务器：别贪便宜买那种超售严重的小厂机器，被攻击时连工单都没人回。阿里云、腾讯云、AWS Lightsail 这些主流厂商，至少防护和响应有保障。
- 域名和 SSL 别省：正规域名注册商 + 免费 Let’s Encrypt 证书，成本几乎为零，但能避免很多中间人攻击和浏览器警告。
- 限制登录尝试：配合
Limit Login Attempts类插件或服务器层 WAF 规则，防止暴力破解。 - 定期看日志：每周花五分钟扫一眼访问日志，重点看
xmlrpc.php、wp-login.php这些高频攻击入口的请求量，异常早发现早处理。
说到底，WordPress 的安全性很大程度上取决于站长自己的意识。XML-RPC 和 Pingback 这两个“内鬼”，关掉它们不会影响你正常写文章、发博客，但能挡掉一大半自动化攻击脚本。花十分钟按上面的步骤操作一遍，你的服务器会感谢你。
如果你在操作过程中遇到什么奇怪的报错，或者不确定自己的服务器环境该用哪种方案，欢迎在评论区留言，笔者看到都会尽量回复。