XML-RPC в WordPress часто оставляют включенным «на всякий случай», а потом удивляются лишним запросам, брутфорсу по /xmlrpc.php и странным ошибкам в логах. Проблема в том, что отключать его вслепую нельзя: у части сайтов через XML-RPC до сих пор работают Jetpack, публикация из внешних клиентов и некоторые старые интеграции.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его безопасно и как проверить, что после изменений ничего не отвалилось.
Когда XML-RPC действительно стоит отключить
Если вы не используете внешние клиенты для публикации и не завязаны на Jetpack-функции, XML-RPC обычно не нужен. На практике его отключают в трех случаях:
- на сайте идут попытки подбора пароля через
xmlrpc.php; - в логах много запросов к XML-RPC, хотя вы не используете этот интерфейс;
- нужно сократить поверхность атаки на сайте, где уже есть REST API и обычная админка.
Но есть и обратная сторона. Если у вас подключен Jetpack, мобильное приложение WordPress, внешняя CMS или сервисы автопостинга, отключение XML-RPC может сломать синхронизацию или публикацию. Поэтому сначала проверьте зависимости, а потом уже меняйте конфигурацию.
Диагностика: как понять, используется ли XML-RPC
Самый простой способ — посмотреть, есть ли обращения к /xmlrpc.php в access-логах веб-сервера. Если у вас Nginx, ищите строки с этим путем. Если Apache — смотрите access log сайта. Важно не только наличие запросов, но и их источник: если это ваши сервисы, отключение вызовет проблемы; если это случайный трафик и брутфорс, отключение оправдано.
Можно проверить и вручную через браузер или curl. При включенном XML-RPC WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не ошибка, а признак того, что endpoint доступен.
curl -I https://example.com/xmlrpc.phpЕсли вы видите ответ сервера, endpoint открыт. Это еще не значит, что он используется, но значит, что его можно атаковать и сканировать.
Что проверить перед отключением
- подключен ли Jetpack и какие его модули реально используются;
- есть ли мобильное приложение WordPress у редакторов;
- используются ли внешние сервисы публикации или импорта;
- есть ли в логах регулярные POST-запросы к
xmlrpc.phpот ваших IP или сторонних сервисов.
Пошаговое решение: как отключить XML-RPC
Есть три нормальных подхода: через код, через сервер и через плагин безопасности. Если нужен контроль без лишних зависимостей, лучше начать с кода. Если задача — отрезать запросы еще до загрузки WordPress, удобнее блокировать на уровне Nginx или Apache.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Просто откатить, не зависит от сервера | WordPress все равно загружается |
| Правило на сервере | Блокирует запрос раньше, экономит ресурсы | Нужно аккуратно править конфиг |
| Плагин безопасности | Удобно для админов без доступа к серверу | Добавляет еще один слой логики |
Вариант 1: отключить XML-RPC через код
Если вы хотите быстро и прозрачно отключить XML-RPC, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Для продакшена mu-plugin надежнее: он не зависит от активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC, но не всегда отсекает запросы на уровне веб-сервера. Для большинства сайтов этого достаточно, если задача — убрать функциональность без сложной инфраструктуры.
Вариант 2: заблокировать xmlrpc.php на сервере
Если вы хотите снизить нагрузку и не отдавать WordPress лишнюю работу, блокируйте endpoint на сервере. Для Nginx это можно сделать через отдельное правило в конфиге сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess или в конфиге виртуального хоста:
<Files xmlrpc.php>
Require all denied
</Files>Серверный вариант полезен, если сайт регулярно получает мусорный трафик по этому адресу. Но если у вас есть легитимные интеграции, сначала убедитесь, что они не используют XML-RPC.
Вариант 3: отключить через плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, есть ли у него отдельная настройка для XML-RPC. Это удобно, когда нужно быстро включать и выключать доступ без правки кода. Но не стоит ставить отдельный плагин только ради одной галочки, если задача решается двумя строками кода.
Как не сломать Jetpack и внешние сервисы
Самая частая ошибка — отключить XML-RPC, а потом искать причину, почему перестала работать синхронизация. Jetpack исторически использует XML-RPC для части функций, хотя набор зависимостей у него меняется. Поэтому перед отключением проверьте, какие модули активны: статистика, публикация, удаленное управление, мобильные сценарии.
Если вам нужен только один сервис, а остальные функции Jetpack не используются, иногда проще отключить лишние модули Jetpack, чем полностью держать XML-RPC открытым. Но это уже зависит от конкретной конфигурации сайта.
Проверка результата после внедрения
После отключения проверьте не только сам endpoint, но и реальные сценарии. Это важнее, чем просто увидеть код ответа 403 или 404.
- Откройте
/xmlrpc.phpв браузере или через curl. - Проверьте логи веб-сервера: запросы должны либо блокироваться, либо не доходить до WordPress.
- Если есть Jetpack или внешние клиенты, выполните тестовую синхронизацию.
- Убедитесь, что публикация записей из админки работает как раньше.
Если вы отключили XML-RPC через код, а endpoint все еще отвечает, значит правило не подхватилось: проверьте, что файл действительно загружается, и нет ли кеширования на уровне сервера или CDN.
Что считать нормальным результатом
- запросы к
xmlrpc.phpполучают отказ доступа или не обрабатываются WordPress; - в логах нет регулярных успешных обращений к XML-RPC от неизвестных IP;
- сайт не теряет нужные интеграции;
- админка и REST API работают без изменений.
Частые ошибки и как их исправить
Ошибка 1: отключили XML-RPC, не проверив Jetpack. В результате перестают работать функции, которые завязаны на удаленное соединение. Решение: временно верните доступ, проверьте зависимости и отключайте только после теста.
Ошибка 2: правят .htaccess, но сайт работает на Nginx. Правило просто не применяется. Решение: используйте конфиг Nginx или отключение через WordPress-код.
Ошибка 3: добавили код в активную тему. После смены темы защита исчезает. Решение: вынесите правило в mu-plugin или отдельный мини-плагин.
Ошибка 4: блокируют XML-RPC, но оставляют уязвимый доступ к админке. Это не замена нормальной защите входа, сложным паролям и ограничению попыток авторизации. Решение: отключение XML-RPC должно быть частью общей гигиены, а не единственной мерой.
Практические советы по безопасности и производительности
Если сайт получает много мусорных запросов, серверная блокировка обычно предпочтительнее: она экономит ресурсы до загрузки WordPress. Если же вы часто меняете интеграции и не хотите лезть в конфиги, удобнее держать отключение в mu-plugin и включать доступ точечно.
Для сайтов с жесткими требованиями к безопасности полезно дополнительно:
- ограничить доступ к
wp-login.phpпо IP, если это возможно; - включить двухфакторную аутентификацию для админов;
- проверить, не открыт ли REST API для лишних публичных сценариев;
- убрать неиспользуемые плагины и темы, чтобы уменьшить поверхность атаки.
Если вам нужно не только отключить XML-RPC, но и почистить сайт от лишних технических дублей, мусорных мета-тегов и других SEO-артефактов, имеет смысл смотреть на комплексную оптимизацию. В таких задачах часто используют Clearfy Pro, но только если его набор функций действительно совпадает с вашей конфигурацией и задачами сайта: https://wpshop.ru/plugins/clearfy?utm_source=wpdownload.ru&utm_medium=article&utm_campaign=otklyuchit-xml-rpc-v-wordpress
Когда лучше не отключать XML-RPC
Не стоит рубить доступ, если сайт активно использует внешние публикации, старые мобильные клиенты или интеграции, которые вы не можете быстро перевести на другой механизм. В таких случаях сначала выносите список зависимостей, потом тестируйте отключение на staging-окружении и только после этого переносите изменения на продакшен.
Если нужна быстрая проверка без риска, начните с серверного ограничения по IP для известных сервисов или с временного отключения на тестовой копии сайта. Это дешевле, чем потом разбирать, почему редакторы не могут публиковать материалы из привычного инструмента.