本文约 3,386 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
查看服务器访问日志时，除了 wp-login.php，你大概率还会看到大量针对 xmlrpc.php 的 POST 请求，来源 IP 五花八门。这很反常——正常访客根本不会去碰这个文件。xmlrpc.php 是 WordPress 的 XML-RPC 接口，本意是给移动端 App、Jetpack 等做远程发布和 pingback 用的，默认一直开着。问题在于，它的 system.multicall 方法允许在一次 HTTP 请求里打包几百次方法调用，攻击者正好用它来一次性尝试几百个密码，绕过普通的单请求限速；更狠的还能拿它做 pingback 反射，把你的服务器变成攻击别人的帮凶。对大多数个人站和独立站来说，这个接口平时根本用不上，却白白留着巨大风险。尤其当你的站被卷入某个批量攻击批次时，短时间内涌向 xmlrpc.php 的请求会明显暴涨，甚至拖到服务器响应变慢。本文教你怎么确认它被滥用、如何安全关闭，以及关闭后需要留意什么。
故障原因分析
- XML-RPC 默认开启且路径固定。所有 WordPress 站点都有
xmlrpc.php，扫描器闭着眼都能找到，无需探测。
system.multicall是暴力破解放大器。它允许一次请求提交多个wp.getUsersBlogs调用，等于把每 IP 每分钟一次的限速绕过去，一次请求就能试上百个密码。
- 被用作 pingback 反射攻击。攻击者可借你的站点向第三方发起 pingback，把攻击流量伪装成来自你的服务器，既害人也可能让你被投诉或封禁。
- 存在信息泄露面。通过 XML-RPC 的
system.listMethods、wp.getUsersBlogs等可枚举站点信息，为后续攻击提供线索。
- 很多站长根本用不上它。除非你在用 WordPress 官方 App、Jetpack 或依赖 XML-RPC 的发布工具，否则这个接口对你的站没有实际价值，纯属风险敞口。
分步解决方案
方法一：先确认 XML-RPC 到底开着没、有没有被滥用
用一条命令测试接口是否响应（返回一大串 XML 就说明开着）：
curl -s -X POST https://你的域名/xmlrpc.php \
-H "Content-Type: text/xml" \
-d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' | head再统计日志里它被打了多少次：
grep "xmlrpc.php" /www/wwwlogs/yoursite.com.log | wc -l
grep "xmlrpc.php" /www/wwwlogs/yoursite.com.log | awk '{print $1}' | sort | uniq -c | sort -rn | head如果数量很大或某个 IP 占比极高，基本可以确定它正被当作攻击入口。
方法二：用 functions.php 关闭 XML-RPC（推荐，最温和）
编辑当前主题的 functions.php（建议用子主题，避免升级主题被覆盖），加入以下代码：
// functions.php —— 关闭 XML-RPC 接口
add_filter( 'xmlrpc_enabled', '__return_false' );
// 同时除去响应头里的 X-Pingback，减少暴露线索
add_filter( 'wp_headers', function ( $headers ) {
unset( $headers['X-Pingback'] );
return $headers;
} );
// 可选：直接拦掉所有 XML-RPC 方法调用
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
unset( $methods['system.multicall'] );
return $methods;
} );保存后重新执行方法一的测试命令，若返回 XML-RPC services are disabled on this site. 之类提示，说明已生效。
方法三：用 .htaccess 从服务器层拦掉（更彻底）
如果想让请求根本到不了 PHP，可以在网站根目录 .htaccess 里直接拒绝访问：
# 拒绝所有对 xmlrpc.php 的访问
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Nginx 用户则在站点配置里加：
location = /xmlrpc.php {
deny all;
return 403;
}这样无论什么方法调用都会被挡在门外，连 PHP 都不用启动，最省资源。
方法四：只对可信来源放行（需要时）
如果你确实要用 WordPress App 或 Jetpack，不能完全关闭，可以只允许特定 IP 或特定 UA 访问，其余一律拒绝。例如在 .htaccess 中：
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 1.2.3.4
</Files>把 1.2.3.4 换成你实际使用的出口 IP。这样既能保留功能，又堵住了公开滥用。
方法五：用插件一键关闭（适合不爱改代码的站长）
不想动代码，可以安装 Disable XML-RPC（如 Disable XML-RPC-API 类插件），启用即关闭接口，后台可视化操作，卸载即恢复。适合新手，但这类插件较多，选一个维护活跃、评分高的即可，不要装多个。
常见踩坑点
- 关闭后 Jetpack 或官方 App 失灵。这两者依赖 XML-RPC，若你在用它们，请改用方法四的 IP 放行而非彻底关闭。
- 只加了
xmlrpc_enabled却没除X-Pingback。响应头仍暴露线索，建议一并清理。
- 改主题文件被升级覆盖。直接改主题
functions.php，主题一更新改动就丢了，务必用子主题。
.htaccess语法写错导致整站 500。改前先备份，改后立即刷新首页确认正常。
- 关掉后忘了确认是否真生效。用
curl复测一次，别只看代码写了就以为万事大吉。
- 以为关了 XML-RPC 就安全了。它也挡不住
wp-login.php爆破，登录防护该做的还要做。
- 只在代码层禁用了部分方法。只移除
xmlrpc_methods里的个别方法时，system.listMethods等仍可被调用，想彻底省心就从.htaccess或 Nginx 层拒绝整个xmlrpc.php，让请求根本到不了 PHP。
总结
xmlrpc.php 是 WordPress 一个默认开启、却常被攻击者拿来做暴力破解放大和 pingback 反射的接口。对绝大多数个人站和独立站来说，它没有使用价值，关闭它收益远大于成本。做法很简单：用 functions.php 里的 xmlrpc_enabled 过滤器关闭并清理 X-Pingback 头，或用 .htaccess、Nginx 直接从服务器层拒绝访问；如果确实需要 Jetpack 或官方 App，就用 IP 白名单只放行自己。关闭后记得用 curl 复测确认生效。把这处口子堵上，是 WordPress 安全加固里投入产出比很高的一步。
