XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам в логах, перебору паролей и странным обращениям к /xmlrpc.php. Если вы не пользуетесь мобильным приложением WordPress, Jetpack или внешними сервисами, которые ходят в сайт через XML-RPC, эту точку входа обычно проще закрыть, чем разбираться с последствиями.
Сразу важный момент: отключение XML-RPC не лечит все проблемы безопасности, но убирает один из популярных векторов атак. Для сайта на обычном хостинге это полезная и проверяемая мера, если вы понимаете, что именно отключаете.
Когда XML-RPC мешает, а когда его лучше оставить
XML-RPC — это не «лишний плагин», а встроенный механизм WordPress для удалённого доступа. Через него раньше активно работали мобильные клиенты, публикация из внешних редакторов и часть интеграций. Сейчас для большинства сайтов он не нужен, но есть исключения.
Оставлять XML-RPC имеет смысл, если
- вы публикуете записи через мобильное приложение WordPress;
- у вас подключён Jetpack и он использует XML-RPC для части функций;
- есть внешняя система, которая точно работает через XML-RPC, а не через REST API;
- вы не можете быстро проверить все интеграции и боитесь сломать рабочий сценарий.
Отключать XML-RPC разумно, если
- сайт обычный: блог, корпоративный сайт, лендинг, контентный проект;
- в логах видны частые обращения к
/xmlrpc.php; - вы не используете старые клиенты и внешнюю публикацию;
- нужно уменьшить поверхность атаки без сложной доработки кода.
Диагностика: как понять, что XML-RPC у вас вообще используется
Перед отключением не полагайтесь на догадки. Проверьте сайт по факту: есть ли обращения к файлу, работают ли интеграции, не завязаны ли на него сторонние сервисы.
Что посмотреть в первую очередь
- Логи веб-сервера. Ищите запросы к
/xmlrpc.phpи повторяющиеся POST-запросы. - Настройки Jetpack, если он установлен. Некоторые функции могут быть завязаны на соединение с WordPress.com.
- Список интеграций: мобильное приложение, внешние редакторы, автопостинг, сервисы мониторинга.
- Проверку ответа файла в браузере или через
curl.
Если открыть https://example.com/xmlrpc.php, на большинстве сайтов вы увидите стандартный ответ WordPress вроде сообщения о том, что XML-RPC сервер принимает только POST-запросы. Это ещё не проблема, но это подтверждает, что точка входа доступна извне.
Способы отключения: что выбрать на практике
Есть три рабочих подхода: кодом, через плагин или на уровне сервера. У каждого варианта свои компромиссы.
| Способ | Плюсы | Минусы | Когда брать |
|---|---|---|---|
Код в functions.php или mu-plugin | Контроль, без лишних плагинов | Нужно не ошибиться с местом размещения | Если есть доступ к теме или mu-plugin |
| Плагин безопасности | Быстро включить, без правки кода | Лишняя зависимость от плагина | Если нужен простой переключатель |
| Web server / WAF | Режет запросы до WordPress | Зависит от хостинга и доступа к конфигу | Если есть доступ к nginx/apache или Cloudflare |
Пошаговое решение через код
Если нужен предсказуемый вариант без лишних плагинов, проще всего отключить XML-RPC через фильтр xmlrpc_enabled. Это корректный хук WordPress, а не самодельная заглушка.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы, но для технической настройки надёжнее использовать mu-plugin, чтобы отключение не зависело от смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, её можно создать вручную. WordPress подхватит такой файл автоматически.
Если нужно не только отключить, но и отдать 403
Иногда одного фильтра мало: файл всё равно отвечает, а вам нужно жёстко закрыть доступ на уровне WordPress. Тогда можно добавить проверку на раннем этапе загрузки.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
}, 1 );Этот вариант грубее. Он подходит, если вы точно уверены, что XML-RPC не нужен ни одному сервису. Для большинства случаев достаточно фильтра xmlrpc_enabled.
Отключение через плагин: когда это оправдано
Если на сайте уже стоит плагин безопасности или оптимизации, проверьте его настройки. Некоторые плагины умеют отключать XML-RPC без отдельного кода. Это удобно, если вы не хотите править файлы темы и вам нужен переключатель в админке.
Например, в комплексных инструментах вроде Clearfy Pro есть функции для чистки сайта и отключения лишних возможностей WordPress. Но даже в таком случае важно понимать, что именно выключено и не конфликтует ли это с другими настройками безопасности.
Плагин — нормальный вариант, если:
- на сайте уже есть доверенный инструмент для hardening;
- вы хотите быстро откатить изменение через интерфейс;
- нет доступа к серверу и неудобно работать с кодом.
Блокировка на уровне сервера: полезно, если атаки идут массово
Если в логах видно, что xmlrpc.php дёргают постоянно, лучше отсечь запросы раньше WordPress. Это снижает лишнюю нагрузку и не даёт PHP обрабатывать мусор.
Пример для nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache подход зависит от конфигурации, но логика та же: запретить доступ к файлу напрямую. Если вы не уверены в настройках сервера, лучше согласовать это с хостингом, а не экспериментировать на боевом сайте.
Проверка результата после внедрения
После отключения важно не ограничиться «в админке всё открывается». Проверьте именно ту точку, которую закрывали.
- Откройте
/xmlrpc.phpв браузере: он не должен вести себя как рабочая точка входа. - Проверьте ответ через
curl:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, ожидайте 403 или другой отказ в доступе. Если использовали только фильтр WordPress, ответ может отличаться в зависимости от конфигурации, но сам XML-RPC должен быть недоступен для рабочих запросов.
Дополнительно проверьте:
- не сломалась ли авторизация в Jetpack;
- не перестала ли работать мобильная публикация;
- нет ли новых ошибок в логах после изменения;
- не выросло ли число 404/403 на этом файле из-за ботов.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо, если Jetpack использовал XML-RPC для связи с сайтом. Решение простое: либо вернуть доступ, либо отказаться от функции, которая на него завязана. Не стоит оставлять поломанный плагин и искать проблему в кэше.
Добавили код в тему, а после обновления он пропал
Так бывает, если правили не дочернюю тему, а основную. Для технических ограничений лучше использовать mu-plugin: он не зависит от обновления темы и не требует постоянного контроля.
Поставили плагин, который отключает слишком много
Некоторые плагины безопасности умеют одновременно резать REST API, XML-RPC, эмодзи, oEmbed и ещё несколько функций. Если после установки появились побочные эффекты, отключайте опции по одной и фиксируйте, что именно влияет на сайт.
Заблокировали файл на сервере, но WordPress всё равно отвечает
Значит, правило не сработало или применяется не к тому виртуальному хосту. Проверьте конфигурацию nginx/apache, порядок правил и то, не перехватывает ли запрос другой слой — например, CDN или WAF.
Чек-лист перед отключением
- Проверили, нужен ли XML-RPC для мобильного приложения или Jetpack.
- Посмотрели логи на обращения к
/xmlrpc.php. - Выбрали способ отключения: код, плагин или сервер.
- Сделали изменение на staging или в окне с быстрым откатом.
- Проверили ответ файла через браузер и
curl. - Убедились, что не сломались интеграции и публикация.
Что делать дальше, если цель — не только закрыть XML-RPC
Если вы уже чистите поверхность атаки, логично посмотреть и на другие лишние точки входа: неиспользуемые REST-маршруты, старые плагины, открытые административные страницы, избыточные мета-теги и мусорные эндпоинты. Но каждую настройку лучше проверять отдельно, а не выключать всё подряд одним «security pack» без понимания последствий.
Для сайтов, где важны и SEO, и техническая чистота, удобно держать такие изменения в одном месте и документировать их. Тогда при обновлении темы или переносе на другой сервер не придётся вспоминать, почему вдруг перестал работать внешний сервис.