XML-RPC в WordPress часто отключают «на всякий случай», а потом получают неожиданные побочные эффекты: перестаёт работать мобильное приложение, внешние сервисы публикации, старые интеграции с Jetpack или удалённым управлением. Поэтому правильный вопрос звучит не «как выключить», а «что именно у меня использует XML-RPC и можно ли это убрать без потерь».
Если задача — закрыть лишнюю поверхность атаки и убрать ненужные запросы, отключение XML-RPC действительно имеет смысл. Но делать это лучше после диагностики, а не вслепую.
Когда XML-RPC мешает и почему его отключают
XML-RPC — это старый механизм удалённого взаимодействия с WordPress. Через него можно публиковать записи, управлять комментариями и выполнять некоторые действия удалённо. На практике чаще всего он нужен только для старых клиентов и отдельных интеграций. Если вы ими не пользуетесь, XML-RPC становится лишней точкой входа для брутфорса и запросов, которые нагружают сайт.
Типичный сценарий: в логах много обращений к /xmlrpc.php, а сайт работает на обычном веб-интерфейсе и REST API. В таком случае отключение XML-RPC обычно оправдано. Но если у вас подключён внешний редактор, мобильное приложение WordPress или старый сервис автопостинга, сначала проверьте зависимость.
Диагностика: кто вообще использует XML-RPC
Перед изменениями полезно понять, есть ли реальные обращения к xmlrpc.php. Это можно сделать по логам веб-сервера или средствами хостинга. Если доступа к логам нет, хотя бы проверьте список подключённых сервисов: мобильное приложение WordPress, Jetpack, сторонние публикационные сервисы, интеграции с IFTTT-подобными решениями, старые плагины синхронизации.
Что проверить до отключения
- Используете ли вы мобильное приложение WordPress для публикации.
- Подключён ли Jetpack и какие его модули реально нужны.
- Есть ли внешние сервисы автопостинга или импорта контента.
- Не завязаны ли на XML-RPC старые плагины для удалённого управления.
- Появляются ли в логах частые запросы к
/xmlrpc.php.
Если хотя бы один пункт подтверждается, отключать механизм нужно аккуратно: либо с исключениями, либо после замены интеграции на REST API.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или плагине | Нужен контроль внутри WordPress | Просто откатить, легко тестировать | Не сработает, если код отключён вместе с темой |
| Правило на сервере | Нужно блокировать запросы раньше WordPress | Меньше нагрузки, быстрее отказ | Требует доступа к конфигу веб-сервера |
| Плагин безопасности | Нужен быстрый вариант без кода | Удобно для админов без доступа к файлам | Лишняя зависимость, не всегда прозрачная логика |
Для большинства проектов достаточно кода. Если сайт часто атакуют по xmlrpc.php, лучше дополнить это серверным блоком.
Пошаговое решение через код
Самый безопасный путь — отключить XML-RPC через фильтр xmlrpc_enabled. Это не ломает ядро и легко откатывается. Код можно добавить в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более явный вариант с собственной функцией, можно сделать так:
<?php
add_filter( 'xmlrpc_enabled', function( $enabled ) {
return false;
} );Этот способ отключает сам механизм на уровне WordPress. Если кто-то попытается обратиться к XML-RPC, WordPress не будет выполнять запросы как обычно.
Как заблокировать доступ на уровне сервера
Если у вас Apache и доступ к .htaccess разрешён, можно закрыть файл xmlrpc.php до передачи запроса в WordPress:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный блок полезен тем, что запросы не доходят до PHP вообще. Это снижает нагрузку и уменьшает шум в логах. Но если вы не уверены в конфигурации, сначала протестируйте кодовый вариант.
Проверка результата после внедрения
После отключения важно не ограничиваться «страница открывается». Проверьте именно те сценарии, которые завязаны на XML-RPC.
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт или ответ изменился ожидаемо. - Проверьте публикацию записи из админки WordPress.
- Если используете мобильное приложение, попробуйте авторизоваться и отправить тестовую запись.
- Проверьте Jetpack, если он установлен, и убедитесь, что нужные модули работают.
- Посмотрите логи сервера: количество обращений к
/xmlrpc.phpдолжно снизиться или исчезнуть.
Простой тест через консоль:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали доступ на сервере, ожидайте ответ вроде 403 Forbidden. Если отключали через фильтр WordPress, поведение может отличаться в зависимости от конфигурации, но сам XML-RPC не должен выполнять команды.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали интеграцию
Это самая частая проблема. Причина обычно в том, что кто-то использовал старый клиент публикации или Jetpack, а зависимость не была проверена заранее. Решение простое: верните фильтр обратно, найдите конкретный сервис и либо замените его на REST API, либо оставьте XML-RPC включённым только на время миграции.
Добавили код не туда
Если вставить код в активную тему, он исчезнет после смены темы. Для постоянного решения лучше использовать дочернюю тему или mu-plugin. Если у вас есть отдельный технический плагин для сайта, это ещё надёжнее.
Закрыли файл на сервере, но WordPress всё ещё отвечает
Такое бывает при неправильном месте правила или при использовании другого веб-сервера/прокси. Проверьте, что правило реально применяется к нужному виртуальному хосту, и не забывайте очищать кеш конфигурации, если он есть.
Отключили XML-RPC, но атаки не прекратились
Это нормально: боты могут продолжать стучаться в /xmlrpc.php, даже если файл закрыт. Важно не количество попыток, а то, что они больше не доходят до PHP и не создают нагрузку. Если атаки массовые, дополните решение ограничением на уровне WAF или веб-сервера.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — разумная мера. Но не стоит смешивать её с другими изменениями без необходимости. Сначала уберите именно этот механизм, затем проверьте сайт, и только после этого переходите к дополнительной чистке.
Для проектов, где важны безопасность и снижение дублей технических функций, удобно держать такие настройки в одном месте: отдельный mu-plugin, минимальный набор правил на сервере и понятный список исключений. Это проще сопровождать, чем разрозненные правки в теме.
Если вы используете плагины для технической оптимизации и чистки сайта, проверьте, не дублируют ли они друг друга по функциям. Например, некоторые решения для SEO и очистки лишнего кода умеют отключать XML-RPC, Emoji, REST-эндпоинты и другие необязательные элементы интерфейса. Важно не включать всё подряд, а оставлять только то, что действительно нужно проекту.
Короткий чек-лист перед публикацией изменений
- Проверены все внешние сервисы, завязанные на XML-RPC.
- Выбран способ отключения: код, сервер или плагин.
- Сделан бэкап или хотя бы сохранена исходная конфигурация.
- Проверена работа админки, публикации и мобильных клиентов.
- Просмотрены логи после изменения.
Если нужен именно безопасный и обратимый вариант, начните с фильтра xmlrpc_enabled. Если задача — жёстко закрыть точку входа и снизить нагрузку, добавьте блокировку на уровне сервера. В обоих случаях проверка результата обязательна: без неё легко отключить не то, что планировалось.