禁用wordpress的xml-rpc功能可有效提升网站安全性，推荐通过修改.htaccess或functions.php文件实现，虽然可能影响远程发布工具、旧版手机app及pingback功能，但对大多数现代站点影响甚微，且可通过waf、安全插件、强密码、两步验证和日志监控等措施进一步加固安全，综合来看，禁用xml-rpc是利大于弊的安全最佳实践。
WordPress的XML-RPC是一个远程调用接口，它允许外部应用程序和客户端（比如手机App、桌面发布工具，甚至是其他网站）与你的WordPress站点进行交互。简单来说，它就像一个隐藏的通信端口，让非浏览器工具能发布内容、管理评论，或者执行其他操作。然而，这个方便的特性也带来了显著的安全风险，特别是成为恶意攻击的常见目标，比如被用于暴力破解密码或发起DDoS攻击。因此，在很多情况下，禁用它是一个直接且有效的网站安全强化措施。
解决方案
禁用WordPress的XML-RPC功能有几种方法，我个人比较倾向于直接修改配置文件或主题代码，因为这样更彻底，也减少了对额外插件的依赖。
方法一：通过修改.htaccess文件禁用
这是我常用的方法之一，因为它在服务器层面就阻止了对
xmlrpc.php文件的访问。
# 阻止对xmlrpc.php的访问 <Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
将这段代码添加到你WordPress根目录下的
.htaccess文件顶部。如果你的网站使用Nginx服务器，配置方式会略有不同，但核心思路是一致的，即阻止对该文件的HTTP请求。
方法二：通过修改functions.php文件禁用
如果你不想动
.htaccess，或者你的服务器环境不允许，那么在主题的
functions.php文件中添加代码也是一个不错的选择。
// 禁用XML-RPC API
add_filter('xmlrpc_enabled', '__return_false');
// 移除XML-RPC的头部信息，防止被扫描发现
remove_action('wp_head', 'rsd_link');将这段代码添加到你当前活动主题的
functions.php文件末尾。第一行代码直接禁用了XML-RPC功能，第二行则移除了页面头部中指向
xmlrpc.php的RSD（Really Simple Discovery）链接，这在一定程度上能减少被自动化工具发现的几率。
为什么WordPress的XML-RPC会带来安全隐患？
说实话，XML-RPC的设计初衷是为了便利，让WordPress能更好地融入外部生态。比如，早期的桌面博客客户端、Pingback和Trackback功能，甚至是WordPress官方的手机App，都依赖于它。但问题在于，它也成了一个开放的攻击面。
最常见也是最危险的，就是暴力破解攻击。攻击者可以通过XML-RPC的
system.multicall方法，在一次请求中尝试成百上千个密码组合。这比传统的单个登录请求效率高得多，使得暴力破解变得异常容易和快速。我见过太多网站因为XML-RPC被用于暴力破解而导致账户失陷的案例，真的让人头疼。
另一个风险是DDoS攻击，特别是Pingback放大攻击。攻击者可以利用你的XML-RPC接口，向大量目标网站发送伪造的Pingback请求，而你的服务器就成了攻击的跳板，这不仅消耗你服务器的资源，还可能让你卷入不必要的麻烦。在我看来，这种“方便”带来的风险，远超它在现代网站运营中的实际价值。现在我们有更安全、更现代的REST API，XML-RPC的许多功能都可以被替代。
禁用XML-RPC对WordPress网站功能有什么影响？
禁用XML-RPC确实会影响到一些依赖它的功能，但对于大多数现代WordPress网站来说，这些影响通常可以忽略不计，甚至是有益的。
首当其冲受影响的，是远程发布工具。如果你习惯使用像MarsEdit（Mac）或Windows Live Writer（PC）这样的桌面客户端来撰写和发布文章，那么禁用XML-RPC后，这些工具将无法连接到你的网站。对我而言，我更倾向于直接在WordPress后台或使用现代编辑器（如Gutenberg）进行创作，所以这影响不大。
其次是WordPress官方手机App。老版本的App可能依赖XML-RPC进行连接和操作。不过，新版本的App通常会优先使用WordPress REST API，所以影响可能没那么大。如果你发现App无法连接，这可能是原因之一。
还有就是Pingback和Trackback功能。这些是WordPress网站之间相互通知链接的功能。禁用XML-RPC后，这些功能将失效。但说句实话，Pingback和Trackback现在更多地被视为垃圾评论的来源，很多人本来就会选择禁用它们，所以这反而是个“副作用”带来的好处。
至于像Jetpack这样的插件，它的一些模块过去也可能依赖XML-RPC。但Jetpack通常会非常智能地适应环境，如果XML-RPC被禁用，它通常会回退到使用REST API或其他方式进行通信。所以，除非你使用非常老旧的插件或特定服务，否则影响真的不大。在我看来，为了安全牺牲一点点“旧”的功能，是完全值得的。
除了禁用，还有哪些方法可以保护WordPress免受XML-RPC攻击？
虽然禁用XML-RPC是最直接的解决办法，但我们总不能把所有鸡蛋放在一个篮子里。在某些特殊情况下，你可能无法完全禁用它（比如确实有依赖它的旧系统）。这时，结合其他安全措施就显得尤为重要。
一个非常实用的方法是使用Web应用防火墙（WAF）。像Cloudflare、Sucuri这样的WAF服务，它们在流量到达你的服务器之前就能识别并阻止恶意请求，包括针对XML-RPC的暴力破解和DDoS攻击。WAF可以根据规则过滤掉可疑的IP地址和请求模式，这在很大程度上能减轻你服务器的压力。
另外，安全插件也是一个不错的补充。像Wordfence、iThemes Security等流行的WordPress安全插件，它们通常内置了针对XML-RPC的保护功能。它们可以限制对
xmlrpc.php的访问频率，阻止可疑IP，或者在检测到暴力破解尝试时锁定账户。我通常会建议客户安装一个靠谱的安全插件，即使XML-RPC被禁用，它也能提供多一层防护。
当然，强密码和两步验证（2FA）是任何网站都不可或缺的基础安全措施。即使攻击者通过XML-RPC尝试暴力破解，如果你的密码足够复杂，并且启用了2FA，那么他们成功的几率也会大大降低。这虽然不是直接针对XML-RPC的防御，但却是防止账户失陷的最后一道防线。
最后，定期审查访问日志也很有必要。如果你发现大量来自不寻常IP地址的
xmlrpc.php请求，这可能就是攻击的迹象。通过监控日志，你可以及时发现并采取措施，比如手动封禁这些恶意IP。这需要一定的技术背景，但对于维护网站安全来说，主动监控总是比被动修复要好得多。
