如何在WordPress中启用和禁用xmlrpc.php（以及为什么它很重要）

xmlrpc.php 文件是 WordPress 的核心组件，它公开了一个 XML-RPC API 端点，允许远程应用程序进行身份验证并执行服务器端操作——发布文章、管理评论、触发 pingback 等。由于它默认接受未经身份验证的 POST 请求，并在大多数安全层激活之前处理这些请求，因此它是任何 WordPress 安装中最常被滥用的攻击面之一。

如果您不使用 WordPress 移动应用程序、Jetpack 或任何明确需要 XML-RPC 的第三方服务，禁用 xmlrpc.php 是正确的默认安全策略。如果您确实依赖这些集成，可以对端点进行加固而不是完全移除它。

什么是 xmlrpc.php 以及它如何工作

XML-RPC（可扩展标记语言远程过程调用）是一种将函数调用编码为 XML 并通过 HTTP 传输的协议。WordPress 自 3.5 版本起内置了完整的 XML-RPC 服务器，实现于位于 WordPress 根目录的 xmlrpc.php 文件中。

当远程客户端——移动应用程序、桌面博客客户端或自动化脚本——向 https://yourdomain.com/xmlrpc.php 发送 POST 请求时，WordPress 会解析 XML 载荷，对请求正文中嵌入的凭据进行身份验证，并执行所请求的方法。整个交换在单次 HTTP 往返中完成，这既是其优势，也是其从安全角度来看的根本弱点。

WordPress 公开的核心 XML-RPC 方法

• wp.newPost / wp.editPost — 远程创建和更新文章
• wp.getComments / wp.deleteComment — 管理评论
• wp.uploadFile — 上传媒体文件到服务器
• pingback.ping — 通知远程站点它已被链接
• system.multicall — 将多个方法调用批量合并到单个 HTTP 请求中

system.multicall 方法尤为危险。单个 HTTP 请求可以捆绑数百个 wp.getUsersBlogs 调用，每个调用测试不同的密码。这使攻击者能够在仅生成一条服务器日志条目的情况下执行数千次身份验证尝试，从而绕过统计单个请求的速率限制工具。

启用 xmlrpc.php 的安全风险

通过 system.multicall 放大暴力破解

传统暴力破解攻击每个 HTTP 请求发送一对凭据。使用 XML-RPC 时，攻击者可以将 500 次登录尝试包装在单个 system.multicall 载荷中。标准的 fail2ban 规则或登录尝试计数器只看到一个请求，而攻击者却获得了 500 次猜测机会。这不是理论上的风险——它是实际观察到的最常见 XML-RPC 漏洞利用方式。

通过 Pingback 放大 DDoS

WordPress 通过 xmlrpc.php 自动处理传入的 pingback 请求。攻击者可以向数千个 WordPress 站点发送精心构造的 pingback.ping 请求，指示每个站点向单个受害者 URL 发送 HTTP 请求。受害者会收到来自合法 WordPress 服务器的大量请求洪流，使基于 IP 的封锁无效。您的服务器同时成为受害者（资源耗尽）和不情愿的攻击放大器。

通过 Pingback 实现 SSRF

pingback 机制可被滥用于服务器端请求伪造（SSRF）。攻击者发送一个 pingback.ping 请求，其中源 URL 指向内部网络资源——例如 http://192.168.1.1/admin。WordPress 服务器从网络边界内部获取该 URL，可能暴露不可公开路由的内部服务。

传输中的凭据暴露

XML-RPC 在 XML 信封中以纯文本形式在 POST 正文中传输凭据。如果您的站点不强制使用 HTTPS，凭据将暴露给任何网络观察者。即使使用 TLS，凭据也会嵌入每个请求中——没有会话令牌或 OAuth 流程来限制暴露窗口。

何时应保持 xmlrpc.php 启用

默认情况下禁用它，但如果您的工作流程确实依赖以下任何一项，则保持启用：

• WordPress 移动应用程序（iOS/Android）：官方应用程序使用 XML-RPC 对自托管 WordPress 安装执行所有站点管理操作。
• Jetpack 插件：多个 Jetpack 模块——包括 publicize、移动推送通知和某些统计功能——通过 XML-RPC 与 WordPress.com 服务器通信。
• 桌面博客客户端：MarsEdit、Windows Live Writer 及类似工具完全依赖 XML-RPC API。
• 自动化发布流程：IFTTT、Zapier 以及将内容推送到 WordPress 的自定义脚本，在未配置 REST API 时通常使用 XML-RPC。
• WordPress 站点之间的 Pingback/Trackback：如果跨站点 pingback 通知是您编辑工作流程的一部分，禁用 xmlrpc.php 将使其静默。

如果以上均不适用，则没有任何操作上的理由保持端点开放。

xmlrpc.php 与 WordPress REST API

WordPress 在 4.7 版本中引入了 REST API，作为 XML-RPC 的现代化、基于令牌的替代方案。了解两者之间的差异有助于您判断禁用 XML-RPC 是否会破坏任何关键功能。

如果您正在构建新集成或迁移现有集成，请使用 REST API。其身份验证模型更为安全，且端点在基础设施层面更易于审计和速率限制。

