Как отключить XML-RPC в WordPress и не сломать нужные интеграции

XML-RPC в WordPress часто всплывает не тогда, когда он нужен, а когда сайт начинает получать лишние запросы, брутфорс по xmlrpc.php или странную нагрузку в логах. Проблема в том, что отключать его «в лоб» безопасно не всегда: у части сайтов через XML-RPC до сих пор работают мобильные клиенты, внешние публикации и некоторые старые интеграции.

Ниже — рабочая схема: как понять, используется ли XML-RPC, как отключить его без лишних побочных эффектов и как проверить результат после внедрения.

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

Если вы не публикуете записи из сторонних клиентов и не используете старые интеграции, XML-RPC обычно не нужен. На практике его чаще всего отключают из-за трех сценариев: попытки перебора паролей, лишние POST-запросы к /xmlrpc.php и конфликт с правилами безопасности на уровне сервера или WAF.

Но есть и обратная сторона: некоторые приложения и сервисы до сих пор обращаются к WordPress через XML-RPC. Поэтому сначала лучше проверить, есть ли реальные обращения, а уже потом резать доступ.

Что смотреть в логах и в админке

Диагностика начинается с простых вещей. Если у вас есть доступ к access.log, ищите запросы к xmlrpc.php. Если логов нет, можно хотя бы посмотреть статистику в панели хостинга или временно включить аудит на уровне веб-сервера.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если запросы идут пачками с разных IP и одинаковым телом, это типичный признак перебора или pingback-активности. Если же вы видите редкие запросы от понятного сервиса, сначала выясните, что это за интеграция.

Как отключить XML-RPC в WordPress: три рабочих варианта

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

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

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

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

Такой код можно положить в functions.php дочерней темы, но лучше — в небольшой mu-plugin, чтобы он не зависел от темы. Например, файл wp-content/mu-plugins/disable-xmlrpc.php:

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

Это отключит сам механизм XML-RPC на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, он не получит рабочий ответ.

Вариант 2. Закрыть доступ через .htaccess или nginx

Если задача — именно отсечь запросы до PHP, можно заблокировать файл на уровне веб-сервера. Это полезно, когда вы хотите снизить нагрузку и не отдавать лишние запросы WordPress вообще.

Для Apache в .htaccess можно использовать такое правило:

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

Для nginx обычно добавляют отдельный блок в конфигурацию сайта:

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

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Для nginx это обычно nginx -t и затем reload.

Вариант 3. Отключить через плагин безопасности

Если у вас уже стоит плагин, который умеет управлять XML-RPC, можно использовать его. Но здесь важно не полагаться на «галочку» без проверки: некоторые плагины блокируют только часть методов или только отдельные сценарии.

Если вы используете Clearfy Pro, проверьте, какие именно опции включены в блоке защиты и очистки. Важно не просто скрыть проблему в интерфейсе, а убедиться, что запросы к xmlrpc.php реально перестали проходить. Ссылка на плагин: https://wpshop.ru/plugins/clearfy.

Как понять, не сломаете ли вы нужную интеграцию

Перед отключением проверьте, используется ли XML-RPC в вашем сценарии. Это особенно важно, если сайт старый, у вас есть мобильное приложение для публикации, внешняя CMS, автопостинг или интеграции с сервисами, которые давно не обновлялись.

• Проверьте логи за последние 30–60 дней на обращения к xmlrpc.php.
• Спросите у команды, публикуют ли они записи из внешних клиентов.
• Посмотрите, не используется ли старый мобильный клиент WordPress.
• Если есть интеграции через сторонние сервисы, проверьте их документацию.

Если сомневаетесь, сначала заблокируйте доступ на уровне сервера только для внешнего трафика или включите правило в WAF и понаблюдайте за ошибками. Это проще откатить, чем потом искать, почему перестала работать публикация из внешнего инструмента.

Проверка результата после внедрения

После отключения важно не ограничиваться «в админке всё открывается». Нужно проверить и HTTP-ответ, и отсутствие лишних запросов, и отсутствие побочных эффектов в логах.

Проверка через curl

Самый простой тест — обратиться к xmlrpc.php напрямую:

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

Если вы отключали через WordPress-фильтр, поведение может отличаться в зависимости от сервера и кэша, но в любом случае файл не должен работать как обычная точка входа для XML-RPC. При серверной блокировке вы должны увидеть отказ в доступе.

Проверка в логах

После внедрения посмотрите, продолжают ли приходить запросы. Если вы закрыли доступ правильно, в логах могут остаться попытки обращения, но они уже не должны доходить до обработки WordPress.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если вы видите, что запросы продолжают выполняться как обычные POST и дают 200 OK, значит блокировка не сработала или сработала не там, где вы ожидали.

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

Самая частая ошибка — отключить XML-RPC в WordPress, но оставить открытым сам файл на сервере. В этом случае вы не убираете шум и не снижаете нагрузку так, как рассчитывали.

Еще одна типичная проблема — включить сразу несколько способов блокировки: фильтр в коде, правило в nginx и опцию в плагине. Потом сложно понять, что именно ломает интеграцию. Лучше выбрать один основной способ и один резервный, если это действительно нужно.

• Ошибка: блокировка через плагин, но без проверки логов.
  Что делать: проверьте реальные ответы на xmlrpc.php и поведение внешних сервисов.
• Ошибка: правило в .htaccess добавлено не в тот блок.
  Что делать: убедитесь, что конфиг Apache действительно читает этот файл и нет конфликтующих правил выше.
• Ошибка: в nginx правило стоит ниже общего location / и не срабатывает.
  Что делать: используйте точное совпадение location = /xmlrpc.php.
• Ошибка: отключили XML-RPC, но забыли про старую интеграцию.
  Что делать: сначала найдите источник обращений, потом режьте доступ.

Безопасность и производительность: что еще стоит сделать рядом

Если вы уже занялись XML-RPC, имеет смысл проверить соседние точки входа. Часто вместе с ним атакуют wp-login.php, перебирают пароли и пытаются нагрузить сайт лишними запросами. Здесь помогает не только блокировка, но и базовая гигиена: ограничение попыток входа, двухфакторная аутентификация для админов, актуальные обновления ядра и плагинов.

Если сайт на высоком трафике, блокировка на уровне nginx или WAF обычно предпочтительнее, чем только PHP-фильтр: так вы не тратите ресурсы на обработку заведомо ненужных запросов. Но если у вас нет доступа к серверу, кодовый вариант через xmlrpc_enabled все равно лучше, чем ничего.

Для сайтов, где важна чистка лишних функций и техническая оптимизация, удобно держать под рукой один инструмент, который закрывает несколько типовых задач сразу. Но даже в этом случае проверка после изменений обязательна: отключение функции без контроля логов часто создает ложное ощущение безопасности.

Что должно измениться после отключения

После корректной настройки вы должны увидеть три вещи: запросы к xmlrpc.php перестали доходить до WordPress, внешние сервисы не используют этот endpoint без необходимости, а в логах больше нет массовых попыток подбора или pingback-спама. Если хотя бы один пункт не выполняется, значит решение нужно доработать.

Практически это означает одно: сначала диагностика, потом один выбранный способ блокировки, затем проверка через запросы и логи. Такой порядок экономит время и не ломает рабочие сценарии на ровном месте.