Как отключить XML-RPC в WordPress без поломки REST API

Автор: Ярослав Ершов | Опубликовано: 15.08.2026

XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки, шум в логах и непонятные запросы к xmlrpc.php. При этом отключать его вслепую нельзя: у части сайтов через XML-RPC до сих пор работают мобильные клиенты, старые интеграции и внешние сервисы публикации.

Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его без побочных эффектов и как проверить, что REST API и обычная админка продолжают работать как раньше.

Когда XML-RPC действительно можно отключать

Если сайт не использует старые приложения WordPress, удалённую публикацию через сторонние клиенты и сервисы, которые ходят именно в xmlrpc.php, то чаще всего XML-RPC не нужен. Для обычной работы сайта, редактирования записей в админке и большинства современных интеграций достаточно REST API.

Но есть важная оговорка: некоторые внешние сервисы и плагины до сих пор используют XML-RPC неявно. Поэтому правильный порядок действий — сначала диагностика, потом отключение, а не наоборот.

Что обычно ломается при отключении

старые мобильные приложения WordPress;
публикация через внешние редакторы и десктоп-клиенты;
некоторые сервисы автопостинга и мониторинга;
интеграции, которые работают через system.multicall или pingback.ping.

Диагностика: используется ли xmlrpc.php на вашем сайте

Начните с логов веб-сервера и доступа к файлам сайта. Если в логах регулярно встречаются запросы к /xmlrpc.php, это не всегда значит, что XML-RPC нужен. Часто это просто боты, которые проверяют сайт на уязвимости или пытаются подобрать пароль через массовые запросы.

Проверьте три вещи:

Есть ли реальные пользователи или сервисы, которые публикуют через XML-RPC.
Есть ли в логах запросы с успешными ответами, а не только 401/403/404.
Использует ли ваш сайт REST API для внешних интеграций вместо XML-RPC.

Если у вас есть доступ к логам, полезно посмотреть, кто именно обращается к файлу:

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

На shared-хостинге логов может не быть. Тогда проверьте сайт вручную: если вы не используете внешние клиенты WordPress и не помните ни одной интеграции на XML-RPC, вероятность, что он нужен, невысока.

Как отключить XML-RPC: сравнение подходов

Способ	Плюсы	Минусы	Когда выбирать
Плагин безопасности	Быстро, без кода	Лишняя зависимость, не всегда точечное управление	Если нужен простой переключатель и уже есть security-плагин
Код в теме или mu-plugin	Контроль, минимум лишнего	Нужно понимать, где хранится код	Если нужен предсказуемый результат и нет желания ставить ещё один плагин
Отключение на уровне сервера	Работает до PHP и WordPress	Зависит от конфигурации хостинга	Если есть доступ к nginx/apache и нужно отсечь запросы раньше

Пошаговое решение через код

Самый практичный вариант для большинства сайтов — отключить XML-RPC через фильтр WordPress. Это не ломает REST API и не требует правок ядра.

Вариант 1: отключить полностью

Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так код не потеряется при обновлении темы.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

После этого WordPress перестанет принимать XML-RPC-запросы. Если кто-то попытается обратиться к xmlrpc.php, сайт не будет обрабатывать такие вызовы как рабочий канал интеграции.

Вариант 2: оставить XML-RPC, но отключить pingback

Иногда XML-RPC нужен для отдельного сервиса, но pingback только создаёт шум и используется для злоупотреблений. В таком случае можно оставить сам механизм, но убрать pingback-методы.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Это не равно полной защите, но снижает лишнюю нагрузку и убирает один из популярных векторов злоупотребления.

Вариант 3: заблокировать на уровне сервера

Если вы хотите отрезать запросы ещё до загрузки WordPress, можно закрыть доступ к xmlrpc.php в конфигурации веб-сервера. Для nginx это обычно делается отдельным location-блоком.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Этот способ хорош тем, что экономит ресурсы: PHP вообще не стартует для таких запросов. Но применять его стоит только если вы уверены, что XML-RPC нигде не используется.

Проверка результата после внедрения

После отключения не ограничивайтесь тем, что «сайт открылся». Проверьте именно те точки, которые могут сломаться.

Откройте /xmlrpc.php в браузере: если доступ закрыт, вы не должны видеть рабочий ответ XML-RPC.
Проверьте вход в админку и создание/редактирование записей.
Убедитесь, что REST API отвечает корректно, например на /wp-json/.
Посмотрите логи веб-сервера: количество обращений к xmlrpc.php должно либо исчезнуть, либо стать незначимым шумом без успешных вызовов.

Для быстрой проверки REST API можно выполнить запрос из консоли:

curl -I https://example.com/wp-json/

Если ответ идёт с кодом 200 или 301/302 на ожидаемый адрес, REST API жив. Если вы используете внешнюю интеграцию, проверьте её отдельно: авторизацию, получение записей, отправку данных.

Частые ошибки и как их исправить

Отключили XML-RPC, а сервис публикации перестал работать

Значит, у вас был реальный потребитель XML-RPC. Верните доступ временно и переведите интеграцию на REST API, если сервис это поддерживает. Если не поддерживает — оставьте XML-RPC включённым, но ограничьте доступ по IP или закройте pingback.

Поставили security-плагин, но xmlrpc.php всё равно отвечает

Не все плагины блокируют запросы одинаково. Некоторые только отключают отдельные методы, а не весь канал. Проверьте, что именно делает плагин: блокирует ли он сам файл, методы или только уведомления pingback.

Сломали REST API вместе с XML-RPC

Это обычно происходит, если блокировку сделали слишком грубо на уровне сервера и зацепили не тот location или правило. XML-RPC и REST API — разные механизмы. Не блокируйте весь /wp-json/ ради отключения /xmlrpc.php.

Добавили код в родительскую тему

После обновления темы правило исчезнет. Для такого кода используйте дочернюю тему или mu-plugin. Это особенно важно, если сайт обслуживается несколькими разработчиками и правки должны переживать обновления.

Практические меры безопасности после отключения

Отключение XML-RPC — полезный шаг, но не замена нормальной защите входа. Если у вас идут попытки брутфорса, проверьте ещё и:

сложность паролей и наличие двухфакторной аутентификации;
ограничение попыток входа;
актуальность ядра, темы и плагинов;
наличие лишних админов и старых учётных записей;
защиту от массовых запросов на уровне WAF или хостинга.

Если на сайте много технического мусора, дублей и лишних страниц в индексе, имеет смысл дополнительно проверить SEO-настройки и чистку сайта. В таких задачах иногда помогает Clearfy Pro, но только как инструмент для конкретных технических правок, а не как замена ручной проверки.

Короткий чек-лист перед отключением

Проверил, есть ли внешние сервисы, завязанные на XML-RPC.
Посмотрел логи на реальные успешные обращения к xmlrpc.php.
Выбрал способ отключения: код или сервер.
Сохранил изменения в дочерней теме или mu-plugin.
Проверил REST API, админку и внешние интеграции после внедрения.

Если сайт обычный, без старых клиентов и редких интеграций, полное отключение XML-RPC обычно даёт более чистую и предсказуемую конфигурацию. Если же у вас есть зависимость от старого канала, лучше не ломать его «на глаз», а ограничить доступ точечно и постепенно перевести сервисы на REST API.