XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильное приложение, внешнюю публикацию или интеграцию с сервисом, который до сих пор использует этот протокол. Поэтому правильный подход здесь не в том, чтобы просто закрыть /xmlrpc.php, а в том, чтобы сначала понять, нужен ли он вообще на вашем сайте, и только потом выбрать способ отключения.
Если задача узкая — убрать лишнюю поверхность атаки и при этом не задеть рабочие сценарии, — лучше идти по проверке зависимостей. Это быстрее, чем потом откатывать «жёсткий» запрет через серверную конфигурацию.
Когда XML-RPC действительно стоит отключать
На большинстве обычных сайтов XML-RPC не нужен. Если вы публикуете записи только из админки, не используете Jetpack в старом режиме, не подключали внешние клиенты и не синхронизируете контент через сторонние приложения, протокол чаще всего просто висит мёртвым грузом. При этом он остаётся отдельной точкой входа, которую регулярно сканируют боты.
Но есть и обратная сторона: некоторые функции WordPress исторически завязаны на XML-RPC. Самые частые из них — удалённая публикация, pingback/trackback и отдельные интеграции с мобильными или десктопными клиентами. Если отключить его без проверки, можно получить неочевидные ошибки в стороннем софте.
Быстрая диагностика перед отключением
Сначала проверьте, есть ли у сайта реальные обращения к xmlrpc.php. Это можно сделать по логам веб-сервера или через мониторинг. Если доступа к логам нет, хотя бы откройте страницу вручную и посмотрите, отвечает ли файл на запросы.
curl -I https://example.com/xmlrpc.phpНормальный ответ сам по себе ещё не означает, что протокол используется, но если файл доступен извне, его уже можно считать отдельной точкой риска. Дальше проверьте, нет ли в проекте плагинов или внешних сервисов, которые работают через XML-RPC. Если сайт старый, особенно внимательно смотрите на интеграции с публикацией из сторонних клиентов и на Jetpack.
- есть ли обращения к
/xmlrpc.phpв access log; - используется ли Jetpack или старые мобильные клиенты;
- нужна ли удалённая публикация;
- используются ли pingback/trackback;
- есть ли внешняя синхронизация контента.
Как отключить XML-RPC: три рабочих варианта
Способ зависит от того, где вы хотите поставить блок: на уровне WordPress, на уровне сервера или через плагин. Для большинства сайтов достаточно одного из первых двух вариантов. Плагин имеет смысл только если вам нужен быстрый переключатель без правок конфигурации.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме/му-плагине | Контроль, без лишних зависимостей | Нужно не забыть про обновления и место подключения | Если есть доступ к коду |
| .htaccess / nginx | Блокирует запрос раньше WordPress | Требует доступа к серверу и аккуратности | Если нужен жёсткий запрет |
| Плагин безопасности | Быстро и без правок файлов | Лишняя зависимость, иногда избыточно | Если нет доступа к конфигу |
Вариант 1: отключить через PHP-фильтр
Если вам нужно именно отключить XML-RPC на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Такой способ удобен тем, что его легко откатить и он не требует правок веб-сервера.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключит обработку XML-RPC в WordPress, но сам файл xmlrpc.php может по-прежнему отвечать на запросы. Для части сценариев этого достаточно, но если вы хотите убрать и сам внешний доступ, лучше дополнить блокировкой на сервере.
Вариант 2: запретить доступ на уровне сервера
Если задача — уменьшить поверхность атаки, серверный запрет надёжнее. Он отсекает запросы до загрузки WordPress, а значит, не тратит ресурсы PHP и не даёт боту даже дойти до ядра.
Для Apache можно добавить правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx обычно используют отдельное правило в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. На nginx это особенно важно: одна лишняя скобка может уронить весь виртуальный хост.
Вариант 3: отключить только pingback, если XML-RPC нужен частично
Иногда полностью выключать XML-RPC нельзя, но pingback и trackback вам не нужны. Тогда можно оставить протокол для интеграций и убрать только этот функционал. Это более тонкая настройка, которая подходит для старых проектов с внешними клиентами.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Такой вариант не закрывает XML-RPC полностью, но убирает один из самых шумных и бесполезных сценариев, который часто используют для спама и лишней нагрузки.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Если вы просто открыли страницу в браузере и не увидели ошибки, это ещё не значит, что протокол реально заблокирован. Нужен тест на уровне HTTP-ответа.
Сначала проверьте заголовки:
curl -i https://example.com/xmlrpc.phpЕсли вы блокировали доступ на сервере, ожидайте 403 Forbidden или другой явный отказ. Если отключали только через WordPress-фильтр, ответ может отличаться в зависимости от конфигурации, но запрос не должен выполнять XML-RPC-методы.
Дальше проверьте типичный XML-RPC запрос. Можно отправить минимальный payload и посмотреть, как отвечает сайт:
curl -s https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?>
<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>'Если блокировка настроена корректно, вы не должны получить рабочий список методов. Для серверного запрета ответ обычно вообще не дойдёт до WordPress.
Частые ошибки и как их исправить
Отключили XML-RPC, а сломали внешнюю публикацию
Такое бывает, когда сайт использует старый клиент или интеграцию, о которой уже забыли. Решение простое: сначала найдите источник запросов в логах, потом решайте, можно ли заменить его REST API или вообще убрать интеграцию.
Поставили блок только в WordPress, но бот всё равно стучится
Фильтр xmlrpc_enabled не убирает сам URL из внешнего мира. Боты продолжат долбить /xmlrpc.php, просто WordPress будет отвечать отказом. Если цель — снизить нагрузку и шум в логах, нужен серверный запрет.
Сломали Jetpack или мобильное приложение
Если эти сервисы используются, не отключайте XML-RPC вслепую. Сначала проверьте, можно ли перевести нужную функцию на другой канал. Если нет — оставьте протокол включённым и ограничьте только pingback или настройте доступ точечно.
Забыли про кэш и не увидели изменения
После правок в конфигурации или коде очистите кэш страницы, объектный кэш и, если есть, CDN. Иначе проверка может показать старый ответ, и вы будете искать проблему не там.
Что делать, если нужен более безопасный вариант без ручной правки кода
Если на сайте нет удобного доступа к конфигу, а править тему не хочется, используйте плагин, который умеет отключать лишние технические функции и чистить поверхность атаки. В экосистеме WPShop для таких задач подходит Clearfy Pro: он закрывает часть типовых SEO- и технических дублей, а также помогает отключать ненужные элементы без ручного ковыряния в шаблонах. Но даже в этом случае стоит понимать, что именно вы отключаете, а не включать всё подряд.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, лучше закрыть его на сервере и дополнительно проверить, нет ли других лишних точек входа: старых endpoint-ов, открытых файлов резервных копий, лишних REST-маршрутов от неиспользуемых плагинов. Это не про паранойю, а про сокращение поверхности атаки и уменьшение шума в логах.
- не отключайте протокол без проверки интеграций;
- предпочитайте серверный запрет, если нужен именно блок;
- после изменений проверяйте ответ
/xmlrpc.phpчерезcurl; - очищайте кэш перед финальной проверкой;
- если нужен только pingback, отключайте его точечно, а не весь XML-RPC.
В итоге рабочая схема обычно выглядит так: сначала диагностика, потом выбор способа блокировки, затем проверка реального HTTP-ответа и только после этого — финальная очистка кэша и мониторинг логов. Это тот случай, когда аккуратность экономит больше времени, чем «быстрое» отключение наугад.