XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или интеграции, которые до сих пор ходят в /xmlrpc.php. Поэтому нормальный сценарий здесь не «рубим всё», а сначала проверяем, кто именно использует этот интерфейс, и только потом выбираем способ отключения.
Если задача — убрать лишнюю поверхность атаки, снизить шум от брутфорса и при этом не сломать рабочие интеграции, XML-RPC лучше отключать осознанно. Ниже — рабочая схема: диагностика, варианты решения, проверка результата и типичные ошибки.
Когда XML-RPC действительно стоит отключать
Сам по себе файл xmlrpc.php не является уязвимостью, но он часто используется для перебора паролей и запросов, которые создают лишнюю нагрузку. Если вы не публикуете записи через старые внешние клиенты, не используете Jetpack в режиме, где ему нужен XML-RPC, и не подключали сторонние сервисы с этой схемой авторизации, отключение обычно оправдано.
Но есть и обратная сторона: некоторые мобильные приложения, интеграции для автопостинга и старые плагины до сих пор завязаны именно на XML-RPC. Поэтому перед изменениями полезно понять, есть ли обращения к этому endpoint в логах.
Диагностика: кто стучится в /xmlrpc.php
Начните с логов веб-сервера. Если видите частые POST-запросы к /xmlrpc.php с разных IP, это типичный шум брутфорса или сканирования. Если же запросов мало, но они идут от знакомого сервиса, отключение надо делать точечно или искать замену.
Что искать в access log
Примерно так выглядят запросы, которые стоит проверить:
POST /xmlrpc.php HTTP/1.1Если у вас есть доступ к логам Nginx или Apache, посмотрите частоту запросов и IP-адреса. Важно не просто увидеть факт обращения, а понять, есть ли среди них легитимные клиенты. Для этого полезно сопоставить время запросов с действиями в админке, публикациями через приложение или работой интеграции.
Быстрая проверка снаружи
Можно проверить, отвечает ли endpoint вообще. Если сайт публичный, достаточно открыть https://ваш-домен/xmlrpc.php. В норме WordPress обычно возвращает сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не означает, что всё безопасно, но показывает, что файл доступен.
Если вам нужен более технический тест, отправьте POST-запрос:
curl -i -X POST https://example.com/xmlrpc.phpПосле отключения вы должны получить запрет или 404/403 в зависимости от выбранного способа. Но важно не только увидеть блокировку, а убедиться, что не сломались нужные сценарии.
Как отключить XML-RPC: три рабочих подхода
Есть три нормальных варианта: через плагин безопасности, через код в теме или mu-plugin, и на уровне веб-сервера. У каждого свой компромисс по удобству и контролю.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правки кода | Дополнительная зависимость | Если нужен простой переключатель и сайт уже использует security-плагин |
| Код | Контроль, без лишних плагинов | Нужно аккуратно разместить код | Если есть доступ к теме или mu-plugins |
| Веб-сервер | Режет запросы раньше WordPress | Зависит от конфигурации хостинга | Если хотите блокировать на уровне Nginx/Apache |
Вариант 1: отключить через код
Если нужна именно деактивация на уровне WordPress, используйте фильтр 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, но не всегда режет доступ к файлу на уровне веб-сервера. Для большинства задач этого достаточно, но если цель — именно убрать шум и лишние обращения, лучше дополнить блокировкой на сервере.
Вариант 2: заблокировать на уровне Nginx или Apache
Если у вас есть доступ к конфигурации сервера, можно отдать 403 для xmlrpc.php. Это полезно, когда вы хотите отсечь запросы до загрузки WordPress.
Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache в .htaccess можно использовать правило на основе Files:
<Files xmlrpc.php>
Require all denied
</Files>Этот путь хорош тем, что WordPress даже не стартует для таких запросов. Но если хостинг управляемый и вы не уверены, как именно у него устроена обработка правил, сначала проверьте на тестовом стенде.
Вариант 3: использовать плагин безопасности
Если у вас уже стоит security-плагин и там есть отключение XML-RPC, это допустимый вариант. Но не ставьте отдельный плагин только ради одной галочки: лишняя зависимость ради одной функции обычно не оправдана. Если вы уже используете, например, Clearfy Pro для чистки сайта и технических настроек, проверьте, нет ли там нужной опции в вашем наборе задач: https://wpshop.ru/plugins/clearfy.
Пошаговое решение без сюрпризов
- Проверьте логи и найдите, кто обращается к
/xmlrpc.php. - Составьте список сервисов, которые могут использовать XML-RPC: мобильные приложения, старые клиенты публикации, интеграции, Jetpack.
- Выберите способ отключения: код, сервер или существующий security-плагин.
- Сначала примените изменение на staging-копии сайта.
- Проверьте публикацию записи, вход в админку, работу API и внешних интеграций.
- После успешной проверки перенесите изменение на production.
Если у вас есть сомнения по совместимости, начните с мягкого варианта: отключите XML-RPC через фильтр xmlrpc_enabled. Если всё работает, позже можно усилить защиту на уровне сервера.
Как проверить, что отключение сработало
Проверка должна быть не только технической, но и прикладной. Сначала убедитесь, что endpoint больше не отвечает как раньше:
curl -i -X POST https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки: 403 Forbidden, 404 Not Found или сообщение о том, что XML-RPC отключён. Главное — не получить обычный ответ WordPress на POST-запрос.
Затем проверьте реальные сценарии:
- публикация и редактирование записей в админке;
- работа мобильного приложения WordPress, если оно используется;
- подключение внешних сервисов, которые могут ходить через XML-RPC;
- отсутствие новых запросов к
/xmlrpc.phpв логах после изменения.
Если после отключения сайт перестал синхронизироваться с каким-то сервисом, не возвращайте XML-RPC целиком без проверки. Лучше выяснить, можно ли перевести интеграцию на REST API или другой способ авторизации.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом сломали Jetpack
Jetpack в некоторых сценариях использует XML-RPC для связи с WordPress.com. Если модуль нужен, проверьте его документацию и текущую схему подключения. Иногда проблема решается не возвратом XML-RPC, а сменой способа интеграции.
Поставили отдельный плагин ради одной функции
Это лишняя нагрузка и ещё одна точка отказа. Если задача только в блокировке XML-RPC, код или серверное правило обычно чище.
Добавили правило в .htaccess, но оно не сработало
На некоторых хостингах Apache может быть не единственным слоем, а правила перезаписываются конфигурацией платформы. В таком случае проверьте, не используется ли Nginx перед Apache, и не блокирует ли хостинг прямое редактирование .htaccess.
Отключили XML-RPC, но атаки в логах остались
Это нормально, если блокировка сделана только на уровне WordPress: запросы всё равно доходят до сервера. Чтобы убрать шум раньше, переносите блокировку на веб-сервер или на WAF/CDN.
Безопасность и производительность: что ещё имеет смысл сделать рядом
Отключение XML-RPC полезно, но не стоит считать его полноценной защитой. Если у вас открыта авторизация по паролю, слабые учётные записи и нет ограничения попыток входа, брутфорс найдёт другой путь. Поэтому рядом обычно проверяют ещё несколько вещей:
- включён ли двухфакторный вход для администраторов;
- нет ли одинаковых паролей у нескольких пользователей;
- ограничены ли попытки входа;
- не открыт ли
/wp-login.phpдля массового перебора без защиты; - не включены ли лишние публичные endpoint'ы и старые плагины.
Если сайт активно использует REST API и современную интеграцию, лучше постепенно переводить внешние сценарии на него, а не держаться за XML-RPC как за универсальный шлюз. Это не всегда мгновенная замена, но в долгую такой подход обычно проще сопровождать.
И ещё практический момент: если вы вносите изменения на уровне сервера, фиксируйте их в конфигурации, а не в ручных временных правках. Иначе через обновление шаблона, миграцию или перенос сайта блокировка легко потеряется.