XML-RPC в WordPress до сих пор часто остаётся включённым по умолчанию, хотя большинству сайтов он не нужен. Если вы не используете старые мобильные клиенты, внешние сервисы публикации или интеграции, которые завязаны именно на XML-RPC, этот интерфейс лучше закрыть. На практике это снижает поверхность атаки и убирает один из частых источников брутфорса.
Но отключать его стоит не «на всякий случай», а после проверки зависимостей. Иначе можно сломать публикацию через сторонний сервис, синхронизацию с приложением или удалённую работу с сайтом.
Когда XML-RPC действительно можно отключать
Сначала проверьте, используется ли он вообще. На обычном сайте без внешних интеграций ответ чаще всего будет «нет». Если вы заходите в админку напрямую, публикуете записи из панели WordPress и не подключали сторонние клиенты, XML-RPC обычно не нужен.
Типичные сценарии, где он не нужен
- сайт управляется только через wp-admin;
- нет старых мобильных приложений WordPress;
- не используются сервисы автопостинга через XML-RPC;
- не подключены внешние системы, которые работают именно через этот протокол.
Когда отключать нельзя без проверки
Если у вас есть интеграции с внешними редакторами, приложениями для публикации или сервисами, которые были настроены много лет назад, сначала проверьте документацию этих сервисов. Некоторые из них уже перешли на REST API, но не все.
Диагностика: как понять, что XML-RPC открыт
Самый простой способ — открыть файл /xmlrpc.php в браузере. Если он доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это нормальный признак того, что endpoint жив.
Ещё полезнее проверить ответ через команду curl:
curl -i https://example.com/xmlrpc.phpЕсли endpoint включён, вы увидите HTTP-ответ от WordPress. Если он закрыт на уровне сервера или правилами безопасности, ответ может быть 403 или 404.
Для сайта под нагрузкой полезно посмотреть логи веб-сервера. Если в access log много запросов к /xmlrpc.php, это почти всегда признак автоматизированных попыток подбора пароля.
Что лучше: плагин, .htaccess или код
Есть три рабочих подхода. Выбор зависит от того, нужен ли вам быстрый откат и насколько вы контролируете сервер.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро включить и отключить, не трогая сервер | Лишняя зависимость от плагина | Если нет доступа к конфигам сервера или нужен простой откат |
| .htaccess / nginx | Блокировка на уровне веб-сервера | Нужно аккуратно править конфиг | Если вы администрируете сервер и хотите жёстко закрыть endpoint |
| Код в теме или mu-plugin | Не нужен отдельный плагин | Менее удобно сопровождать, чем серверное правило | Если нужен контроль из кода проекта |
Пошаговое решение через код
Если вам нужно отключить XML-RPC из WordPress-кода, используйте фильтр xmlrpc_enabled. Это самый понятный вариант для проекта, который вы контролируете.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код можно добавить в functions.php дочерней темы, но на практике надёжнее вынести его в mu-plugin, чтобы он не зависел от темы.
Пример минимального mu-plugin:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужно не только отключить сам XML-RPC, но и убрать доступ к файлу на уровне сервера, добавьте правило в .htaccess для Apache:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика другая — правило добавляется в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если у вас уже есть WAF или плагин безопасности, не дублируйте блокировки без необходимости. Достаточно одного понятного механизма, который вы сможете потом быстро проверить и поддерживать.
Пошаговое решение через плагин
Если вы не хотите править код, используйте плагин, который умеет отключать XML-RPC. Это удобно для сайтов, где изменения делают не разработчики, а редакторы или администраторы без доступа к серверу.
Но здесь важно не ставить случайный «комбайн» ради одной функции. Если у вас уже есть плагин для технической оптимизации, проверьте, не умеет ли он закрывать XML-RPC и другие лишние endpoints. Например, в Clearfy Pro есть набор функций для чистки и SEO-оптимизации сайта: https://wpshop.ru/plugins/clearfy?utm_source=wp-kurs.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xmlrpc-v-wordpress-cherez-htaccess-i-plagin.
Плюс плагина в том, что отключение можно быстро вернуть назад, если какой-то внешний сервис перестал работать. Минус — это ещё одна точка отказа и ещё один слой, который нужно обновлять.
Как проверить, что решение сработало
После внедрения обязательно проверьте не только сам endpoint, но и побочные эффекты. Это тот случай, когда «в админке всё открывается» ещё не означает, что всё сделано правильно.
- Откройте
/xmlrpc.phpв браузере: доступ должен быть закрыт или не должен отдавать рабочий ответ WordPress. - Проверьте
curl -i https://example.com/xmlrpc.php: ожидайте403или другой отказ, если блокировка серверная. - Посмотрите логи: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Проверьте внешние сервисы, которые могли использовать XML-RPC: публикация, синхронизация, мобильные приложения.
Если вы отключали XML-RPC через фильтр, а endpoint всё ещё отвечает, значит правило не подхватилось. Частая причина — код добавлен не туда или кэш страницы мешает увидеть актуальный ответ. Но кэш обычно не влияет на сам xmlrpc.php, поэтому сначала ищите ошибку в месте внедрения.
Частые ошибки и как их исправить
Отключили не тем способом
Иногда XML-RPC пытаются «закрыть» через визуальные настройки плагина безопасности, но потом забывают, где именно это было сделано. В результате после обновления плагина или смены настроек endpoint снова открывается. Если нужен предсказуемый результат, лучше использовать серверное правило или код, который вы контролируете.
Сломали интеграцию, о которой не знали
Это типичная ситуация на старых проектах. Сайт работает, но перестаёт публиковать записи из внешнего клиента или синхронизироваться с сервисом, который давно не трогали. Решение простое: временно верните доступ, найдите зависимость, а потом переведите её на REST API или другой поддерживаемый способ интеграции.
Добавили правило в неправильный конфиг
Для Apache и nginx синтаксис разный. Если вы вставили <Files> в конфиг nginx, это не сработает. Если правите .htaccess, убедитесь, что сервер вообще читает этот файл и что для каталога разрешены переопределения.
Проверили только в браузере
Браузерный тест не всегда достаточен. xmlrpc.php может отвечать иначе на GET и POST. Для проверки лучше использовать curl или хотя бы посмотреть реальные запросы в логах.
Что ещё можно сделать для безопасности
Отключение XML-RPC — не замена нормальной защите входа. Если на сайте идут брутфорс-атаки, проверьте ещё несколько вещей:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальные версии WordPress, темы и плагинов;
- отсутствие лишних админ-аккаунтов;
- защиту
/wp-login.phpна уровне WAF или плагина безопасности.
Если сайт работает на VPS или выделенном сервере, серверная блокировка обычно надёжнее, чем только плагин. Но для небольших проектов с ограниченным доступом к конфигам плагин тоже допустим, если вы понимаете, где именно он вмешивается.
В итоге правильный порядок такой: сначала проверить, нужен ли XML-RPC, потом выбрать способ блокировки, затем протестировать доступ и убедиться, что не пострадали внешние интеграции. Это тот случай, где аккуратная диагностика экономит больше времени, чем последующее «откатывание» сломанной настройки.
