XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать публикации через внешние клиенты, Jetpack или интеграции, которые до сих пор используют этот канал. Проблема в том, что у XML-RPC нет одного единственного сценария использования: для одних сайтов это лишняя поверхность атаки, для других — рабочий транспорт для удалённого доступа.
Если задача не абстрактная, а практическая — убрать лишний риск и не поломать нужные интеграции — сначала стоит понять, кто именно обращается к /xmlrpc.php, а уже потом выбирать способ блокировки.
Когда XML-RPC действительно стоит отключать
Отключение имеет смысл, если сайт не использует:
- публикацию и редактирование через старые мобильные приложения WordPress;
- Jetpack-функции, завязанные на XML-RPC;
- внешние сервисы, которые подключаются по XML-RPC, а не через REST API;
- старые интеграции с десктопными клиентами и автоматизацией.
Если сайт живёт только в админке и REST API, а внешних клиентов нет, XML-RPC обычно можно убрать без потерь. Но если вы не уверены, лучше сначала проверить логи и список подключений.
Диагностика: кто обращается к xmlrpc.php
Самая частая ошибка — блокировать файл до проверки. В результате вы видите только «что-то сломалось», но не понимаете, что именно. Начните с доступа к логам веб-сервера или хотя бы к журналу безопасности на хостинге.
Что искать в логах
В access.log обычно видны запросы к /xmlrpc.php. Если сайт на Apache или Nginx, ищите строки с этим путём и смотрите IP, user-agent и частоту запросов. Повторяющиеся обращения с одинаковым шаблоном часто указывают на брутфорс, а не на легитимный сервис.
# Пример поиска по access.log
grep "xmlrpc.php" access.log | tail -n 50Если у вас есть доступ только к панели хостинга, проверьте статистику запросов по URI. Важно не просто увидеть факт обращения, а понять, есть ли среди них ваш собственный сервис, например Jetpack или приложение для публикации.
Проверка зависимостей на стороне WordPress
Иногда сайт использует XML-RPC неявно. Например, подключённые сервисы могут работать через старую схему авторизации, а владелец об этом не знает. Перед отключением проверьте:
- активен ли Jetpack и какие его модули используются;
- есть ли мобильные приложения WordPress, подключённые к сайту;
- используются ли внешние редакторы или планировщики публикаций;
- есть ли интеграции, которые отправляют посты по XML-RPC.
Если доступ к сайту есть только у вас, можно временно включить мониторинг запросов на уровне сервера и посмотреть, не появляются ли обращения после рабочего дня или по расписанию.
Как отключить XML-RPC: три рабочих способа
Выбор зависит от того, нужен ли вам полный запрет или мягкая блокировка только для внешних запросов.
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужно быстро закрыть доступ без правки кода | Добавляет зависимость от плагина |
| Код в теме или mu-plugin | Нужен контролируемый и предсказуемый вариант | Требует аккуратного деплоя |
| Блокировка на уровне сервера | Нужно отсечь запросы до WordPress | Можно случайно задеть легитимные интеграции |
Вариант 1: отключение через код
Если вы управляете кодовой базой, самый прозрачный способ — запретить обработку XML-RPC через фильтр xmlrpc_enabled. Это не ломает WordPress целиком и легко откатывается.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код можно добавить в functions.php дочерней темы, но надёжнее вынести в небольшой mu-plugin, чтобы он не зависел от темы. Для production-сайта это практичнее: тема может обновиться или смениться, а защита останется.
Вариант 2: блокировка через .htaccess или Nginx
Если задача — не дать запросу даже дойти до WordPress, блокируйте xmlrpc.php на уровне веб-сервера. Это полезно при массовых попытках подбора паролей, потому что снимает нагрузку с PHP.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот вариант хорош, если вы точно знаете, что XML-RPC не нужен. Если есть сомнения, сначала проверьте логи и только потом закрывайте доступ.
Вариант 3: плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, можно использовать его вместо ручной правки. Но здесь важно не путать удобство с контролем: плагин должен делать именно то, что вам нужно, а не включать лишние «оптимизации» в комплекте.
Например, в Clearfy Pro есть инструменты для чистки и отключения части лишних функций WordPress. Если у вас уже используется этот набор задач, имеет смысл проверить, закрывает ли он и XML-RPC в вашей конфигурации. Ссылка на продукт: Clearfy Pro.
Пошаговое решение без сюрпризов
- Соберите данные по обращениям к
/xmlrpc.phpза несколько дней, а не за один час. - Проверьте, нет ли активных интеграций, которые используют XML-RPC.
- Выберите способ блокировки: код, сервер или плагин.
- Сделайте изменения сначала на staging, если он есть.
- После внедрения проверьте, что сайт не потерял нужные функции.
Если вы работаете через код, лучше использовать mu-plugin. Это маленький файл в wp-content/mu-plugins/, который WordPress загружает автоматически. Такой подход удобен для технических ограничений, которые не должны зависеть от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После загрузки файла проверьте, что /xmlrpc.php возвращает отказ в доступе или пустой ответ в зависимости от уровня блокировки. Если вы закрывали доступ через сервер, WordPress вообще не должен обрабатывать этот запрос.
Как проверить, что решение сработало
Проверка нужна не только на уровне браузера. Сайт может «выглядеть закрытым», но продолжать принимать запросы на сервере.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере и проверьте ответ. - Посмотрите access.log: после изменения запросы должны либо исчезнуть, либо получать отказ до PHP.
- Проверьте Jetpack и другие подключённые сервисы, если они есть.
- Попробуйте публикацию из внешнего клиента, если вы им реально пользуетесь.
Если XML-RPC отключён правильно, вы не увидите рабочий ответ метода system.listMethods. При этом обычный вход в админку, REST API и публикация через сам WordPress должны остаться без изменений.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли Jetpack
Это ожидаемое поведение, если Jetpack использовал XML-RPC для связи с сайтом. Решение простое: либо вернуть XML-RPC, либо отказаться от функций, которые на нём завязаны. Не стоит пытаться «починить» это случайной правкой в плагине безопасности — сначала определите, какая именно функция нужна.
Закрыли xmlrpc.php, но атаки всё равно идут
Если запросы продолжают приходить, проверьте, блокируете ли вы именно на уровне сервера, а не только внутри WordPress. Внутренняя блокировка всё равно тратит ресурсы на загрузку PHP. Для массовых попыток подбора паролей лучше отсекать запросы раньше.
Сломали мобильное приложение WordPress
Старые сценарии публикации через приложение могут использовать XML-RPC. Если редакторы работают с телефона и не предупредили об этом, отключение нужно согласовывать заранее. В таких случаях лучше перейти на актуальный способ публикации через админку или REST API-интеграцию, если она поддерживается вашим инструментом.
Смешали отключение XML-RPC с другими мерами безопасности
Иногда в один коммит добавляют и блокировку XML-RPC, и отключение REST API, и правки в .htaccess. Потом невозможно понять, что именно сломало сайт. Для технической поддержки это плохая практика: меняйте по одному слою и фиксируйте результат.
Безопасность и производительность: что ещё имеет смысл проверить
Отключение XML-RPC не заменяет базовую защиту. Если сайт регулярно получает брутфорс, проверьте:
- ограничение попыток входа;
- 2FA для админов;
- актуальность ядра, тем и плагинов;
- наличие WAF или правил на уровне хостинга;
- логи на предмет других точек атаки, а не только
xmlrpc.php.
С точки зрения производительности блокировка XML-RPC полезна тем, что убирает лишние PHP-запросы. Но эффект заметен только если сайт действительно атакуют или если на него часто стучатся внешние сервисы. Не стоит ожидать магического ускорения всего проекта — это точечная мера, а не панацея.
Если вам нужен более широкий набор технической чистки WordPress — от отключения лишних функций до удаления дублей и мусорных элементов интерфейса — такие задачи лучше решать системно, а не набором разрозненных правок. В этом случае удобнее держать изменения в одном месте и документировать, что именно отключено и зачем.