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

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

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

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

Перед изменениями проверьте, не завязаны ли на XML-RPC:

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

Быстрая диагностика проблемы

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

Проверить наличие файла можно и вручную:

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

Если ответ возвращается, это еще не проблема. Вопрос в том, нужен ли вам этот endpoint вообще.

Как закрыть XML-RPC: три рабочих варианта

Есть несколько способов, и выбирать стоит по уровню контроля над сайтом. Самый безопасный для сопровождения — отключение через код в теме или mu-plugin. Самый быстрый — через сервер или плагин безопасности. Самый грубый — блокировка на уровне веб-сервера.

Вариант 1. Отключить XML-RPC через mu-plugin

Если нужен предсказуемый результат, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Mu-plugin загружается автоматически и не зависит от темы.

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

Это отключит XML-RPC на уровне WordPress. Если у вас нет каталога mu-plugins, создайте его вручную. Такой способ удобен тем, что его сложно случайно выключить из админки.

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

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

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

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

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

Такой вариант полезен, когда нагрузка от атак заметна в логах и вы хотите не тратить ресурсы на запуск WordPress для каждого запроса.

Вариант 3. Использовать плагин безопасности

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

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

Пошаговая схема внедрения без сюрпризов

1. Проверьте, есть ли у сайта реальные интеграции через XML-RPC.
2. Посмотрите логи на предмет обращений к /xmlrpc.php.
3. Выберите способ отключения: mu-plugin, сервер или существующий security-плагин.
4. Внесите изменение на staging, если он есть.
5. Проверьте вход в админку, публикацию записей и работу внешних сервисов.
6. После выката еще раз посмотрите логи и убедитесь, что endpoint больше не используется.

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

После отключения запрос к xmlrpc.php должен перестать обрабатываться WordPress. Проверка зависит от способа блокировки.

Если вы отключали через фильтр, выполните:

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

Ожидаемое поведение зависит от серверной конфигурации и способа блокировки. Это может быть 403 Forbidden, 404 Not Found или другой отказ в доступе. Важно, чтобы не возвращался стандартный ответ XML-RPC WordPress.

Если вы блокировали на уровне Nginx или Apache, проверьте еще и логи. В них не должно быть признаков того, что запрос дошел до PHP-обработки WordPress.

Дополнительно откройте админку и убедитесь, что:

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

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

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

Значит, сервис действительно использовал этот протокол. Решение не в том, чтобы «включить обратно всем», а в том, чтобы понять, чем именно он пользовался. Иногда можно перевести интеграцию на REST API или заменить способ публикации.

Поставили плагин, но endpoint все равно отвечает

Некоторые плагины отключают только часть функций или меняют поведение в админке, но не блокируют сам файл на уровне сервера. Если нужна жесткая блокировка, добавьте правило в Nginx/Apache или проверьте, не переопределяет ли что-то фильтр xmlrpc_enabled.

Закрыли доступ, но атаки продолжаются в логах

Это нормально: боты продолжают стучаться, даже если получают отказ. Важен не сам факт запросов, а то, что они больше не доходят до WordPress и не расходуют ресурсы PHP. Если нагрузка все еще заметна, смотрите в сторону rate limiting, fail2ban или правил на уровне CDN/WAF.

Сломали мобильную публикацию и не заметили сразу

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

Что еще стоит сделать вместе с отключением XML-RPC

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

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

Мини-чек-лист перед выкладкой

• Проверили, нужен ли XML-RPC хотя бы одному сервису.
• Выбрали способ отключения, который можно быстро откатить.
• Протестировали на staging или в окне низкой нагрузки.
• Проверили ответ на /xmlrpc.php и логи сервера.
• Убедились, что публикация и вход в админку работают.
• Зафиксировали изменение в технической документации сайта.

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