XML-RPC в WordPress до сих пор встречается на старых установках, но в большинстве проектов он не нужен. Если вы не используете мобильное приложение WordPress, внешние клиенты публикации или старые интеграции, этот интерфейс только расширяет поверхность атаки и добавляет лишний шум в логах. При этом отключать его нужно аккуратно: не сломать REST API, не перекрыть нужные эндпоинты и не получить ложное ощущение безопасности.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без побочных эффектов и как проверить результат после внедрения.
Когда XML-RPC действительно можно отключать
Сначала проверьте, есть ли у сайта реальные зависимости. Сам по себе факт, что плагин безопасности ругается на XML-RPC, еще не означает, что его можно бездумно рубить. На практике он нужен только в нескольких случаях:
- старое мобильное приложение WordPress;
- удаленная публикация через внешние клиенты, которые работают именно через XML-RPC;
- устаревшие интеграции с плагинами или сервисами, которые не перешли на REST API;
- некоторые инструменты синхронизации и мониторинга на старых проектах.
Если ничего из этого нет, отключение обычно оправдано. Но если у вас есть интеграция, которая отправляет посты, комментарии или пинги через XML-RPC, сначала переведите ее на REST API или другой способ обмена данными.
Диагностика: как понять, используется ли XML-RPC сейчас
Самый простой способ — посмотреть логи доступа веб-сервера и проверить запросы к /xmlrpc.php. Если там есть регулярные обращения от ваших сервисов, отключение может сломать часть сценариев. Если же видите только перебор логинов и массовые POST-запросы, это типичный кандидат на закрытие.
Проверка снаружи
Можно быстро проверить доступность файла вручную:
curl -I https://example.com/xmlrpc.phpНормальный ответ до отключения обычно будет не 404, а что-то вроде 405 Method Not Allowed или другой ответ WordPress/сервера на запрос без корректного тела. После блокировки вы должны увидеть 403, 404 или ответ, который явно говорит о запрете доступа.
Проверка по логам
Если есть доступ к логам, ищите строки с xmlrpc.php. Важно отличать легитимные обращения от атак. Для оценки полезно смотреть не только количество запросов, но и User-Agent, IP-адреса и частоту повторов. Если один и тот же адрес бьет по xmlrpc.php десятки раз в минуту, это уже не рабочая интеграция, а попытка подбора.
Пошаговое решение: как отключить XML-RPC без лишнего риска
Есть три нормальных подхода: через плагин безопасности, через серверную блокировку и через код. Выбор зависит от того, кто управляет проектом и насколько вам нужен контроль на уровне WordPress.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужна быстрая настройка без правок кода | Просто включить и проверить | Зависимость от плагина, лишняя нагрузка в админке |
| Код | Есть доступ к теме или mu-plugin | Прозрачно, без лишних зависимостей | Нужно аккуратно размещать и не потерять при обновлении темы |
| Серверная блокировка | Нужна защита до загрузки WordPress | Режет запросы раньше PHP | Требует доступа к конфигу сервера |
Вариант 1: отключение через код
Если вы хотите управляемое решение в самом WordPress, добавьте фильтр в mu-plugin или в собственный мини-плагин. Это надежнее, чем править functions.php активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант отключает сам XML-RPC на уровне WordPress. Если файл xmlrpc.php все еще доступен на сервере, запросы будут доходить до WordPress, но функциональность будет выключена.
Вариант 2: блокировка на уровне сервера
Если у вас Apache, можно закрыть файл напрямую через .htaccess. Это полезно, когда нужно отсечь обращения еще до запуска WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика зависит от конфигурации, но обычно используется отдельное правило для /xmlrpc.php. Важно не копировать чужие фрагменты без проверки синтаксиса: конфиг сервера лучше тестировать отдельно перед перезагрузкой.
Вариант 3: плагин безопасности
Если у вас уже стоит плагин, который умеет отключать XML-RPC, это допустимый путь. Но не стоит ставить отдельный плагин только ради одной галочки, если можно решить задачу кодом или серверным правилом. Лишний плагин — это еще один слой поддержки, обновлений и потенциальных конфликтов.
Что не стоит делать
Частая ошибка — просто удалить файл xmlrpc.php из ядра WordPress. Так делать не нужно. После обновления он вернется, а вы получите нестабильное состояние сайта и неочевидные проблемы при обслуживании. Правильнее либо отключить функциональность фильтром, либо закрыть доступ на уровне веб-сервера.
Еще одна ошибка — блокировать весь REST API вместе с XML-RPC. Это разные механизмы. REST API нужен для редактора блоков, внешних интеграций, некоторых плагинов и мобильных сценариев. Если вы его перекроете, проблемы будут уже не в безопасности, а в работоспособности сайта.
Проверка результата после внедрения
После отключения проверьте три вещи: доступность xmlrpc.php, работу админки и работу REST API. Это минимальный набор, который показывает, что вы не сломали лишнего.
- Откройте
https://example.com/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что ответ стал запрещающим или файл больше не отдается.
- Проверьте вход в админку, создание записи и загрузку редактора.
- Проверьте REST API, например
/wp-json/, чтобы убедиться, что он остался доступен.
Для быстрой проверки REST API подойдет такой запрос:
curl -I https://example.com/wp-json/Если REST API отвечает корректно, а xmlrpc.php закрыт, значит решение сработало как задумано.
Частые ошибки и как их исправить
XML-RPC отключили, но атаки в логах остались
Это нормально, если вы закрыли функциональность только на уровне WordPress, но не на уровне сервера. Запросы все еще доходят до файла и фиксируются в логах. Если хотите убрать шум раньше, добавьте серверное правило.
Сломалась внешняя интеграция
Значит, у вас был реальный потребитель XML-RPC. Верните доступ, найдите источник обращения и переведите его на REST API или другой канал. Не оставляйте открытым интерфейс только потому, что «что-то где-то может использоваться».
После правки .htaccess сайт начал отдавать 500
Обычно причина в неверном синтаксисе или в том, что правило вставили не в тот блок. Верните файл к рабочей версии, проверьте конфигурацию и вносите изменения по одному. Для Apache это особенно важно на сайтах с нестандартными правилами пермалинков.
REST API тоже перестал работать
Это уже ошибка в правилах блокировки. Проверьте, что вы закрывали только xmlrpc.php, а не весь каталог или все POST-запросы подряд. REST API должен остаться доступным, если он используется редактором, плагинами или фронтендом.
Практические советы по безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа. Если у вас слабые пароли, нет ограничения попыток входа и не обновляются плагины, закрытие одного файла мало что изменит. Но как часть общей гигиены это полезный шаг.
- используйте двухфакторную аутентификацию для админов;
- ограничьте попытки входа в админку;
- обновляйте ядро, темы и плагины;
- проверяйте, не открывает ли какой-то плагин лишние публичные эндпоинты;
- не держите в активной теме код, который можно вынести в mu-plugin.
Если вам нужен более широкий контроль над дублями, индексированием и технической чисткой сайта, иногда удобнее закрывать такие задачи не вручную, а через набор точечных настроек. В экосистеме WPShop для этого есть, например, Clearfy Pro: он не заменяет разработку, но помогает быстро убрать часть технического мусора и лишних точек доступа. Ссылка с UTM: Clearfy Pro.
Как понять, что решение действительно полезно
Хороший результат здесь измеряется не абстрактным «сайт стал безопаснее», а конкретными признаками:
xmlrpc.phpбольше не принимает рабочие запросы;- в логах стало меньше мусорных обращений к этому файлу;
- REST API продолжает отвечать;
- админка и редактор работают без ошибок;
- не осталось зависимых интеграций, о которых вы забыли.
Если все пять пунктов выполняются, XML-RPC можно считать закрытым без побочных эффектов. Если нет — возвращайтесь к диагностике и ищите, кто именно использует этот канал.