XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, попыткам брутфорса и странным обращениям к /xmlrpc.php в логах. Полностью рубить его без проверки зависимостей — плохая идея: у части сайтов через XML-RPC до сих пор работают Jetpack, старые мобильные клиенты и внешние публикационные сервисы.
Ниже — рабочая схема: как понять, нужен ли вам XML-RPC, как отключить его безопасно, чем заменить и как проверить, что сайт не потерял важные интеграции.
Когда XML-RPC действительно мешает
Если в логах постоянно видны запросы к xmlrpc.php, это не всегда проблема сама по себе. Но на практике этот файл часто используют для перебора паролей и массовых запросов. На слабом хостинге он ещё и создаёт лишнюю нагрузку, потому что WordPress обрабатывает запросы не так дёшево, как статический ответ сервера.
Отключение XML-RPC имеет смысл, если:
- вы не пользуетесь Jetpack или уже перевели его функции на другие способы подключения;
- не публикуете записи из внешних клиентов и приложений;
- в логах есть регулярные обращения к
/xmlrpc.phpс ошибками авторизации; - нужно уменьшить поверхность атаки на сайте, где уже есть защита от REST API и админки.
Диагностика: что сломается, если отключить XML-RPC
Перед изменениями проверьте, есть ли реальные зависимости. Самый простой путь — посмотреть, кто вообще обращается к XML-RPC и используете ли вы его осознанно. Если у вас есть доступ к логам веб-сервера, найдите строки с xmlrpc.php. Если логов нет, проверьте настройки плагинов и сценарии публикации.
Быстрый чек-лист перед отключением
- Используется ли Jetpack для статистики, публикации или удалённого управления;
- Есть ли мобильное приложение WordPress, которое вы реально используете;
- Подключены ли внешние сервисы автопостинга, которые работают через XML-RPC;
- Не завязаны ли на XML-RPC старые интеграции с редакторами или CRM;
- Есть ли отдельные правила в WAF или на уровне хостинга, которые уже режут этот файл.
Если хотя бы один пункт вызывает сомнение, сначала протестируйте отключение на staging-копии. Для боевого сайта лучше идти по схеме «сначала блокировка по запросам, потом полное отключение», а не наоборот.
Как отключить XML-RPC в WordPress
Есть три нормальных подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, кто обслуживает сайт и насколько вам важно оставить возможность быстро откатить изменения.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правок темы | Ещё один плагин в стеке | Если нужен простой и обратимый вариант |
| Код | Контроль, минимум зависимостей | Нужно не ошибиться с местом вставки | Если вы ведёте сайт как разработчик |
| Сервер | Режет запросы до WordPress | Нужен доступ к конфигу | Если важна защита и снижение нагрузки |
Вариант 1. Отключение через код
Если вам нужен предсказуемый результат без лишних плагинов, добавьте фильтр в functions.php дочерней темы или в собственный мини-плагин. Это не ломает админку и легко откатывается.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, сервер всё равно отдаст файл, но WordPress не будет обрабатывать запрос как рабочий XML-RPC-эндпоинт.
Вариант 2. Блокировка на уровне веб-сервера
Если цель — именно защита и снижение нагрузки, лучше резать запросы раньше, чем они попадут в PHP. Для Apache можно добавить правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx обычно используют отдельное правило в конфиге сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Это уже не просто «выключить функцию», а именно заблокировать доступ к файлу. Такой вариант полезен, если сайт регулярно атакуют через XML-RPC и вы не хотите тратить ресурсы PHP на обработку мусорных запросов.
Вариант 3. Плагин для точечного контроля
Если на сайте есть несколько администраторов и не хочется править код, можно использовать плагин, который умеет отключать XML-RPC и другие лишние поверхности. В этом сценарии удобно, когда в одном месте вы также чистите дубли, отключаете эмодзи, REST-эндпоинты и лишние системные запросы. Например, Clearfy Pro подходит, если вам нужен не только XML-RPC, но и более широкая техническая чистка сайта: https://wpshop.ru/plugins/clearfy.
Пошаговое решение без риска для интеграций
Если вы не уверены, что XML-RPC не нужен, действуйте поэтапно.
- Сделайте резервную копию файлов и базы.
- Проверьте, есть ли активный Jetpack и какие функции он использует.
- На staging-копии отключите XML-RPC через фильтр
xmlrpc_enabled. - Проверьте публикацию из админки, вход в панель и работу интеграций.
- Если всё стабильно, перенесите изменение на боевой сайт.
- При высокой нагрузке добавьте блокировку на уровне Nginx или Apache.
Если у вас есть внешняя интеграция, которой XML-RPC всё ещё нужен, не отключайте его полностью. В таком случае лучше ограничить доступ по IP на уровне сервера или закрыть файл через WAF, оставив только доверенные источники.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужен ответ сервера и отсутствие рабочих XML-RPC-вызовов.
Проверка через браузер и curl
Откройте /xmlrpc.php в браузере. Если доступ закрыт на уровне сервера, вы увидите отказ в доступе или 403. Если отключение сделано только через WordPress, файл может отвечать, но без нормальной обработки XML-RPC.
Для более точной проверки используйте curl:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на сервере, ожидаемым результатом будет 403 или другой отказ в доступе. Если отключали только фильтром WordPress, ответ может отличаться, но сам XML-RPC не должен работать как раньше.
Проверка зависимостей
- войти в админку и создать тестовую запись;
- проверить Jetpack, если он установлен;
- убедиться, что мобильное приложение WordPress не теряет соединение;
- посмотреть логи сайта после изменения — обращений к
xmlrpc.phpдолжно стать меньше или они должны получать отказ.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо, если Jetpack использовал XML-RPC для части функций. Решение простое: либо вернуть доступ, либо перевести нужные функции на другой способ подключения, либо заменить сценарий работы. Не стоит держать XML-RPC включённым только ради одной старой функции, если её можно перенести.
Добавили правило в .htaccess, но файл всё равно отвечает
Частая причина — сайт работает не на Apache, а на Nginx, или правило стоит не в том месте. Ещё одна причина — поверх вашего правила есть конфигурация хостинга. В этом случае проверяйте именно активный веб-сервер и его конфиг, а не только файл в корне WordPress.
Отключили через код, но атаки в логах остались
Фильтр xmlrpc_enabled не запрещает сам HTTP-запрос к файлу. Он лишь отключает функциональность внутри WordPress. Если вам нужно убрать шум и нагрузку, блокируйте xmlrpc.php на уровне сервера или через WAF.
Сломали интеграцию, но не поняли какую
Так бывает, когда отключение делают без staging и без списка зависимостей. Если после изменения что-то перестало публиковаться или синхронизироваться, сначала ищите внешние клиенты, старые мобильные приложения и плагины автопостинга. Не возвращайте XML-RPC «на всякий случай» без диагностики.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC редко решает проблему в одиночку. Если вы уже чистите поверхность атаки, имеет смысл проверить и другие точки:
- закрыть или ограничить
/wp-login.phpпри массовых брутфорс-атаках; - убедиться, что REST API не отдаёт лишние данные публично;
- убрать дубли архивов, тегов и служебных страниц, если они не нужны для индексации;
- проверить, не создают ли плагины лишние запросы в админке и на фронтенде;
- очистить автозагрузку опций и неиспользуемые плагины.
Если вам нужен именно набор технической чистки, а не точечное отключение одной функции, удобнее делать это через один инструмент, а не вручную разносить правки по теме и серверу.
Когда лучше не отключать XML-RPC полностью
Полное отключение не всегда лучший вариант. Если сайт живёт на старой интеграции, использует удалённую публикацию или завязан на сервис, который вы не можете быстро заменить, лучше сначала ограничить доступ, а не рубить функциональность. В таких случаях безопаснее оставить XML-RPC только для доверенных сценариев и закрыть всё остальное на уровне сети или сервера.
Практический критерий простой: если вы не можете за один вечер перечислить все сервисы, которые обращаются к XML-RPC, сначала проведите аудит. Отключать без понимания зависимостей — это не защита, а лотерея.