XML-RPC в WordPress часто отключают не «для галочки», а из-за конкретной проблемы: лишние запросы к xmlrpc.php, попытки подбора паролей, шум в логах или ненужная точка входа на сайте, где мобильное приложение WordPress и внешние сервисы не используются. Но отключать его вслепую нельзя: у некоторых сайтов через XML-RPC до сих пор работают публикации по удалёнке, интеграции с десктопными клиентами и старые сценарии синхронизации.
Ниже — рабочий способ отключить XML-RPC без плагинов, понять, нужен ли он вообще, и проверить, что защита действительно сработала.
Когда XML-RPC стоит отключать, а когда лучше не трогать
Если сайт обычный: вход в админку, публикация из браузера, никаких внешних клиентов и мобильной синхронизации — XML-RPC чаще всего не нужен. В этом случае его отключение уменьшает поверхность атаки и убирает лишний шум в логах.
Если же вы используете хотя бы один из сценариев ниже, сначала проверьте зависимость:
- публикация через мобильное приложение WordPress;
- подключение десктопных клиентов для редактирования записей;
- старые интеграции с внешними сервисами, которые обращаются к
xmlrpc.php; - синхронизация контента через сторонние инструменты, где явно указан XML-RPC.
Диагностика: как понять, что XML-RPC реально используется
Самый простой признак — обращения к /xmlrpc.php в access-логах веб-сервера. Если там только массовые запросы с разных IP и типичные попытки брутфорса, это хороший кандидат на отключение. Если видите регулярные запросы от известных сервисов или ваших устройств, сначала разберитесь, кто их делает.
Проверить доступность файла можно и вручную. Откройте в браузере https://ваш-домен.ru/xmlrpc.php. Если XML-RPC включён, WordPress обычно отвечает сообщением о том, что запросы к этому файлу принимаются только через POST. Это не доказательство использования, но подтверждение, что точка входа открыта.
Если есть доступ к серверу, полезно посмотреть логи за последние дни и отфильтровать обращения к этому пути. На практике этого достаточно, чтобы понять, есть ли живые клиенты или только сканеры.
Как отключить XML-RPC без плагинов
Есть два надёжных подхода: через PHP-фильтр в теме или mu-plugin, и через веб-сервер. Для WordPress-проекта обычно удобнее начать с PHP-способа: он переносимее и проще откатывается.
Способ 1: отключить XML-RPC через functions.php или mu-plugin
Если вы работаете с темой, добавьте код в functions.php. Но для постоянного технического решения лучше использовать mu-plugin, чтобы отключение не зависело от смены темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Этого достаточно, чтобы WordPress перестал принимать XML-RPC-запросы на уровне ядра. Если нужен более явный контроль, можно дополнительно заблокировать сам файл на раннем этапе загрузки:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );
Первый вариант обычно предпочтительнее: он короче и использует штатный фильтр WordPress. Второй вариант полезен, если вы хотите явно вернуть 403 и не полагаться только на поведение ядра.
Способ 2: заблокировать xmlrpc.php на уровне сервера
Если сайт под атакой или вы хотите отсечь запросы ещё до PHP, можно закрыть доступ на уровне веб-сервера. Это снижает нагрузку, потому что запрос не доходит до WordPress.
Для Apache в .htaccess можно добавить правило:
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx обычно используют отдельное правило в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Если у вас уже есть интеграции, не спешите применять серверную блокировку без проверки. Она жёстче, чем фильтр WordPress, и может сломать внешние клиенты без понятного сообщения об ошибке.
Что выбрать: плагин, код или серверное правило
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Код в WordPress | Просто откатить, не зависит от панели хостинга | Запрос всё ещё доходит до PHP | Обычный сайт, нужен быстрый и безопасный старт |
| Правило на сервере | Режет запрос раньше, экономит ресурсы | Нужен доступ к конфигу, можно сломать интеграции | Сайт под нагрузкой или под атакой |
| Плагин безопасности | Удобно для админов без доступа к коду | Лишняя зависимость, иногда дублирует то, что можно сделать штатно | Если в проекте уже есть централизованный security-плагин |
Если у вас уже стоит комплексный плагин для технической чистки и SEO, например Clearfy Pro, проверьте, не дублирует ли он эту настройку. Но для точечной задачи отключения XML-RPC кодом обычно достаточно.
Проверка результата после внедрения
После отключения нужно проверить не только страницу в браузере, но и фактический ответ сервера. Иначе можно получить ложное ощущение безопасности.
Проверка через браузер
Откройте /xmlrpc.php. Если вы закрыли доступ через WordPress-фильтр, поведение может отличаться в зависимости от окружения, но сам файл не должен работать как активная точка входа для XML-RPC.
Проверка через curl
Надёжнее отправить POST-запрос и посмотреть код ответа:
curl -i -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'
Если всё отключено корректно, вы должны увидеть отказ в доступе, 403 или другое явное сообщение о запрете. Если приходит обычный XML-RPC-ответ, значит блокировка не сработала или сработала не там, где нужно.
Проверка по логам
После внедрения посмотрите access- и error-логи. Важно убедиться, что:
- запросы к
/xmlrpc.phpбольше не проходят успешно; - нет ошибок PHP, связанных с вашим кодом;
- не сломались легитимные интеграции, если они были.
Частые ошибки и как их исправить
Ошибка 1: отключили XML-RPC, а сайт всё равно принимает запросы. Обычно код добавили не туда: в неактивную тему, в файл, который не загружается, или в плагин, который отключён. Для проверки лучше использовать mu-plugin или временно добавить код в активную тему и сразу протестировать.
Ошибка 2: закрыли xmlrpc.php на сервере и сломали интеграцию. Значит, до внедрения не проверили зависимость. Откатите правило, найдите источник запросов и решите, можно ли заменить его REST API или другим способом.
Ошибка 3: поставили security-плагин, но не поняли, что именно он делает. Некоторые плагины отключают XML-RPC вместе с другими функциями. Если потом что-то перестаёт работать, сложно быстро найти причину. Для точечных задач лучше явное правило или небольшой кусок кода.
Ошибка 4: проверяют только GET-запрос в браузере. XML-RPC работает через POST. Браузерная проверка полезна, но не достаточна. Обязательно делайте POST через curl или Postman.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — хороший базовый шаг, но не единственный. На практике стоит ещё:
- ограничить попытки входа в админку;
- включить двухфакторную аутентификацию для администраторов, если это поддерживает ваш стек;
- следить за логами на предмет массовых запросов к
xmlrpc.phpиwp-login.php; - не смешивать отключение XML-RPC с другими изменениями безопасности в одном коммите, если потом нужно быстро искать причину сбоя.
Если проект большой и у него несколько сред, фиксируйте это изменение отдельно: так проще проверить, где именно блокировка включена, а где нет. Для production-сайта это особенно важно, если доступ к серверу и к WordPress-разработке разделён между разными людьми.
В итоге рабочая схема простая: сначала убедиться, что XML-RPC действительно не нужен, затем отключить его через фильтр WordPress или на уровне сервера, после этого проверить ответ xmlrpc.php через POST и посмотреть логи. Это тот случай, где короткое техническое решение лучше длинной «безопасности через плагин», если вы понимаете, что именно закрываете.