XML-RPC в WordPress до сих пор часто включён по умолчанию, хотя на многих сайтах он не нужен. Проблема не в самом файле xmlrpc.php, а в том, что через него можно отправлять массовые запросы: подбирать логины, дергать пингбэки, нагружать сайт лишними обращениями. Если вы не используете мобильное приложение WordPress, удалённую публикацию или старые внешние сервисы, XML-RPC обычно проще отключить.
Ниже — не абстрактная теория, а рабочая схема: как понять, нужен ли вам XML-RPC, как отключить его без лишних побочных эффектов и как проверить, что после правки сайт ведёт себя нормально.
Когда XML-RPC действительно мешает
На практике XML-RPC становится проблемой в трёх сценариях: в логах много обращений к /xmlrpc.php, хостинг фиксирует всплески 403/404/POST-запросов, а в панели безопасности появляются попытки подбора паролей через мультизапросы. Иногда сайт не падает, но начинает отвечать медленнее из-за постоянного шума вокруг этого файла.
Если у вас есть интеграции со сторонними сервисами, сначала проверьте, не используют ли они XML-RPC. Это касается старых клиентов публикации, некоторых приложений для удалённого управления контентом и редких сценариев синхронизации. Для обычного сайта на современном WordPress чаще всего достаточно REST API, а не XML-RPC.
Быстрая диагностика проблемы
Перед отключением посмотрите, есть ли реальная зависимость от XML-RPC. Минимальный чек-лист такой:
- в логах сервера есть частые обращения к
xmlrpc.php; - в панели безопасности видны попытки авторизации через XML-RPC;
- вы не используете мобильное приложение WordPress для публикации;
- внешние сервисы синхронизации работают через REST API или обычный HTTP API;
- на сайте нет старых интеграций, которые явно требуют XML-RPC.
Если хотя бы один сервис зависит от него, сначала протестируйте отключение на staging-копии. Это дешевле, чем потом искать, почему перестала работать публикация из внешнего клиента.
Как отключить XML-RPC в WordPress
Есть несколько способов. Самый надёжный для сайта под вашим контролем — отключить обработку на уровне WordPress-кода. Если у вас есть доступ к серверу и вы не хотите ставить лишний плагин, это обычно лучший вариант.
| Способ | Когда подходит | Компромисс |
|---|---|---|
| Код в теме или mu-plugin | Нужен точечный контроль | Требует аккуратного деплоя |
| Плагин безопасности | Уже есть такой плагин в проекте | Добавляет зависимость от настроек плагина |
| Отключение на уровне сервера | Есть доступ к конфигу nginx/apache | Нужно понимать, как устроен сервер |
Вариант через код
Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Этого достаточно, чтобы WordPress перестал принимать XML-RPC-запросы на уровне ядра. Но если вам нужно не просто отключить функциональность, а ещё и отдать корректный ответ для сканеров и ботов, можно добавить отдельную обработку на раннем этапе.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );
Второй вариант жёстче. Он полезен, если вы хотите быстро пресечь обращения к xmlrpc.php, но его стоит использовать только если вы уверены, что XML-RPC нигде не нужен.
Если нужен серверный уровень
На nginx можно закрыть доступ к файлу напрямую. Это не заменяет отключение в WordPress, но снижает шум от лишних запросов.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют правила в .htaccess или конфиге виртуального хоста. Смысл тот же: не давать файлу обрабатываться, если он вам не нужен. Но перед этим проверьте, что сервер действительно читает нужный конфиг, иначе вы получите иллюзию защиты.
Что может сломаться после отключения
Чаще всего ничего критичного не ломается. Но есть несколько типичных зависимостей, о которых забывают:
- мобильное приложение WordPress для удалённой публикации;
- старые внешние клиенты и сервисы автопостинга;
- некоторые интеграции с legacy-системами;
- редкие плагины, которые до сих пор используют XML-RPC для синхронизации.
Если сайт — обычный блог, корпоративный ресурс или контентный проект без старых интеграций, риск минимален. Если же у вас есть автоматизация публикаций, сначала найдите, чем именно она пользуется: XML-RPC, REST API или прямым доступом к базе. Это разные вещи, и отключение одного канала не должно ломать другой.
Как проверить, что решение сработало
После внедрения не ограничивайтесь тем, что страница админки открывается. Проверьте именно то, что вы меняли.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что ответ не содержит рабочий XML-RPC endpoint.
- Посмотрите логи веб-сервера: обращений к файлу должно стать меньше или они должны получать отказ.
- Проверьте, работают ли обычные публикации, вход в админку и REST API.
- Если есть внешняя интеграция, выполните тестовую отправку записи или запроса.
Простой тест через консоль выглядит так:
curl -I https://example.com/xmlrpc.php
Если вы закрывали файл через WordPress-фильтр, ответ может отличаться в зависимости от сервера и кэша, но сам endpoint не должен оставаться доступным как рабочий канал для запросов. Для более точной проверки отправьте POST-запрос из тестового клиента, если такая возможность есть.
Частые ошибки и как их исправить
Отключили XML-RPC в теме, а потом обновили её
Это самая банальная ошибка. Настройка исчезает вместе с обновлением. Решение простое: переносите код в mu-plugin или в собственный мини-плагин, а не в тему.
Закрыли файл на сервере, но WordPress всё ещё отвечает
Значит, правило не применилось или запрос идёт через другой слой. Проверьте конфигурацию nginx/apache, перезапуск сервера и наличие кэширующего прокси. Иногда сайт отдаёт старый ответ из кэша, и кажется, что защита не работает.
Сломали интеграцию, не проверив зависимость
Если внешний сервис перестал публиковать записи, не ищите проблему везде подряд. Сначала проверьте, не был ли он завязан именно на XML-RPC. Если да, переводите его на REST API или другой поддерживаемый способ интеграции.
Поставили несколько решений сразу
Когда XML-RPC отключают и плагином, и кодом, и серверным правилом, потом сложно понять, что именно дало эффект или сломало совместимость. Лучше внедрять по одному изменению и фиксировать результат.
Практические советы по безопасности и производительности
Если цель — не только убрать лишний endpoint, но и снизить поверхность атаки, не ограничивайтесь одним файлом. Проверьте, не используются ли на сайте старые плагины с устаревшими способами авторизации, и убедитесь, что REST API не открыт там, где он не нужен публично. Полностью закрывать REST API обычно не стоит: он нужен ядру, редактору и многим современным интеграциям.
Для проектов, где важна чистка сайта и снижение технического шума, удобно держать такие настройки в одном месте: отключение лишних эмиттеров, чистка дублей, контроль индексации и базовая оптимизация. Если вы уже используете набор инструментов вроде Clearfy Pro, проверьте, не дублируете ли вы одну и ту же защиту кодом и настройками плагина одновременно.
Главный принцип здесь простой: отключайте только то, что реально не используется, и проверяйте зависимые интеграции до выката. Тогда защита от лишних запросов не превратится в ещё одну причину инцидента.