Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

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

• в логах видны частые обращения к /xmlrpc.php;
• идут попытки перебора логина через system.multicall;
• сайт не использует мобильное приложение WordPress;
• не подключён Jetpack или он работает без XML-RPC;
• нет старых интеграций публикации по XML-RPC.

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

Диагностика: используется ли XML-RPC на вашем сайте

Перед изменениями проверьте, есть ли реальные обращения к этому файлу. Самый простой способ — посмотреть access-логи веб-сервера или логи в панели хостинга. Ищите запросы к /xmlrpc.php. Если их много и они однотипные, это уже повод для ограничения доступа.

Можно проверить и вручную. Откройте в браузере https://ваш-домен.ru/xmlrpc.php. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что он нужен, но подтверждает, что файл доступен извне.

Если хотите быстро понять, не завязаны ли на него сервисы, проверьте:

• подключён ли Jetpack;
• используется ли мобильное приложение WordPress;
• есть ли внешние сервисы автопостинга;
• настроены ли интеграции через старые клиенты блог-платформ.

Что ломается чаще всего

Самая частая ошибка — отключить XML-RPC на боевом сайте, а потом обнаружить, что перестали работать публикации из стороннего сервиса. Вторая типовая проблема — блокировать файл только на уровне WordPress, но оставить его доступным на уровне сервера. В таком случае запросы всё равно доходят до PHP и создают нагрузку.

Способы отключения: код, сервер или плагин

Есть три рабочих подхода. Выбор зависит от того, есть ли доступ к конфигу сервера и хотите ли вы управлять этим через код темы или отдельный плагин.

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

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

Если вам нужно отключить XML-RPC именно на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так изменение не потеряется при обновлении темы.

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

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

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

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

Отключение на уровне сервера

Если задача — не допускать лишние запросы вообще, лучше блокировать xmlrpc.php на веб-сервере. Это особенно полезно на сайтах с высокой нагрузкой или частыми атаками по логам.

Для nginx

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

После этого запросы к файлу будут отрезаны до передачи в PHP. Это экономит ресурсы и уменьшает шум в логах.

Для Apache

<Files xmlrpc.php>
    Require all denied
</Files>

Если у вас shared-хостинг и нет доступа к конфигу, этот способ может быть недоступен. Тогда остаётся вариант через WordPress или плагин безопасности.

Если нужен плагин: когда это оправдано

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

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

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

После отключения обязательно проверьте не только сам файл, но и функциональность, которая могла быть завязана на XML-RPC.

• Откройте /xmlrpc.php в браузере или через curl.
• Проверьте, что ответ стал 403 Forbidden или что WordPress больше не принимает XML-RPC.
• Убедитесь, что публикация из внешних сервисов не нужна или продолжает работать.
• Посмотрите логи сайта: запросы к xmlrpc.php должны исчезнуть или начать блокироваться на сервере.

Для быстрой проверки через командную строку можно использовать такой запрос:

curl -I https://example.com/xmlrpc.php

Если всё настроено на уровне сервера, вы увидите отказ до загрузки WordPress. Если отключение сделано только через фильтр, ответ может отличаться, но сам XML-RPC работать не должен.

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

Отключили XML-RPC, а Jetpack перестал синхронизироваться

Причина обычно в том, что Jetpack всё ещё использует XML-RPC для части функций. Решение простое: проверьте, какие модули Jetpack реально нужны, и не отключайте XML-RPC, пока не убедитесь, что альтернативный канал связи работает.

Блокировка стоит в WordPress, но атаки всё равно видны в логах

Это значит, что запросы доходят до PHP. Если цель — снизить нагрузку, переносите блокировку на nginx или Apache.

Сайт с внешним автопостингом перестал публиковать записи

Значит, интеграция использовала XML-RPC. В этом случае либо возвращайте доступ, либо переводите интеграцию на REST API, если сервис это поддерживает.

Поставили плагин безопасности, но ничего не изменилось

Проверьте, действительно ли опция активна и не конфликтует ли с кэшем или другой защитой на уровне хостинга. Иногда плагин только меняет поведение WordPress, но не режет сам запрос раньше PHP.

Практические советы по безопасности и производительности

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

• ограничение попыток входа;
• двухфакторная аутентификация для админов;
• отключение ненужных API и служебных функций;
• актуальные версии ядра, темы и плагинов;
• блокировка лишних точек входа на уровне сервера.

Отдельно проверьте REST API. Его отключать без причины не стоит: многие современные плагины и редактор Gutenberg используют именно его. XML-RPC и REST API — не одно и то же, и путать их не нужно.

Если задача сайта — минимизировать поверхность атаки и убрать технический мусор, удобно держать такие настройки в одном месте и документировать, что именно отключено. Тогда через полгода не придётся гадать, почему перестал работать старый сервис или откуда взялась лишняя нагрузка.