XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом именно через него получают лишние запросы, перебор паролей и шум в логах. Если вы не пользуетесь мобильным приложением WordPress, Jetpack или внешними сервисами, которые ходят в сайт через xmlrpc.php, этот интерфейс обычно можно отключить без потерь.
Но отключать его вслепую не стоит: сначала проверьте, кто и зачем его использует. Иначе можно сломать публикацию из стороннего клиента, синхронизацию с Jetpack или интеграцию, о которой давно забыли.
Когда XML-RPC действительно стоит отключать
Сценарий простой: в логах много обращений к /xmlrpc.php, сайт получает попытки подбора пароля, а вы не используете старые внешние клиенты. В этом случае XML-RPC — лишняя поверхность атаки. Для большинства обычных сайтов админка, REST API и стандартный вход в WordPress закрывают все рабочие задачи.
Что обычно ломается после отключения
- мобильное приложение WordPress;
- Jetpack и сервисы, которые используют XML-RPC для связи с сайтом;
- старые внешние публикационные клиенты;
- некоторые интеграции для удалённой публикации и пинга.
Если хотя бы один из этих пунктов вам нужен, сначала найдите альтернативу. Для большинства современных задач лучше использовать REST API или штатные механизмы плагина, а не держаться за XML-RPC.
Диагностика: как понять, используется ли XML-RPC
Перед изменениями посмотрите, есть ли реальные обращения к xmlrpc.php. Это можно сделать по логам веб-сервера или через инструменты хостинга. Ищите не только частоту запросов, но и успешные вызовы: если идут только 401/403 и повторяющиеся POST-запросы, это типичный перебор.
Полезно проверить и сам WordPress: если у вас установлен Jetpack, включён мобильный клиент или есть старый плагин синхронизации, отключение может повлиять на работу сайта. Если сомневаетесь, временно ограничьте доступ к файлу на уровне сервера и посмотрите, не появятся ли ошибки у админов или интеграций.
Как отключить XML-RPC: рабочие способы
Есть три нормальных варианта: через код, через сервер и через плагин безопасности. Выбор зависит от того, где вам удобнее контролировать правило и нужно ли оставить исключения.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Просто, прозрачно, легко откатить | Нужно не забыть после смены темы |
| Правило на сервере | Блокирует запросы раньше WordPress | Зависит от конфигурации Apache/Nginx |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость от плагина |
Способ 1. Отключить XML-RPC через код
Самый предсказуемый вариант — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так правило не пропадёт при обновлении темы.
<?php
add_filter('xmlrpc_enabled', '__return_false');Если нужен более гибкий контроль, можно не отключать всё целиком, а точечно блокировать опасные методы. Но для обычного сайта это уже избыточно: проще выключить интерфейс полностью и не оставлять лишних исключений.
Способ 2. Заблокировать xmlrpc.php на уровне сервера
Этот способ полезен, если вы хотите отрезать запросы ещё до загрузки WordPress. Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика обычно задаётся в конфигурации сайта. Конкретный блок зависит от сборки, но смысл один: вернуть 403 на запросы к /xmlrpc.php. Если у вас нет доступа к конфигу, не пытайтесь имитировать это через WordPress — защита будет слабее и нагрузка всё равно дойдёт до PHP.
Способ 3. Использовать плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, это нормальный вариант для быстрого внедрения без правки кода. Но не ставьте отдельный плагин только ради одной галочки, если задача решается одной строкой кода или правилом сервера.
Если нужен более широкий набор технических чисток, блокировки дублей и базовая защита от лишних запросов, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и там важно не включать всё подряд без проверки, особенно на живом сайте.
Пошаговое решение без лишних рисков
- Проверьте, используется ли XML-RPC внешними сервисами.
- Сделайте резервную копию конфигурации и файлов, если меняете серверное правило.
- Выберите один способ блокировки: код, сервер или плагин.
- Примените правило на тестовой среде или в окно низкой нагрузки.
- Проверьте, что
/xmlrpc.phpотдаёт 403 или не отвечает как раньше. - Посмотрите, не появились ли ошибки у Jetpack, мобильного приложения или публикационных клиентов.
Проверка результата после внедрения
После отключения откройте https://ваш-домен/xmlrpc.php. Нормальный результат — запрет доступа или пустой ответ без возможности выполнить методы XML-RPC. Если страница по-прежнему отвечает как раньше, значит правило не применилось или его перебивает другое правило на сервере.
Дополнительно проверьте логи доступа. Если атаки продолжаются, но теперь получают 403, значит вы закрыли саму точку входа. Это хороший признак: WordPress больше не тратит ресурсы на обработку этих запросов.
Если у вас есть Jetpack или сторонняя интеграция, протестируйте их отдельно. Не ограничивайтесь открытием главной страницы: именно интеграции чаще всего показывают проблему уже после внедрения.
Частые ошибки и как их исправить
Отключили XML-RPC в коде, но он всё ещё доступен
Частая причина — код добавили в неактивную тему или в файл, который не загружается. Для такого правила лучше использовать mu-plugin, чтобы оно не зависело от темы. Ещё одна причина — кэш на уровне сервера или CDN, который отдаёт старый ответ на проверочный запрос.
Сломался Jetpack или мобильное приложение
Значит, XML-RPC был нужен. В такой ситуации не нужно «чинить» отключение, если сервис действительно важен. Лучше оставить доступ и ограничить его на уровне WAF, fail2ban или правил безопасности, а не отрезать полностью.
Поставили несколько способов блокировки сразу
Так делать не стоит: потом сложно понять, какое правило реально сработало и где искать конфликт. Сначала оставьте один способ, проверьте результат, и только потом добавляйте дополнительные меры, если они действительно нужны.
Проверили только в браузере
Браузерный тест не всегда показывает реальную картину. XML-RPC — это POST-эндпоинт, и его лучше проверять через логи, curl или хотя бы прямым запросом к /xmlrpc.php. Иначе можно пропустить ситуацию, когда страница открывается, но методы всё ещё доступны.
Что делать вместо XML-RPC, если нужен удалённый доступ
Если задача — не «сломать старое», а безопасно публиковать и управлять сайтом извне, смотрите в сторону REST API и штатных механизмов авторизации. Для современных интеграций это обычно более понятный и контролируемый путь. А если нужен именно контентный сценарий с внешней автоматизацией, лучше сразу проектировать его под REST API, а не держать включённым устаревший интерфейс ради одного клиента.
Практические советы по безопасности и производительности
- не оставляйте XML-RPC включённым без причины, если сайт открыт в интернет;
- проверяйте логи после внедрения, а не только сам факт 403;
- не ставьте отдельный плагин, если достаточно одной строки в mu-plugin;
- если используете CDN или WAF, убедитесь, что правило не конфликтует с их кэшированием и фильтрацией;
- не смешивайте отключение XML-RPC с другими изменениями безопасности в один большой релиз без теста.
Если вам нужен не только этот пункт, но и чистка дублей, отключение лишних компонентов и базовая техническая оптимизация, удобно держать всё в одном месте, а не разносить по десятку плагинов. Но любое решение всё равно стоит проверять на staging-сайте, а не на боевом домене.