XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам к /xmlrpc.php, попыткам перебора паролей и странной нагрузке на сайт. Если вы не используете мобильное приложение WordPress, Jetpack или внешние сервисы, которые завязаны на XML-RPC, этот интерфейс обычно можно отключить без потерь для обычной работы сайта.
Ниже — не абстрактная теория, а рабочий сценарий: как понять, нужен ли вам XML-RPC, чем его отключать, как не сломать интеграции и как проверить, что защита действительно сработала.
Когда XML-RPC становится проблемой
Сам по себе файл xmlrpc.php не является уязвимостью, но он часто используется как точка входа для атак. Самые типичные сценарии — перебор учётных данных через метод system.multicall, массовые запросы к сайту и попытки обойти ограничения на логин. На слабых хостингах это ещё и лишняя нагрузка: один внешний бот может отправлять много запросов, а WordPress будет каждый раз поднимать ядро и выполнять обработку.
Что обычно видно в логах
Если у вас есть доступ к access log веб-сервера или логам защиты, ищите повторяющиеся POST-запросы к /xmlrpc.php. Часто они идут с одинаковых IP, короткими интервалами и с большим количеством неудачных попыток авторизации. В панели хостинга это может выглядеть как всплеск запросов без заметного роста обычного трафика.
Ещё один признак — жалобы на нагрузку без видимой причины. Если сайт не менялся, а CPU или количество PHP-воркеров растёт, полезно проверить именно этот endpoint, а не только кэш.
Как понять, нужен ли вам XML-RPC
Перед отключением стоит проверить реальные зависимости. XML-RPC нужен не всем, но если вы пользуетесь некоторыми внешними инструментами, отключение может сломать публикацию или синхронизацию.
- Мобильное приложение WordPress для публикации и редактирования записей.
- Jetpack и отдельные его функции, которые используют удалённое соединение.
- Сторонние сервисы автопостинга и публикации через XML-RPC.
- Некоторые старые интеграции с десктопными клиентами.
Если у вас обычный сайт с входом в админку через браузер, без мобильного приложения и без внешних публикаций, XML-RPC чаще всего не нужен.
| Подход | Когда подходит | Минус |
|---|---|---|
| Отключить через плагин | Нужно быстро и без правок сервера | Лишняя зависимость от плагина |
| Отключить кодом | Есть доступ к теме или mu-plugin | Нужно аккуратно обновлять код |
| Закрыть на уровне сервера | Нужна жёсткая защита и минимум PHP-запросов | Можно случайно сломать нужную интеграцию |
Пошаговое решение: как отключить XML-RPC
Вариант 1. Отключение кодом
Если вы управляете сайтом как разработчик, самый прозрачный способ — добавить фильтр в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так вы не зависите от настроек плагина и не теряете контроль после обновлений.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC на уровне WordPress. Запросы к /xmlrpc.php перестанут обрабатываться штатно, и сайт будет отвечать ошибкой доступа или недоступности метода.
Вариант 2. Отключение через mu-plugin
Если не хотите трогать тему, создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Mu-plugin загружается раньше обычных плагинов и не зависит от активации в админке.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это удобно, если у вас несколько сайтов или вы не хотите, чтобы отключение потерялось при смене темы.
Вариант 3. Блокировка на уровне веб-сервера
Если задача именно в снижении нагрузки и отсечении мусорных запросов, можно закрыть доступ к xmlrpc.php на уровне Nginx или Apache. Но здесь важно не путать защиту с «ломанием» функциональности: если XML-RPC нужен, серверная блокировка его полностью убьёт.
Для Apache часто используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика обычно выносится в конфиг сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если вы не уверены, что конфиг применится корректно, сначала проверьте его в тестовой среде. Ошибка в серверном правиле может затронуть не только XML-RPC, но и весь сайт, если блок вставлен не в тот блок конфигурации.
Что проверить после отключения
Отключение считается успешным не тогда, когда «вроде ничего не сломалось», а когда вы подтвердили результат с двух сторон: запросы больше не проходят, а нужные сценарии по-прежнему работают.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере. В норме вы не должны видеть рабочий интерфейс XML-RPC. - Проверьте логи веб-сервера: запросы к этому файлу должны либо исчезнуть, либо получать отказ.
- Если использовали плагин или код, убедитесь, что обычный вход в админку и публикация записей работают как раньше.
- Если у вас есть Jetpack, мобильное приложение или внешняя интеграция, протестируйте именно их, а не только главную страницу.
Для быстрой проверки можно отправить тестовый POST-запрос, но в большинстве случаев достаточно посмотреть статус ответа и логи. Если endpoint закрыт корректно, он не должен продолжать обрабатываться как обычный PHP-скрипт.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Это ожидаемо. Если Jetpack или другой сервис использует XML-RPC, вам нужно либо оставить его включённым, либо заменить способ интеграции. Не пытайтесь «частично» блокировать endpoint без понимания, какие именно методы используются: это обычно заканчивается нестабильной работой.
Добавили код в родительскую тему
После обновления темы правило исчезнет. Если отключение нужно надолго, используйте дочернюю тему или mu-plugin. Для технических ограничений mu-plugin обычно надёжнее.
Закрыли XML-RPC на сервере, но в логах всё равно есть запросы
Это нормально: запросы могут доходить до веб-сервера, но получать отказ. Если цель — убрать именно нагрузку на PHP, убедитесь, что блокировка происходит до передачи запроса в WordPress. Если цель — просто не дать атаке пройти дальше, отказ на уровне сервера уже полезен.
Поставили плагин, который «отключает всё», и сломали API
Некоторые плагины безопасности блокируют не только XML-RPC, но и другие механизмы, если настройки слишком жёсткие. Всегда проверяйте, что именно выключено: иногда удобнее использовать точечный фильтр xmlrpc_enabled, чем набор общих ограничений.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — только часть меры. Полезно дополнительно проверить, не открыт ли у вас лишний вход в админку через слабые пароли, нет ли старых пользователей с правами администратора и не включены ли плагины, которые сами создают лишнюю поверхность атаки.
- Оставьте только те плагины, которые реально используете.
- Проверьте, нет ли внешних сервисов, завязанных на удалённую публикацию.
- Если на сайте уже есть защита от brute force, убедитесь, что она не конфликтует с кэшем и страницей входа.
- Для сайтов с высокой нагрузкой полезно смотреть не только на безопасность, но и на количество обращений к PHP без кэширования.
Если вам нужен более широкий набор технических ограничений и чистка лишних функций WordPress, можно посмотреть в сторону Clearfy Pro: у него есть инструменты для удаления части мусора и отключения ненужных возможностей, но применять такие настройки стоит точечно, после проверки зависимостей. Ссылка: Clearfy Pro.
Мини-чек-лист перед отключением
- Проверили, используется ли мобильное приложение WordPress.
- Убедились, что Jetpack и внешние интеграции не завязаны на XML-RPC.
- Выбрали способ отключения: код, mu-plugin или сервер.
- Проверили результат через
/xmlrpc.phpи логи. - Сохранили способ отката на случай, если интеграция всё же нужна.
Если подойти к задаче аккуратно, XML-RPC можно отключить без побочных эффектов. Главное — не путать защиту от атак с универсальной «галочкой безопасности»: сначала проверьте зависимости, потом режьте доступ, и только после этого считайте задачу закрытой.