Как отключить XML-RPC в WordPress и закрыть доступ без поломки входа и приложений

XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки, шум в логах и непонятные запросы к /xmlrpc.php. Если сайт не использует мобильное приложение WordPress, внешние публикации или старые интеграции, этот endpoint обычно можно закрыть. Но делать это нужно аккуратно: у части сайтов XML-RPC всё ещё нужен для конкретных сценариев, а грубая блокировка может сломать синхронизацию или удалённую публикацию.

Когда XML-RPC действительно стоит отключать

Сначала проверьте не «по привычке», а по факту. XML-RPC нужен, если вы:

• публикуете записи из старого клиента WordPress;
• подключаете внешние сервисы, которые работают именно через XML-RPC;
• используете мобильное приложение WordPress для управления сайтом;
• видите в логах постоянные запросы к xmlrpc.php, но не понимаете источник.

Если ничего из этого не используется, отключение обычно оправдано. Для обычного сайта на Elementor, где контент редактируют из админки, XML-RPC чаще всего не нужен.

Диагностика: как понять, используется ли XML-RPC сейчас

Не начинайте с блокировки на сервере. Сначала проверьте, есть ли реальные обращения к endpoint.

Проверка по логам сервера

Посмотрите access log веб-сервера и найдите обращения к /xmlrpc.php. Если запросы идут только от ботов и сканеров, это один сценарий. Если видите запросы от ваших сервисов или устройств — другой.

grep "xmlrpc.php" /var/log/nginx/access.log

Если у вас Apache, путь к логам может отличаться. Смысл один: нужно понять, кто и как часто обращается к файлу.

Быстрая проверка снаружи

Можно проверить ответ endpoint обычным запросом. Если XML-RPC доступен, сервер обычно отвечает не 404, а страницей с сообщением WordPress или кодом, связанным с методом запроса.

curl -I https://example.com/xmlrpc.php

Это не доказывает, что XML-RPC используется, но показывает, что endpoint открыт.

Что выбрать: плагин, код или блокировка на сервере

Для разных задач подходят разные способы. Ниже — короткое сравнение без лишней теории.

Если задача простая, а сайт типовой, я бы начинал с кода в MU-плагине или с серверной блокировки. Плагин имеет смысл, когда вы не хотите трогать конфиги и у вас уже есть инструмент для security-hardening.

Пошаговое решение: как отключить XML-RPC без побочных эффектов

Вариант 1. Отключить через код WordPress

Самый предсказуемый способ — вернуть __return_false на фильтр xmlrpc_enabled. Это отключает сам механизм XML-RPC внутри WordPress, но не мешает вам потом точечно открыть доступ на уровне сервера, если понадобится.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Код лучше добавлять не в тему, а в MU-плагин. Тогда он не исчезнет после смены темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если каталога mu-plugins нет, создайте его вручную.

Вариант 2. Закрыть доступ на уровне .htaccess

Если сайт работает на Apache или LiteSpeed с поддержкой .htaccess, можно запретить прямой доступ к файлу xmlrpc.php. Это полезно, когда вы хотите отрезать запрос ещё до WordPress.

<Files xmlrpc.php>
    Require all denied
</Files>

Для старых конфигураций Apache 2.2 иногда встречается синтаксис Deny from all, но на современных серверах лучше использовать Require all denied.

Вариант 3. Закрыть endpoint в nginx

Если у вас nginx, блокировка делается в конфиге виртуального хоста. Это самый прямой способ, но он требует доступа к серверу и понимания, где именно лежит конфиг сайта.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

После правки конфига не забудьте проверить синтаксис и перезагрузить nginx. Иначе можно получить нерабочий сайт из-за одной лишней скобки.

Вариант 4. Плагин безопасности

Если нужен интерфейс без ручной правки, используйте плагин, который умеет отключать XML-RPC и другие лишние функции. Например, в Clearfy Pro есть инструменты для чистки WordPress и отключения ненужных компонентов. Это удобно, когда вы параллельно хотите убрать и другие дубли или лишние запросы, а не только XML-RPC. Смотрите описание на странице плагина: Clearfy Pro.

Как проверить, что решение сработало

Проверка нужна не только для спокойствия. Она показывает, не сломали ли вы нужную интеграцию.

• Откройте https://example.com/xmlrpc.php в браузере или через curl.
• Проверьте, что endpoint больше не отвечает как доступный сервис WordPress.
• Посмотрите логи сервера: новых обращений к xmlrpc.php быть не должно.
• Если вы отключали через код, убедитесь, что сайт продолжает нормально работать в админке и на фронтенде.

Для более точной проверки можно отправить запрос методом system.listMethods. Если XML-RPC закрыт, нормального ответа не будет.

curl -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?>
<methodCall>
  <methodName>system.listMethods</methodName>
  <params></params>
</methodCall>'

Частые ошибки и как их исправить

Отключили XML-RPC, а потом перестало работать мобильное приложение

Это ожидаемо. Мобильное приложение WordPress и некоторые внешние клиенты используют XML-RPC. Если они нужны, не блокируйте endpoint полностью. Тогда лучше ограничить доступ на сервере по IP или оставить XML-RPC включённым и закрыть только лишние методы — но это уже отдельная задача и требует точной настройки.

Добавили код в тему, а после обновления всё пропало

Классическая ошибка. Если код лежал в functions.php активной темы, он исчезнет при смене темы или может быть перезаписан обновлением. Для таких задач используйте MU-плагин или отдельный мини-плагин.

Закрыли xmlrpc.php в nginx, но WordPress всё ещё отвечает

Проверьте, не обслуживается ли сайт через другой серверный слой: например, nginx перед Apache. В такой схеме блокировку нужно ставить там, где реально проходит запрос. Иначе правило просто не сработает.

Сломали доступ к сайту из-за ошибки в конфиге

Если после правки .htaccess или nginx-конфига сайт перестал открываться, откатите последнее изменение и проверьте синтаксис. Для nginx это особенно важно: перед перезагрузкой всегда делайте проверку конфигурации.

nginx -t

Практические советы по безопасности и производительности

Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из популярных векторов перебора и лишнюю нагрузку от мусорных запросов. Если у вас часто атакуют xmlrpc.php, полезно дополнительно:

• обновить ядро WordPress, тему и плагины;
• включить ограничение попыток входа, если оно уместно для вашего стека;
• проверить, нет ли открытых старых интеграций, которые вы уже не используете;
• посмотреть, не генерируют ли плагины лишние запросы к админке и REST API;
• держать бэкап перед изменениями в серверных конфигурациях.

Если сайт большой и логов много, блокировка на уровне nginx или Apache обычно предпочтительнее, чем попытка «лечить» запросы уже внутри WordPress. Так вы экономите PHP-процессы и уменьшаете шум в логах.

Когда XML-RPC лучше не отключать полностью

Полное отключение не всегда правильный ответ. Если у вас есть внешняя публикация, старый клиент, интеграция с мобильным приложением или сервис, который нельзя быстро перевести на REST API, сначала проверьте совместимость. В таких случаях безопаснее временно ограничить доступ на уровне сервера, собрать список зависимостей и только потом убирать endpoint окончательно.

Если нужен более широкий аудит лишних функций WordPress — от дублей до технической чистки — удобнее решать это не точечно, а как часть общей оптимизации. Но даже тогда сначала проверьте, что именно используется на сайте, а что просто висит «на всякий случай».