XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, удалённая публикация или старые интеграции с внешними сервисами. Проблема в том, что этот интерфейс нужен не только для атак и brute force, но и для вполне легитимных сценариев. Поэтому правильный подход здесь не «рубить всё подряд», а сначала понять, используется ли он вообще.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удалённую публикацию, старые клиенты для WordPress и интеграции, завязанные на XML-RPC, его можно закрыть. На большинстве современных проектов вместо него используют REST API, а для публикации и администрирования — панель WordPress или отдельные сервисы с нормальной авторизацией.
Отключение особенно уместно, если в логах видно много запросов к /xmlrpc.php, а в админке нет ни одного сценария, который от него зависит. Но если сайт синхронизируется с внешним редактором, мобильным приложением или старой системой автопостинга, сначала проверьте совместимость.
Что обычно ломается после отключения
- удалённая публикация из старых клиентов и сервисов;
- некоторые мобильные приложения и десктопные редакторы;
- интеграции, которые используют методы
system.multicallилиwp.getUsersBlogs; - часть устаревших плагинов для автопостинга и синхронизации.
Диагностика: используется ли XML-RPC сейчас
Перед изменениями посмотрите, есть ли реальные запросы к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. В логах ищите обращения к файлу и частоту запросов. Если их много и они идут не от ваших сервисов, это уже аргумент в пользу отключения.
Ещё один практичный тест — временно ограничить доступ только для своего IP или для тестовой копии сайта и проверить, не отвалятся ли внешние сценарии. Если ничего не сломалось, можно переходить к постоянному отключению.
Быстрая проверка через HTTP-ответ
На живом сайте откройте https://example.com/xmlrpc.php. Если XML-RPC активен, WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не значит, что всё безопасно, но подтверждает, что endpoint доступен.
curl -I https://example.com/xmlrpc.phpЕсли вы уже закрыли доступ, ответ может быть 403, 404 или редирект на другую страницу — это нормально, если так и было задумано.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных способа: через плагин, через код и через веб-сервер. Выбор зависит от того, кто управляет сайтом и насколько жёстко нужно закрыть доступ.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правок кода | Лишняя зависимость | Если нужен простой способ для админов |
| Код в теме или mu-plugin | Контроль, без тяжёлых плагинов | Нужно не забыть о переносе при смене темы | Для проектов с доступом к коду |
| Веб-сервер | Закрывает запросы раньше WordPress | Нужны права на конфиг | Если нужен более жёсткий уровень защиты |
Вариант 1: отключение через код
Если вам нужен предсказуемый и лёгкий способ, добавьте фильтр в functions.php дочерней темы или, лучше, в mu-plugin. Так решение не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, если нет особых требований к блокировке на уровне сервера.
Вариант 2: блокировка через .htaccess
Если сайт работает на Apache или LiteSpeed, можно закрыть доступ к файлу xmlrpc.php на уровне веб-сервера. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика будет другой: правило добавляют в конфигурацию сервера. Важно не копировать чужие фрагменты без проверки синтаксиса и совместимости с текущей схемой обработки PHP.
Вариант 3: плагин для управления безопасностью
Если на сайте уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC без лишних побочных эффектов. Но не ставьте отдельный плагин только ради одной функции, если задача решается одной строкой кода. Лишний плагин — это ещё одна точка обновлений и потенциальных конфликтов.
Пошаговое решение без сюрпризов
- Проверьте логи и убедитесь, что XML-RPC не нужен вашим интеграциям.
- Сделайте резервную копию файлов и базы.
- Выберите способ отключения: код, сервер или существующий security-плагин.
- Внесите изменение на staging-копии, если она есть.
- Проверьте доступ к
/xmlrpc.phpи основные сценарии входа в админку. - Если всё работает, перенесите изменение на боевой сайт.
Как проверить, что отключение сработало
После внедрения проверьте не только сам URL, но и реальные пользовательские сценарии. Это важнее, чем просто увидеть 403.
- откройте
/xmlrpc.phpв браузере или черезcurl; - проверьте, что в логах больше нет успешных обращений к этому файлу;
- убедитесь, что вход в админку работает как раньше;
- если у вас есть внешняя интеграция, прогоните тестовую публикацию или синхронизацию;
- посмотрите, не появились ли ошибки в журнале PHP или в логах плагина безопасности.
Если вы закрывали доступ через сервер, полезно проверить и заголовки ответа, и код состояния. Иногда правило написано так, что файл не блокируется полностью, а просто редиректится — это не всегда то, что нужно.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать мобильный клиент
Значит, клиент или сервис реально использовал XML-RPC. В этом случае либо возвращайте доступ, либо переводите интеграцию на другой способ авторизации и публикации. Не стоит держать закрытый endpoint и надеяться, что всё само восстановится.
Добавили правило в .htaccess, но оно не сработало
Частая причина — сайт работает не на Apache, а на Nginx, или правило стоит не в том месте файла. Ещё одна проблема — конфликт с другими директивами. Если сомневаетесь, проверьте конфигурацию сервера и логи ошибок.
Поставили плагин, а сайт стал медленнее
Для отключения одной функции плагин часто избыточен. Если он нужен только ради XML-RPC, проще заменить его кодом или серверным правилом. Так меньше вероятность конфликтов и лишней нагрузки.
Закрыли XML-RPC, но атаки не прекратились
Это нормально: злоумышленники часто сканируют разные endpoints. Закрытие одного файла не заменяет базовую гигиену безопасности — обновления ядра, тем и плагинов, ограничение попыток входа, нормальные пароли и двухфакторную аутентификацию для админов.
Что ещё сделать для безопасности и производительности
Если вы уже чистите технический слой сайта, проверьте соседние точки риска: лишние плагины, старые интеграции, неиспользуемые REST-маршруты в кастомном коде, открытые тестовые поддомены. Иногда именно они создают больше проблем, чем сам XML-RPC.
Для проектов, где нужно одновременно убрать дубли, подчистить служебные элементы и не перегружать сайт отдельными плагинами, имеет смысл смотреть в сторону комплексных решений вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и здесь правило то же самое: сначала проверяйте, какие функции реально нужны, а какие только создают лишний шум.
Если нужен короткий практический вывод: отключайте XML-RPC только после проверки интеграций, закрывайте его тем способом, который соответствует вашему стеку, и обязательно тестируйте не только URL, но и реальные сценарии публикации и входа.