XML-RPC в WordPress часто отключают по одной причине: через него удобно брутфорсить сайт и дергать удалённые методы, если они вообще не нужны. Но на практике ломают не только атаки, а ещё Jetpack, старые мобильные клиенты и некоторые внешние сервисы. Поэтому задача не в том, чтобы «вырубить всё», а в том, чтобы сначала понять, кто реально ходит в /xmlrpc.php, и только потом резать доступ.
Когда XML-RPC трогать вообще не стоит
Если у вас подключён Jetpack, публикация через сторонний клиент, старый мобильный WordPress app или внешний сервис, который работает через XML-RPC, простое отключение даст побочный эффект сразу. В этом случае сначала проверьте, есть ли у вас реальные обращения к методу xmlrpc.php, а не ориентируйтесь только на советы из чек-листов по безопасности.
Если сайт обычный, без удалённой публикации и без интеграций, XML-RPC чаще всего не нужен. Но даже тогда лучше отключать его осознанно: через код, серверную конфигурацию или плагин, а не «на глаз».
Диагностика: кто использует xmlrpc.php
Самый практичный способ — посмотреть логи веб-сервера. Если доступа к логам нет, можно временно поставить правило на логирование запросов к xmlrpc.php или проверить активные интеграции в админке WordPress и в Jetpack.
Что искать в логах
- частые POST-запросы к
/xmlrpc.php; - методы вроде
system.multicall,wp.getUsersBlogs,metaWeblog.newPost; - повторяющиеся запросы с одних и тех же IP;
- ошибки авторизации после отключения или фильтрации.
Если в логах видны только сканеры и перебор паролей, отключение XML-RPC оправдано. Если есть легитимные вызовы от Jetpack или внешнего сервиса, сначала перенесите их на другой способ работы.
Пошаговое решение: как отключить XML-RPC безопасно
Ниже три рабочих варианта. Выбирайте по тому, где вам удобнее контролировать поведение: в коде темы или mu-plugin, на уровне сервера или через плагин.
| Способ | Плюсы | Минусы | Когда подходит |
|---|---|---|---|
Код в functions.php или mu-plugin | Прозрачно, легко откатить | Нужно не забыть при смене темы | Когда нужен точечный контроль |
| Правило на сервере | Быстро и жёстко | Можно случайно сломать интеграции | Когда XML-RPC точно не нужен |
| Плагин безопасности | Удобно для админов без кода | Лишняя зависимость от плагина | Когда нужен интерфейс и журналирование |
Вариант 1: отключить XML-RPC через код
Если хотите убрать доступ к XML-RPC на уровне WordPress, добавьте фильтр в functions.php дочерней темы или в mu-plugin. Для production лучше mu-plugin: он не зависит от активной темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый прямой способ. WordPress перестанет отвечать на XML-RPC-запросы, а попытки обратиться к /xmlrpc.php будут получать отказ.
Вариант 2: заблокировать файл на уровне сервера
Если вы уверены, что XML-RPC не нужен вообще, можно закрыть сам файл. Для Apache это обычно делают через .htaccess, для Nginx — через правило в конфиге. Ниже пример для Apache:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика другая: запросы к xmlrpc.php нужно отдать с кодом 403 до передачи в PHP-FPM. Конкретный блок зависит от вашей схемы конфигурации, поэтому вносите правку аккуратно и проверяйте, что остальные PHP-страницы работают как раньше.
Вариант 3: ограничить только опасные методы
Иногда полный запрет не нужен: например, вы хотите оставить отдельную интеграцию, но убрать массовые вызовы и брутфорс через system.multicall. Тогда можно фильтровать методы XML-RPC и отключать только то, что реально не используется.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['system.multicall'] );
unset( $methods['pingback.ping'] );
return $methods;
} );Этот вариант не равен полной защите, но он полезен, если вам нужно сохранить совместимость с частью внешних клиентов.
Как не сломать Jetpack и мобильное приложение
Jetpack исторически использует XML-RPC для части сценариев подключения и синхронизации. Если вы отключили XML-RPC и после этого Jetpack перестал связываться с сайтом, это не баг WordPress, а ожидаемое поведение. В таком случае у вас два пути: либо вернуть XML-RPC, либо отказаться от функциональности, которая на нём завязана.
С мобильным приложением WordPress ситуация похожая: если приложение работает через XML-RPC в вашем сценарии, отключение разорвёт публикацию и синхронизацию. Проверяйте это до внедрения на боевом сайте, а не после жалоб редакции.
Практический чек-лист перед отключением
- проверьте, подключён ли Jetpack и какие модули реально используются;
- посмотрите, публикуют ли редакторы через мобильное приложение WordPress;
- сверьте внешние сервисы: автопостинг, планировщики, CRM, интеграторы;
- сделайте резервную копию конфигурации и файла, куда вносите правку;
- проверьте, есть ли у вас доступ к логам сервера для отката диагностики.
Проверка результата после внедрения
После отключения не ограничивайтесь открытием главной страницы. Нужно проверить именно тот путь, который вы закрывали.
Что проверить вручную
- открывается ли
/xmlrpc.phpв браузере или через curl; - работает ли вход в админку и обычные страницы сайта;
- не потерял ли связь Jetpack, если он установлен;
- не сломалась ли публикация из мобильного приложения, если оно используется;
- нет ли новых ошибок в логах PHP и веб-сервера.
Простой тест через curl выглядит так:
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали доступ на уровне WordPress или сервера, в ответе не должно быть нормального рабочего XML-RPC-эндпоинта. В зависимости от способа блокировки это может быть 403, 404 или другой отказ, но не успешный ответ с доступным методом.
Частые ошибки и как их исправить
Отключили XML-RPC через плагин и забыли про кеш
Иногда админ видит старое поведение из-за кеша страницы или прокси. Очистите кеш плагина, серверный кеш и CDN, иначе проверка даст ложный результат.
Поставили блок в .htaccess, но сайт на Nginx
Это типичная ошибка при копировании советов без проверки стека. .htaccess на Nginx не работает, поэтому правило нужно переносить в конфиг сервера.
Отключили XML-RPC и потеряли интеграцию
Значит, перед изменением не был проведён аудит зависимостей. Откатите блокировку, найдите сервис, который обращается к XML-RPC, и замените способ интеграции либо настройте исключение.
Использовали слишком общий код в теме
Если фильтр добавлен в родительскую тему, он исчезнет после обновления или смены темы. Для таких правок лучше использовать mu-plugin или отдельный мини-плагин.
Безопасность и производительность: что ещё стоит сделать
Отключение XML-RPC уменьшает поверхность атаки, но не заменяет базовую защиту. Если у вас регулярно идут попытки перебора паролей, проверьте лимиты на вход, двухфакторную аутентификацию, актуальность ядра и плагинов. Для сайтов с высокой нагрузкой полезно дополнительно ограничить частые POST-запросы на уровне WAF или сервера.
Если вам нужен более широкий набор мер по чистке сайта, удалению дублей и технической оптимизации, иногда удобнее закрыть несколько проблем одним инструментом. Например, Clearfy Pro от WPShop можно использовать как вспомогательный набор для SEO- и технических настроек, но он не отменяет необходимости понимать, что именно вы отключаете и почему: Clearfy Pro.
Главная проверка здесь простая: после изменений сайт должен работать в штатных сценариях, а нежелательные обращения к xmlrpc.php — нет. Если это так, решение внедрено правильно.