XML-RPC в WordPress до сих пор встречается на живых сайтах, хотя для большинства проектов он давно не нужен. Проблема в том, что его часто отключают «на всякий случай» и потом внезапно ломают мобильное приложение, удалённую публикацию, Jetpack или интеграцию с внешним сервисом. Поэтому правильный подход здесь не «выключить всё», а сначала понять, кто именно использует endpoint /xmlrpc.php, и только потом закрывать доступ.
Если у вас сайт на обычном хостинге, без старых интеграций и без удалённой публикации через сторонние клиенты, XML-RPC чаще всего можно отключить. Но делать это лучше осознанно: через код, через плагин или на уровне веб-сервера — в зависимости от того, что уже работает на сайте.
Когда XML-RPC действительно мешает
Чаще всего его отключают по трём причинам: лишняя поверхность атаки, брутфорс-запросы к xmlrpc.php и дублирование функциональности, которая уже есть через REST API. На практике это выглядит так: в логах много POST-запросов к /xmlrpc.php, в панели безопасности срабатывают предупреждения, а сервер тратит ресурсы на обработку мусорных обращений.
Но есть и обратная сторона. XML-RPC может быть нужен, если вы используете:
- Jetpack и некоторые его функции;
- старые мобильные клиенты WordPress;
- удалённую публикацию из внешних редакторов;
- интеграции, которые до сих пор ходят именно в XML-RPC, а не в REST API.
Диагностика: нужен ли он вашему сайту
Перед отключением проверьте, есть ли реальные обращения к endpoint. Самый простой способ — посмотреть access log веб-сервера или логи хостинга. Ищите строки с /xmlrpc.php. Если запросы идут только от ботов и сканеров, отключение обычно безопасно. Если видите обращения от Jetpack, приложения или внешнего сервиса — сначала разберитесь, чем это заменить.
Что проверить вручную
- Установлен ли Jetpack и включены ли его функции, завязанные на XML-RPC.
- Используются ли мобильные приложения WordPress для публикации.
- Есть ли сторонние сервисы автопостинга или синхронизации.
- Нет ли в логах ошибок авторизации именно через XML-RPC.
Если у вас есть доступ к WP-CLI, можно быстро проверить, не включён ли Jetpack и какие плагины вообще стоят. Но сам факт наличия плагина ещё не означает, что XML-RPC нужен. Смотрите именно на сценарий использования, а не на список установленных расширений.
Пошаговое решение: как отключить XML-RPC
Ниже три рабочих варианта. Выбирайте тот, который соответствует вашей инфраструктуре.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Через код | Нужен контроль внутри темы или mu-plugin | Прозрачно, легко откатить | Не защищает от самого запроса на уровне сервера |
| Через плагин безопасности | Нужна настройка без правки кода | Быстро, удобно для админов | Лишняя зависимость от плагина |
| На уровне nginx/apache | Нужна жёсткая блокировка | Снимает нагрузку раньше WordPress | Требует доступа к конфигу сервера |
Вариант 1: отключить XML-RPC через код
Самый понятный способ — добавить фильтр xmlrpc_enabled. Лучше делать это в mu-plugin или в небольшом плагине, а не в functions.php активной темы. Тогда настройка не пропадёт при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Если нужно не просто отключить XML-RPC, а ещё и отвечать 403 на сам запрос, можно дополнительно отдать заголовок и завершить выполнение раньше. Но в большинстве случаев фильтра достаточно.
Вариант 2: закрыть доступ на сервере
Если вы хотите отрезать запросы ещё до загрузки WordPress, используйте правила веб-сервера. Это особенно полезно, когда на сайт идёт много мусорных обращений и вы хотите снизить нагрузку.
# nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют <Files xmlrpc.php> в конфиге или .htaccess, если хостинг это позволяет. Смысл тот же: не отдавать обработку WordPress на каждый посторонний запрос.
Вариант 3: отключить через плагин
Если на сайте уже стоит плагин безопасности, проверьте, нет ли в нём отдельной опции для XML-RPC. Это удобнее для администраторов без доступа к коду, но важно понимать, что плагин должен реально блокировать endpoint, а не просто скрывать уведомление в панели.
Если вы уже используете набор для технической чистки сайта, например Clearfy Pro, проверьте, не закрывает ли он XML-RPC вместе с другими лишними функциями. Это полезно, когда нужно убрать дубли и сократить поверхность атаки без ручного редактирования конфигов.
Как проверить, что решение сработало
После отключения откройте https://ваш-домен.ru/xmlrpc.php в браузере или отправьте тестовый запрос через curl. Поведение зависит от способа блокировки, но в норме вы не должны получать рабочий XML-RPC-ответ.
curl -i https://example.com/xmlrpc.phpЧто считать успешным результатом:
- endpoint не отвечает как рабочий XML-RPC;
- в логах больше нет успешных обращений к нему;
- Jetpack и другие нужные интеграции не сломались;
- в админке не появилось ошибок публикации или синхронизации.
Если вы закрывали доступ через nginx или Apache, проверьте ещё и код ответа. Для жёсткой блокировки это обычно должен быть 403. Если вы использовали фильтр WordPress, запрос может доходить до PHP, но функционально XML-RPC будет отключён.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий. Не надо сразу откатывать всё назад. Сначала проверьте, действительно ли вам нужны функции Jetpack, завязанные на XML-RPC. Иногда достаточно отключить только часть модулей или перейти на альтернативный способ связи, если он доступен в вашей конфигурации.
Добавили код в functions.php и забыли про тему
После смены темы защита исчезает. Для технических ограничений лучше использовать mu-plugin или небольшой плагин. Тогда правило живёт отдельно от дизайна и не теряется при обновлениях.
Закрыли endpoint на сервере, но не проверили логи
Если у вас есть легитимный сервис, который продолжает стучаться в /xmlrpc.php, вы увидите ошибки только по факту поломки. После блокировки обязательно смотрите access log и журналы ошибок хотя бы несколько дней, если сайт активно интегрирован с внешними инструментами.
Поставили security-плагин и думают, что вопрос закрыт
Не у всех плагинов одинаковая логика. Одни отключают XML-RPC полностью, другие только ограничивают отдельные методы, третьи вообще не трогают endpoint. Перед внедрением нужно открыть настройки и понять, что именно меняется.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC само по себе не заменяет базовую гигиену. Если сайт регулярно атакуют, полезно дополнительно:
- ограничить частые запросы к
/wp-login.phpи/xmlrpc.phpна уровне WAF или сервера; - включить двухфакторную аутентификацию для админов;
- проверить, не открыты ли лишние REST endpoints для публичного доступа;
- убрать неиспользуемые плагины и темы;
- сократить количество тяжёлых плагинов, которые нагружают админку и фронтенд.
Если вам нужен именно технический аудит и чистка лишнего функционала, удобно сначала собрать список того, что реально используется на сайте, а уже потом резать лишнее. Иначе легко отключить не ту интеграцию и потратить время на откат.
Когда XML-RPC лучше не трогать
Не отключайте его вслепую, если сайт живёт на старой интеграции, где нет быстрой замены. Это касается проектов с внешними редакторами, legacy-автопостингом и частью корпоративных сценариев, где WordPress — не единственный источник контента. В таких случаях сначала тестируйте на staging-копии, а потом переносите изменения на продакшен.
Если нужен более широкий разбор дублей, лишних модулей и технической чистки сайта, такие задачи обычно решают вместе: отключают ненужные endpoints, убирают дубли мета-тегов, чистят head и сокращают лишние запросы. Тогда эффект заметен не только в безопасности, но и в общей стабильности сайта.