XML-RPC в WordPress до сих пор часто остаётся включённым по умолчанию, даже если он давно не нужен. На практике это лишняя поверхность атаки и источник странных запросов в логах. Если вы не используете мобильное приложение WordPress, Jetpack или внешние сервисы, которые завязаны именно на XML-RPC, этот интерфейс обычно проще закрыть.
Ниже разберём, где именно отключать XML-RPC, как не сломать нужные интеграции и чем проверить результат после внедрения.
Когда XML-RPC реально мешает
Проблема обычно всплывает не в админке, а по косвенным признакам: в логах появляются частые POST-запросы к /xmlrpc.php, хостинг ругается на всплески нагрузки, а в отчётах безопасности видно много неудачных попыток авторизации. Сам по себе XML-RPC не является уязвимостью, но это отдельная точка входа, которую атакуют брутфорсом и abuse-запросами.
Есть и рабочие сценарии, где его лучше не трогать без проверки:
- вы публикуете записи через мобильное приложение WordPress;
- используете Jetpack и часть функций завязана на XML-RPC;
- подключены внешние сервисы, которые отправляют публикации или обновления через XML-RPC;
- на сайте есть старые интеграции, которые не переведены на REST API.
Что проверить перед отключением
Сначала не выключайте всё вслепую. Посмотрите, есть ли у вас реальные обращения к endpoint. Если в логах веб-сервера есть регулярные запросы к /xmlrpc.php от ваших сервисов, отключение может сломать синхронизацию или публикацию.
- проверьте логи доступа веб-сервера;
- посмотрите, используется ли Jetpack;
- проверьте мобильное приложение WordPress;
- сверьте список внешних интеграций, которые работают с сайтом.
Как отключить XML-RPC в WordPress
Есть три нормальных способа: через код, через серверную конфигурацию и через плагин. Если нужен контролируемый вариант без лишней магии, лучше начать с кода в functions.php дочерней темы или в небольшом mu-plugin.
Вариант 1: отключение через фильтр
Это самый понятный способ для WordPress. Он не удаляет файл физически, но блокирует обработку запросов через стандартный механизм.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Если нужен более жёсткий вариант, можно дополнительно отрубить доступ к самому endpoint через template_redirect, но это уже менее универсально и требует аккуратности. Для большинства сайтов достаточно фильтра выше.
Вариант 2: запрет на уровне веб-сервера
Если у вас Apache, можно закрыть доступ к файлу xmlrpc.php через .htaccess. Это полезно, когда нужно отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx логика делается через location в конфиге сайта. Здесь важно не копировать чужие фрагменты без проверки, потому что конфигурация у хостингов отличается.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Серверный запрет хорош тем, что запросы не доходят до PHP. Но если вы не уверены в конфиге или не имеете доступа к серверу, проще использовать фильтр WordPress.
Вариант 3: плагин для точечной настройки
Если на сайте уже используется плагин для технической чистки и SEO-настроек, удобнее собрать часть ограничений в одном месте. Например, Clearfy Pro умеет закрывать лишние системные вещи без ручного редактирования кода. Это не обязательный путь, но он удобен, если вы не хотите поддерживать собственный сниппет на каждом сайте.
Смысл тот же: отключить ненужный интерфейс и не держать его открытым только потому, что он есть в ядре.
Пошаговое решение без поломки интеграций
Если сайт рабочий и на нём уже есть трафик, действуйте по схеме ниже. Она помогает не отрезать нужные сервисы случайно.
- Проверьте, использует ли сайт мобильное приложение WordPress или Jetpack.
- Посмотрите логи на обращения к
/xmlrpc.php. - Отключите XML-RPC через фильтр
xmlrpc_enabled. - Проверьте, не сломались ли публикации, синхронизация и удалённые интеграции.
- Если всё стабильно, добавьте серверный запрет, чтобы снизить шум в логах.
Такой порядок лучше, чем сразу закрывать endpoint на сервере. Сначала вы убеждаетесь, что сайт не зависит от XML-RPC, и только потом усиливаете блокировку.
Как проверить, что XML-RPC действительно закрыт
После внедрения важно не ограничиваться “код добавил — значит работает”. Проверка должна быть технической.
Проверка в браузере и через curl
Откройте https://ваш-домен/xmlrpc.php. В норме вы не должны видеть рабочий ответ XML-RPC. Если доступ закрыт на уровне сервера, часто будет 403 Forbidden. Если блокировка сделана на уровне WordPress, ответ может отличаться, но endpoint не должен принимать рабочие XML-RPC-запросы.
Для более точной проверки используйте curl:
curl -i https://example.com/xmlrpc.phpЕсли серверный запрет настроен правильно, вы увидите отказ в доступе. Если ответ приходит, но XML-RPC не обрабатывает запросы, проверьте, не остался ли включённый плагин или другой код, который переопределяет поведение.
Проверка по логам
После отключения в логах доступа должно стать меньше запросов к /xmlrpc.php с успешными ответами. Если атаки продолжаются, это нормально: сканеры будут стучаться ещё какое-то время. Важен не сам факт попыток, а отсутствие обработки на стороне WordPress.
| Способ | Что даёт | Минус |
|---|---|---|
Фильтр xmlrpc_enabled | Просто отключить обработку в WordPress | Запрос всё ещё доходит до PHP |
| Apache/Nginx запрет | Отсечь запросы раньше PHP | Нужен доступ к конфигу сервера |
| Плагин | Удобно для админов без кода | Ещё одна зависимость в системе |
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Это самый частый сценарий. Если Jetpack использует XML-RPC для части функций, после блокировки могут перестать работать отдельные связи с WordPress.com. Решение простое: сначала проверьте, какие модули Jetpack реально нужны, и только потом отключайте endpoint. Если интеграция критична, оставьте XML-RPC включённым и компенсируйте риски другими мерами защиты.
Добавили код не туда
Сниппет в основной теме — плохая идея. При обновлении темы он исчезнет. Используйте дочернюю тему, mu-plugin или отдельный технический плагин. Это особенно важно, если вы поддерживаете несколько сайтов и хотите одинаковое поведение после обновлений.
Закрыли endpoint, но не убрали шум в логах
Если запросы продолжают сыпаться, это не значит, что блокировка не работает. Это значит, что боты продолжают стучаться. Проверьте код ответа и убедитесь, что WordPress не обрабатывает такие запросы. Для снижения шума можно дополнительно закрыть доступ на уровне веб-сервера.
Сломали внешнюю интеграцию и не поняли почему
Некоторые старые сервисы до сих пор используют XML-RPC, а не REST API. Если после отключения перестала работать публикация или синхронизация, ищите именно этот канал. В таких случаях решение не в том, чтобы “вернуть как было”, а в том, чтобы перевести интеграцию на REST API или другой поддерживаемый способ.
Что делать с безопасностью и производительностью дальше
Отключение XML-RPC не заменяет нормальную защиту сайта. Это только один лишний вход, который вы убрали. Дальше стоит проверить:
- есть ли ограничение попыток входа;
- закрыт ли доступ к
/wp-login.phpот брутфорса; - используется ли актуальная версия WordPress, темы и плагинов;
- есть ли в логах другие подозрительные endpoint’ы;
- не плодятся ли лишние редиректы и дубли URL.
Если вы уже наводите порядок в технической части сайта, удобно смотреть на это как на набор отдельных задач: убрать ненужные интерфейсы, сократить поверхность атаки, проверить индексацию и не держать включённым то, что не используется.
В типичном проекте именно такой подход даёт больше пользы, чем попытка “поставить один плагин безопасности и забыть”.