XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации, старые интеграции или пингбеки. На живом сайте это не та настройка, которую стоит менять вслепую: сначала нужно понять, кто именно обращается к /xmlrpc.php, и только потом резать доступ.
Когда XML-RPC действительно мешает
Сам по себе XML-RPC не является уязвимостью, но он расширяет поверхность атаки. На практике его отключают в трех сценариях: сайт не использует внешние клиенты, в логах видны массовые запросы к xmlrpc.php, либо хостинг/фаервол уже блокирует часть ботов, а этот endpoint остается открытым. Если у вас нет Jetpack, мобильного приложения WordPress, внешнего планировщика публикаций или старых сервисов автопостинга, отключение обычно не ломает рабочий процесс.
Диагностика: кто вообще использует xmlrpc.php
Перед изменениями проверьте логи веб-сервера или access log в панели хостинга. Ищите запросы к /xmlrpc.php и смотрите user-agent, IP и частоту. Если запросы идут от вашего мобильного приложения, Jetpack или стороннего сервиса публикации, блокировать endpoint без замены нельзя.
Что проверить до отключения
- используете ли вы приложение WordPress на телефоне;
- подключен ли Jetpack или другой сервис, который синхронизируется через XML-RPC;
- есть ли внешние публикации через сторонние клиенты;
- не завязаны ли на XML-RPC старые интеграции, которые давно не трогали;
- не используется ли pingback/trackback в вашей теме или плагинах.
Если доступа к логам нет, можно временно поставить ограничение и посмотреть, не появятся ли ошибки в админке или в интеграциях. Но это лучше делать в окно низкой нагрузки и с возможностью быстро откатить настройку.
Как отключить XML-RPC безопасно
Есть три рабочих подхода: через плагин безопасности, через код в теме/му-плагине и через веб-сервер. Для большинства сайтов самый управляемый вариант — код в mu-plugin, потому что он не зависит от темы и не исчезнет после обновления.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро, без правки кода | Дополнительная зависимость, иногда избыточные функции |
| Код в mu-plugin | Контроль, не зависит от темы | Нужен доступ к файлам |
| Блокировка на сервере | Режет запросы раньше WordPress | Нужно аккуратно исключать нужные сервисы |
Вариант 1: отключить XML-RPC через mu-plugin
Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте ее вручную. Такой код отключит endpoint и уберет часть связанных функций:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
unset( $headers['X-Pingback'] );
return $headers;
} );
add_filter( 'pings_open', '__return_false', 20, 2 );Этот вариант подходит, если вы точно не используете XML-RPC. Он не ломает обычный вход в админку по wp-login.php и не влияет на REST API.
Вариант 2: заблокировать xmlrpc.php на уровне сервера
Если вам нужен более жесткий контроль, можно закрыть сам файл. Для Apache это обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило зависит от конфигурации, но логика та же: вернуть 403 на запросы к /xmlrpc.php. Этот способ хорош, когда атаки идут массово и вы хотите отсечь их до загрузки WordPress. Но если позже понадобится внешний сервис, правило придется снять или ослабить.
Вариант 3: отключить только pingback, а не весь XML-RPC
Иногда нужен компромисс: сам XML-RPC остается, но pingback и trackback вы не используете. Тогда можно убрать только заголовок X-Pingback и закрыть пинги. Это полезно для старых сайтов, где внешние клиенты еще живы, но обратные ссылки не нужны.
Пошаговое решение без сюрпризов
- Проверьте логи и список интеграций.
- Сделайте резервную копию файлов и базы.
- Выберите способ: mu-plugin, серверное правило или плагин.
- Внедрите изменение сначала на staging, если он есть.
- Проверьте вход в админку, публикацию записей и работу внешних сервисов.
- Только потом переносите изменение на боевой сайт.
Если у вас есть несколько администраторов, предупредите их заранее. Самая частая проблема после отключения XML-RPC — не техническая, а организационная: кто-то продолжает публиковать через старый клиент и получает непонятную ошибку.
Как проверить, что решение сработало
Проверка должна быть не «страница открывается», а именно по endpoint. Откройте https://ваш-домен.ru/xmlrpc.php. Если XML-RPC отключен корректно, вы увидите отказ в доступе, 403 или сообщение о том, что сервис недоступен. Если вместо этого отдается стандартный ответ WordPress, настройка не сработала.
Дополнительно проверьте:
- внешние сервисы публикации — создается ли запись;
- мобильное приложение WordPress — проходит ли авторизация;
- Jetpack — нет ли ошибок синхронизации;
- логи сервера — исчезли ли массовые запросы к
xmlrpc.php; - админка — не появились ли ошибки при сохранении записей или медиа.
Если вы блокировали endpoint на уровне сервера, в логах должен появиться стабильный 403. Если отключали через фильтр WordPress, запрос может доходить до PHP, но должен завершаться отказом.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про мобильное приложение
Если редакторы работают через приложение WordPress, оно перестанет подключаться. Решение простое: либо вернуть XML-RPC, либо перевести команду на веб-админку и подтвердить, что приложение больше не нужно.
Поставили плагин безопасности и не поняли, что именно он блокирует
Некоторые плагины отключают не только XML-RPC, но и другие функции, связанные с REST API или заголовками. Если после установки начались странные ошибки, отключите плагин, проверьте логи и перенесите блокировку в отдельный mu-plugin. Так проще понять причину сбоя.
Закрыли xmlrpc.php на сервере, но забыли про старую интеграцию
Старые сервисы автопостинга иногда продолжают работать тихо до первого сбоя. Если интеграция критична, не блокируйте endpoint до теста на staging. Иначе получите проблему уже в рабочее время.
Отключили XML-RPC, но не убрали pingback
Это не ошибка безопасности, а недоделка. Если цель была убрать лишние запросы и шум в логах, проверьте, что X-Pingback больше не отдается, а пинги выключены в настройках обсуждения и коде.
Что еще имеет смысл проверить по безопасности и производительности
Если вы уже трогаете XML-RPC, посмотрите на соседние точки входа. На практике полезно ограничить число попыток входа, обновить ядро и плагины, а также проверить, не открыт ли лишний функционал в теме. Для сайтов с большим количеством мусорных запросов часто достаточно комбинации: закрыть XML-RPC, настроить базовый лимит логинов и убрать ненужные пинги.
Если нужен более широкий технический аудит, иногда удобнее использовать инструменты чистки и SEO-оптимизации вроде Clearfy Pro: он не заменяет ручную проверку, но помогает убрать часть лишнего функционала и дублей, которые не нужны на обычном контентном сайте. Ставить его стоит только если вы понимаете, какие опции включаете, а не ради одной галочки.
Когда XML-RPC лучше не отключать
Не трогайте endpoint, если у вас есть живые внешние интеграции, редакторы работают из мобильного приложения, либо сайт использует сервисы, которые вы не готовы быстро перевести на другой способ доступа. В таких случаях безопаснее оставить XML-RPC включенным и закрывать проблему на уровне ограничений по IP, WAF или логики авторизации.
Если нужен быстрый ориентир: сначала найдите, кто обращается к xmlrpc.php, потом решите, можно ли заменить этот канал, и только после этого отключайте endpoint. На WordPress это почти всегда дешевле, чем потом искать, почему перестала публиковаться запись или пропали синхронизации.