如何在 WordPress 中禁用 xmlrpc.php

选择与您的服务器访问级别和风险承受能力相匹配的方法。方法按从最低到最高的服务器级别执行顺序排列。

方法一：通过插件禁用（最快捷，无需服务器访问权限）

对于共享主机环境或您不希望编辑服务器配置文件的站点，插件是最便捷的选择。

推荐插件：

• Disable XML-RPC-API — 单一用途，占用资源少，激活即生效
• All In One WP Security and Firewall — 更广泛的安全套件，具有细粒度的 XML-RPC 控制

Disable XML-RPC-API 的操作步骤：

1. 在 WordPress 后台导航至插件 > 安装插件。
2. 搜索”Disable XML-RPC-API”，点击立即安装，然后点击启用。
3. 无需进一步配置——该插件在激活时会挂钩到 xmlrpc_enabled 并立即返回 false。

All In One WP Security and Firewall 的操作步骤：

1. 激活插件后，前往 WP Security > 防火墙。
2. 找到 XML-RPC 部分。
3. 启用完全阻止 XML-RPC 请求的选项。
4. 保存设置。

局限性：基于插件的拦截在 WordPress PHP 执行上下文中触发。服务器仍会启动 PHP、加载 WordPress 并处理请求，然后才拒绝它。在遭受大量攻击时，这会消耗 CPU 和内存。对于正在遭受主动攻击的高流量站点，请改用 .htaccess 或 Nginx 方法。

方法二：通过 .htaccess 禁用（Apache — 服务器级别拦截）

在 .htaccess 级别进行拦截可以防止 PHP 对针对 xmlrpc.php 的请求执行任何操作。这在负载下效率显著更高。

1. 通过 FTP、SFTP 或您的主机文件管理器连接到服务器，并打开 WordPress 根目录中的 .htaccess 文件（通常位于 public_html/.htaccess）。
2. 添加以下代码块。将其放置在标准 WordPress 重写规则之前：

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. 保存文件。

要验证拦截是否生效，请从本地计算机运行测试：

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

您应该收到 403 响应。收到 200 或 405 表示拦截尚未生效。

边缘情况——如果您仍需要来自特定可信 IP 的 pingback，可以将其加入白名单：

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

方法三：通过 Nginx 配置禁用

如果您的服务器运行 Nginx（在 VPS 主机环境中很常见），.htaccess 文件将不起作用。请直接将代码块添加到您站点的服务器块配置中。

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

return 444 指令关闭 TCP 连接而不发送 HTTP 响应，这比 403 更高效，因为它防止攻击者的客户端收到任何反馈。编辑后，重新加载 Nginx：

sudo nginx -t && sudo systemctl reload nginx

将此 location 块放置在您的 server {} 块内，位于任何 try_files 或 PHP 处理指令之前。

方法四：通过 functions.php 禁用（WordPress 过滤器钩子）

此方法使用 WordPress 过滤器在应用层禁用 XML-RPC。它比服务器级别拦截效率低，但在您缺乏直接服务器访问权限且希望使用基于代码的解决方案而不依赖插件时非常有用。

1. 在 WordPress 后台前往外观 > 主题编辑器，或通过 SFTP 直接访问 wp-content/themes/your-theme/functions.php 文件。
2. 在文件末尾添加以下内容：

// Disable XML-RPC completely
add_filter( 'xmlrpc_enabled', '__return_false' );

1. 保存文件。

重要注意事项：此过滤器禁用经过身份验证的 XML-RPC 方法，但不会阻止 pingback.ping 方法，也不会阻止文件被访问。服务器仍会处理请求，直到 WordPress 评估过滤器为止。为获得完整保护，请将此方法与 .htaccess 或 Nginx 拦截结合使用。

如果您使用子主题，请始终将自定义代码添加到子主题的 functions.php 中，而不是父主题。父主题更新将覆盖您的更改。

方法五：选择性禁用——仅阻止 Pingback

如果您需要 XML-RPC 用于 Jetpack 或移动发布，但希望消除 DDoS 放大向量，可以仅禁用 pingback 方法，同时保持 API 其余功能正常运行。

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

将此代码添加到您子主题的 functions.php 或特定站点插件中。这是运行 Jetpack 但不需要接收 pingback 的站点的推荐配置。

如何重新启用 xmlrpc.php

撤销上述任何方法即可恢复 XML-RPC 访问：

• 插件方法：从插件 > 已安装的插件中停用或删除拦截插件。
• .htaccess 方法：从 .htaccess 中删除 <Files "xmlrpc.php"> 代码块并保存。
• Nginx 方法：从服务器配置中删除 location = /xmlrpc.php 代码块，并使用 sudo systemctl reload nginx 重新加载 Nginx。
• functions.php 方法：删除 add_filter( 'xmlrpc_enabled', '__return_false' ) 行并保存。

重新启用后，验证端点是否正确响应：

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

列出可用方法的有效 XML 响应确认端点处于活动状态。

在不禁用 xmlrpc.php 的情况下进行加固

