XML-RPC в WordPress часто отключают по одной причине: он открывает лишнюю поверхность атаки и почти никогда не нужен на обычном сайте. Но у этой настройки есть нюанс — если вы пользуетесь мобильным приложением WordPress, внешними сервисами публикации или старыми интеграциями, можно случайно отрезать рабочий сценарий. Поэтому правильный подход здесь не «выключить всё подряд», а сначала понять, кто именно ходит в /xmlrpc.php.
Когда XML-RPC действительно стоит отключать
Если сайт работает как обычный корпоративный проект, блог или контентный портал, а публикация идёт через админку WordPress, XML-RPC чаще всего не нужен. Его отключение полезно, когда вы хотите убрать лишний вход для перебора паролей и сократить шум в логах от запросов к xmlrpc.php.
Но если у вас есть хотя бы один из этих сценариев, сначала проверьте совместимость:
- мобильное приложение WordPress для публикации;
- старые внешние сервисы, которые отправляют записи через XML-RPC;
- интеграции с удалёнными редакторами и некоторыми десктопными клиентами;
- устаревшие плагины синхронизации контента.
Диагностика: кто обращается к xmlrpc.php
Перед отключением посмотрите, есть ли реальные запросы к этому файлу. На небольшом сайте это можно сделать через логи веб-сервера или через инструменты хостинга. Ищите строки с xmlrpc.php, а также частые POST-запросы с одинаковых IP. Если запросы идут только от ботов с попытками подбора пароля, это хороший кандидат на отключение.
Если доступа к логам нет, можно временно проверить ответ сервера вручную:
curl -I https://example.com/xmlrpc.phpНормальный активный XML-RPC обычно отвечает не как обычная статическая страница. Если после отключения вы увидите 403 Forbidden или 404 Not Found, значит точка входа закрыта. Но сам по себе код ответа ещё не доказывает, что всё безопасно: важно убедиться, что нужные интеграции не перестали работать.
Как отключить XML-RPC: два рабочих варианта
Вариант 1. Через код в functions.php или mu-plugin
Если вы контролируете тему или используете must-use плагин, можно отключить XML-RPC на уровне WordPress. Это удобно, когда не хочется ставить ещё один плагин ради одной настройки.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Лучше добавлять такой код не в активную тему, а в отдельный mu-plugin, если сайт обслуживается командой и тема может меняться. Тогда настройка не потеряется при обновлении дизайна.
Пример минимального mu-plugin:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Вариант 2. Через плагин безопасности или оптимизации
Если на сайте уже стоит плагин для технической чистки, отключение XML-RPC можно сделать там же. Например, в Clearfy Pro есть набор настроек для закрытия лишних технических возможностей WordPress. Это удобно, когда вы хотите держать такие правки в одном месте и не разбрасывать их по теме и отдельным сниппетам.
Плюс плагина — настройку проще откатить без правки кода. Минус — ещё одна зависимость в админке. Для небольшого сайта кодовый вариант обычно проще и прозрачнее.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в mu-plugin | Не зависит от темы, быстро, прозрачно | Нужен доступ к файлам |
| Плагин | Удобно для команды, можно отключить без кода | Ещё один плагин и ещё одна точка настройки |
| Серверный блок | Закрывает запросы до WordPress | Нужны права на конфиг веб-сервера |
Если нужен не полный запрет, а частичное ограничение
Иногда XML-RPC нужен только для одной интеграции, а всё остальное лучше закрыть. В таком случае не стоит рубить доступ без проверки. Сначала выясните, можно ли заменить старый сценарий на REST API WordPress или на нативную интеграцию сервиса. Для современных проектов это обычно надёжнее и проще в сопровождении.
Если вы всё же оставляете XML-RPC, как минимум проверьте, не используется ли метод system.multicall для массовых попыток авторизации. Некоторые хостинги и WAF умеют ограничивать такие запросы на уровне сервера, не отключая весь механизм целиком.
Проверка результата после внедрения
После отключения проверьте не только код ответа, но и реальные сценарии.
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт. - Попробуйте войти в мобильное приложение WordPress, если вы им пользуетесь.
- Проверьте внешние сервисы публикации и автопостинга.
- Посмотрите логи сервера: запросы к
xmlrpc.phpдолжны исчезнуть или получать отказ.
Если после отключения редакторы жалуются на ошибки публикации, не возвращайте XML-RPC «на всякий случай». Сначала определите, какой именно сервис сломался, и есть ли у него современная альтернатива.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли мобильную публикацию
Это типичная ситуация, когда настройку вносят без проверки рабочих сценариев. Решение простое: либо вернуть XML-RPC, либо перевести публикацию на админку WordPress и REST API, если приложение это поддерживает.
Закрыли файл на уровне сервера, но WordPress всё равно отвечает
Так бывает, если правило добавили не в тот блок конфигурации или его перебивает другое правило. Проверьте порядок директив в Nginx или .htaccess, а затем повторите запрос к /xmlrpc.php.
Использовали плагин, но забыли про кеш
После изменения настроек очистите кеш страницы и, если есть, кеш на уровне сервера или CDN. Иначе можно увидеть старый ответ и решить, что отключение не сработало.
Спрятали проблему вместо решения
Иногда администраторы просто блокируют URL в robots.txt или через редирект. Это не равно защите. Если цель — уменьшить риск атак, нужен именно отказ в доступе, а не косметическое скрытие адреса.
Практика безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из лишних входов. Это особенно полезно на сайтах, где нет причин держать старые механизмы публикации. В паре с этим обычно имеет смысл проверить:
- ограничение попыток входа;
- наличие актуальных обновлений ядра, темы и плагинов;
- отсутствие лишних REST-эндпоинтов от старых плагинов;
- логи 403/401 на предмет повторяющихся атак.
Если вы ведёте несколько проектов и хотите собрать базовую техническую гигиену в одном месте, такие настройки удобно держать в одном инструменте, а не размазывать по коду темы. Но для одиночного сайта проще и надёжнее оставить только тот способ, который вы реально сможете поддерживать через полгода.
Короткий чек-лист перед отключением
- Проверил, использует ли сайт мобильное приложение WordPress.
- Посмотрел логи на обращения к
xmlrpc.php. - Убедился, что внешние сервисы публикации не завязаны на XML-RPC.
- Выбрал способ отключения: код, плагин или серверное правило.
- После изменения проверил ответ
/xmlrpc.phpи работу редакторов.
Если нужен самый безопасный путь для обычного сайта, начинайте с диагностики логов, затем отключайте XML-RPC через код или через технический плагин, и только после этого проверяйте реальные интеграции. Так вы убираете лишнюю точку атаки без сюрпризов для редакторов и автоматизации.