XML-RPC в WordPress часто отключают как «лишний» интерфейс, но на практике проблема обычно шире: на сайте остаются открытыми точки доступа, которые не нужны ни редакторам, ни интеграциям, ни поисковым роботам. Если задача — сократить поверхность атаки и убрать шум в логах, лучше смотреть не только на сам xmlrpc.php, но и на связанные сценарии: REST API, авторизацию, служебные запросы и внешние пинги.
Когда отключение XML-RPC действительно уместно
Сценарий простой: вы не используете старые мобильные клиенты WordPress, не подключали Jetpack через XML-RPC, не принимаете публикации через внешние сервисы и не завязаны на сторонние интеграции, которым нужен именно этот протокол. Тогда отключение оправдано. Если хотя бы один из этих пунктов важен, сначала проверьте зависимость, а уже потом закрывайте доступ.
Что обычно ломается после отключения
Чаще всего перестают работать:
- старые приложения WordPress для публикации и редактирования;
- некоторые сценарии Jetpack;
- внешние сервисы, которые отправляют записи через XML-RPC;
- редкие плагины синхронизации, написанные под старые интеграции.
Если сайт обычный контентный и публикация идёт из админки, риск минимальный. Но это нужно проверить до внедрения, а не после.
Диагностика: есть ли у сайта реальная зависимость от XML-RPC
Начните с простого теста. Откройте /xmlrpc.php в браузере или выполните запрос из консоли. Сам по себе ответ сервера ещё не означает, что протокол используется, но он показывает, что точка доступа открыта.
curl -i https://example.com/xmlrpc.phpЕсли в ответе вы видите что-то вроде XML-RPC server accepts POST requests only., файл доступен. Дальше проверьте логи веб-сервера: если туда регулярно прилетают POST-запросы к xmlrpc.php, это уже не просто «наследие», а активная поверхность атаки.
Полезно также посмотреть, не используется ли Jetpack или другой плагин, который может опираться на XML-RPC. Для этого не надо гадать по названию плагина — откройте его настройки и проверьте, есть ли упоминание remote publishing, mobile app, XML-RPC или legacy connection.
Как отключить XML-RPC без лишних рисков
Есть три рабочих подхода: через код, через веб-сервер и через плагин безопасности. Для большинства сайтов достаточно кода в functions.php дочерней темы или в небольшом must-use плагине. Это проще откатить и легче контролировать в репозитории.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в WordPress | Легко версионировать, быстро откатить | Не закрывает запрос на уровне сервера | Если нужен управляемый и прозрачный вариант |
| .htaccess / nginx | Режет запрос раньше WordPress | Нужно аккуратно править конфиг | Если есть доступ к конфигу и нужен жёсткий блок |
| Плагин безопасности | Быстро включить | Зависимость от стороннего кода | Если нужен временный или административный вариант |
Вариант 1: отключение через код
Этот способ не ломает сайт, если вы не используете XML-RPC. Добавьте код в дочернюю тему или в собственный мини-плагин:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить функциональность, а ещё и вернуть 403 на сам файл, можно дополнить блокировкой на уровне запроса:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
nocache_headers();
exit;
}
} );Первый вариант обычно достаточно. Второй полезен, если хотите, чтобы запросы к xmlrpc.php не доходили до логики WordPress дальше минимально необходимого уровня.
Вариант 2: блокировка на уровне сервера
Если сайт работает на Apache, можно закрыть файл в .htaccess. Это особенно полезно, когда к сайту идёт много мусорных запросов и вы хотите отсечь их до PHP.
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика зависит от конфигурации, но смысл тот же: вернуть 403 на запрос к /xmlrpc.php. Делайте это только если понимаете, где у вас лежит server block и как потом проверить reload конфигурации.
Вариант 3: плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, можно использовать его настройку. Но не стоит ставить отдельный плагин только ради одной галочки, если ту же задачу решает одна строка кода. Лишний плагин — это ещё один слой обновлений, совместимости и потенциальных конфликтов.
Если вы уже используете Clearfy Pro, проверьте, нет ли у него готовой опции для отключения XML-RPC и других лишних функций. В таких случаях удобнее централизовать техническую чистку в одном месте, чем размазывать её по теме и нескольким плагинам.
Проверка результата после внедрения
После изменений не ограничивайтесь тем, что сайт «открылся». Проверьте именно целевую точку доступа и связанные сценарии.
- Откройте
/xmlrpc.phpи убедитесь, что он возвращает403или не даёт выполнить POST-запрос. - Проверьте, не появились ли ошибки в логах PHP и веб-сервера.
- Если используете Jetpack или внешнюю интеграцию, протестируйте подключение отдельно.
- Проверьте, не изменилось ли поведение редактора, публикации и REST API.
Для быстрой проверки POST-запроса можно использовать curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли блокировка работает, вы должны увидеть отказ в доступе или другой контролируемый ответ, а не нормальную обработку XML-RPC-запроса.
Частые ошибки и как их исправить
Отключили XML-RPC, но оставили активный внешний сервис
Это самая частая ситуация. Сайт вроде бы работает, но интеграция перестаёт синхронизироваться. Решение одно: до отключения собрать список сервисов, которые публикуют или читают данные через WordPress, и проверить их документацию.
Блокируют файл в .htaccess, но забывают про nginx
Если сайт стоит за nginx или прокси, правило в .htaccess может вообще не сработать. В этом случае блокируйте запрос на том уровне, где он реально обрабатывается.
Путают XML-RPC и REST API
Отключение xmlrpc.php не выключает REST API. Это разные механизмы. Если после правок у вас «сломалась» интеграция, сначала проверьте, что именно использовалось: XML-RPC, REST API или обычный вход в админку.
Ставят тяжёлый плагин ради одной функции
Если задача только в отключении XML-RPC, отдельный плагин часто избыточен. Лучше использовать код или уже установленный инструмент, который закрывает сразу несколько технических проблем: лишние запросы, дубли, служебные endpoints, мусорные скрипты.
Что ещё имеет смысл закрыть вместе с XML-RPC
Если цель — уменьшить поверхность атаки и количество лишних запросов, проверьте соседние настройки. Иногда эффект от них заметнее, чем от одного отключённого файла.
- убрать emoji-скрипты, если они не нужны;
- отключить лишние эмбеддинги;
- проверить, не торчит ли открытый REST API там, где он не нужен внешним сервисам;
- убрать неиспользуемые плагины и темы;
- ограничить доступ к административным точкам входа только там, где это реально допустимо.
Для сайтов, где важна техническая чистота, удобно держать такие настройки в одном месте и не разносить их по нескольким файлам. Это снижает шанс забыть, что именно было отключено, и упрощает аудит после обновлений.
Как понять, что решение сработало и не создало побочных эффектов
Итоговая проверка должна быть короткой и практичной. Если xmlrpc.php больше не отвечает как рабочий endpoint, в логах нет новых обращений от старых клиентов, а публикация через админку и REST API не пострадала — задача решена. После этого стоит ещё раз пройтись по журналам сервера через день-два: иногда внешние сервисы пытаются переподключиться с задержкой, и это быстро показывает, что было завязано на XML-RPC на самом деле.
Если вам нужен не только этот точечный запрет, но и общая чистка сайта от лишних технических функций, лучше делать её по чек-листу: сначала инвентаризация интеграций, потом отключение, потом проверка логов и откатный план. Так вы не превращаете защиту в угадайку.