如果禁用不是一个选项，请应用以下缓解措施来减少攻击面：

强制使用 HTTPS：确保您的站点使用有效的 TLS 证书。如果尚未配置，请通过您的主机提供商进行配置——SSL 证书可防止传输过程中的凭据拦截。

在防火墙或 CDN 层面进行速率限制：配置您的 WAF（Cloudflare、ModSecurity）将每个 IP 每分钟对 xmlrpc.php 的 POST 请求限制在 5-10 次以内。

专门阻止 system.multicall：

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

这消除了暴力破解放大向量，同时保留所有其他 XML-RPC 功能。

按 IP 限制访问：如果您只从已知 IP 地址访问 XML-RPC（您的移动应用运营商 IP 范围或静态办公室 IP），请在 .htaccess 或 Nginx 中将这些地址加入白名单并拒绝所有其他地址。

监控访问日志：定期审计服务器日志，检查对 xmlrpc.php 的重复 POST 请求。该文件的 200 状态 POST 请求突然激增是正在进行的暴力破解活动的可靠指标。

在配备 cPanel 的 VPS 或其他托管面板环境中，您可以直接从控制面板配置 ModSecurity 规则来执行这些限制，无需手动编辑文件。

选择正确方法：决策矩阵

对于托管在独立服务器上的生产站点，Nginx 或 Apache 服务器级别拦截始终优于基于插件的解决方案，因为它完全阻止了对恶意请求的 PHP 执行，消除了基于插件的拦截在持续攻击下产生的 CPU 开销。

实用关键要点清单

• 在禁用 XML-RPC 之前，审计您的技术栈中是否有任何活跃的插件或服务实际需要它——检查 Jetpack、移动应用和任何发布自动化工具。
• 如果不存在依赖关系，请应用服务器级别拦截（.htaccess 或 Nginx）而非插件——它更高效且在插件停用后仍然有效。
• 如果必须保持 XML-RPC 活跃，请通过 xmlrpc_methods 过滤器无条件移除 system.multicall 和 pingback.ping——这两种方法占 XML-RPC 滥用的绝大多数。
• 始终在接受经过身份验证请求（包括 XML-RPC）的任何 WordPress 站点上强制使用 HTTPS。
• 应用任何拦截后，使用 curl 验证端点返回 403 或断开连接——不要在未经测试的情况下假设配置正确。
• 在基于 Nginx 的 VPS 或独立服务器环境中，使用 return 444 而非 deny all，以避免向攻击者提供任何 HTTP 级别的反馈。
• 记录并监控对 xmlrpc.php 的 POST 请求——突然激增是凭据填充或 DDoS 放大活动的早期预警。
• 如果您管理多个 WordPress 站点，请考虑在服务器或 CDN 层面集中此配置，而不是逐站点应用插件规则。

对于需要强大远程管理功能而不承担 XML-RPC 风险面的站点，将集成迁移到带有应用程序密码的 WordPress REST API 是正确的长期路径。REST API 提供每令牌撤销、范围权限和标准 HTTP 语义，更易于保护和审计。

如果您正在设置新的 WordPress 环境并希望从一开始就拥有干净、安全的基线，预配置了 ModSecurity 的 VPS 控制面板可为您提供服务器级别的 WAF 保护，无需手动编写规则。

—

常见问题解答

禁用 xmlrpc.php 会破坏 WordPress REST API 吗？

不会。REST API（/wp-json/）是一个完全独立的端点，具有自己的身份验证和路由。阻止 xmlrpc.php 对 REST API 功能没有任何影响。这两个系统在架构上是独立的。

禁用 xmlrpc.php 会破坏 Jetpack 吗？

这取决于您使用的 Jetpack 模块。Jetpack 已逐步将功能迁移到 REST API，但一些较旧的模块——包括某些 publicize 和通知功能——仍通过 XML-RPC 与 WordPress.com 服务器通信。在禁用之前，请检查 Jetpack > 仪表板 > 调试页面，查看 XML-RPC 连接是否被列为必要条件。

.htaccess 方法和 functions.php 方法哪个更安全？

.htaccess 方法在攻击条件下明显更安全。它在 PHP 加载之前在 Web 服务器层面拦截请求，消耗极少资源。functions.php 过滤器在 WordPress 的 PHP 执行上下文中触发，这意味着服务器仍会为每个被拦截的请求引导 WordPress——在高流量攻击下这代价高昂。

如果我只通过 WordPress 过滤器禁用 xmlrpc.php，攻击者仍然可以利用它吗？

部分可以。xmlrpc_enabled 过滤器阻止经过身份验证的方法调用，但文件仍可公开访问，服务器仍会处理传入请求。根据 WordPress 版本，pingback 端点可能仍部分有效。为获得完整保护，请将过滤器与服务器级别拦截结合使用。

如何检查 xmlrpc.php 当前是否可在我的站点上访问？

从本地终端运行以下命令，将域名替换为您自己的：

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

收到 200 响应表示端点开放。收到 403 或连接断开（000）确认它已被拦截。您也可以使用 xmlrpc.eritreo.it 上的在线工具专门测试 pingback 漏洞。