Если на сайте идут лишние запросы к xmlrpc.php, чаще всего проблема не в самом WordPress, а в конкретной функции: pingback, внешних публикациях, мобильных клиентах или старых интеграциях. Полностью рубить XML-RPC вслепую — плохая идея. Сначала нужно понять, что именно используется, а уже потом отключать только лишнее.
Когда XML-RPC действительно стоит ограничить
На практике XML-RPC отключают не ради “чистоты”, а чтобы убрать лишнюю поверхность атаки и шум в логах. Если сайт не использует внешние клиенты, старые приложения и pingback, то оставлять этот канал открытым смысла мало. Но если у вас подключён Jetpack, мобильное приложение WordPress или сторонний сервис публикации, полная блокировка может сломать часть сценариев.
Что обычно ломается первым
- публикация через внешние приложения и десктоп-клиенты;
- Jetpack и связанные с ним функции, если они завязаны на XML-RPC;
- удалённые запросы для редактирования записей;
- pingback и trackback, если сайт ещё их принимает;
- мониторинг, который ошибочно считает
xmlrpc.php“подозрительным” и начинает блокировать легитимные запросы.
Диагностика: что именно использует xmlrpc.php
Перед изменениями посмотрите логи веб-сервера и события безопасности. Если видите много запросов с методом pingback.ping или массовые обращения к xmlrpc.php с одинаковыми паттернами, это уже повод ограничить функциональность. Если же в логах есть запросы от известных сервисов или от ваших собственных устройств, сначала проверьте, можно ли заменить их на REST API или штатный вход в админку.
Быстрая проверка вручную: откройте /xmlrpc.php в браузере. Нормальный ответ WordPress обычно не выглядит как обычная страница сайта. Это не тест безопасности, а только подтверждение, что файл доступен. Для реальной диагностики лучше смотреть логи и список подключённых интеграций.
Как отключить только pingback, а не весь XML-RPC
Если задача — убрать именно pingback, достаточно отключить соответствующий метод. Это безопаснее, чем блокировать весь файл на сервере. Такой подход часто подходит для сайтов, где внешние публикации не нужны, но остаются старые интеграции.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Код можно добавить в functions.php дочерней темы или в собственный мини-плагин. Если у вас уже есть mu-plugin для технических правок, это даже лучше: настройка не потеряется при смене темы.
Что даёт этот вариант
- pingback перестаёт принимать входящие запросы;
- снижается шум от автоматических обращений;
- меньше риск словить мусорные уведомления и лишнюю нагрузку;
- остальные XML-RPC методы остаются доступны, если они нужны.
Как полностью отключить XML-RPC через код
Если вы точно знаете, что XML-RPC нигде не используется, можно отключить его целиком. В WordPress для этого есть фильтр xmlrpc_enabled.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой и предсказуемый способ на уровне WordPress. Он не зависит от конкретного плагина безопасности и не требует правок в конфигурации сервера. Но важно понимать: если какой-то сервис всё же обращается к XML-RPC, он перестанет работать сразу.
Блокировка на уровне сервера: когда она уместна
Если сайт регулярно получает брутфорс или массовые запросы к xmlrpc.php, имеет смысл добавить блокировку на уровне nginx или Apache. Это снижает нагрузку ещё до загрузки WordPress. Но здесь есть нюанс: серверная блокировка не различает “плохие” и “хорошие” запросы, поэтому применять её стоит только после проверки зависимостей.
Пример для nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста. Но если сайт работает на общем хостинге, не всегда есть доступ к серверным настройкам. В этом случае проще и безопаснее использовать фильтр WordPress.
| Подход | Что отключает | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | Весь XML-RPC | Просто, прозрачно, без правок сервера | Ломает все интеграции, завязанные на XML-RPC |
Удаление методов через xmlrpc_methods | Только выбранные методы | Можно оставить нужные функции | Нужно понимать, какие методы используются |
| Блокировка на сервере | Доступ к xmlrpc.php | Снимает нагрузку до WordPress | Не подходит, если есть легитимные клиенты |
Проверка результата после внедрения
После изменения не ограничивайтесь “страница открывается/не открывается”. Проверьте несколько вещей:
- в логах больше нет запросов с
pingback.ping; - если отключали весь XML-RPC, внешние клиенты действительно перестали подключаться;
- Jetpack и другие интеграции не начали сыпать ошибками;
- в админке нет новых уведомлений о неудачных соединениях;
- нагрузка на сайт не выросла из-за повторных попыток авторизации.
Если у вас есть доступ к WP-CLI, можно быстро проверить, что WordPress жив и отвечает штатно, но сам XML-RPC этим не тестируется напрямую. Тут важнее именно логи веб-сервера и поведение внешних сервисов после изменения.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина обычно в том, что Jetpack ещё использует XML-RPC для части сценариев на конкретной установке. Решение простое: либо вернуть XML-RPC, либо перейти на другой способ подключения, если он поддерживается в вашей конфигурации. Перед блокировкой всегда проверяйте список активных интеграций.
Поставили плагин безопасности и забыли, что он уже блокирует xmlrpc.php
В итоге вы получаете двойную блокировку и путаницу в диагностике. Сначала отключите лишние правила в одном месте, потом тестируйте. Иначе непонятно, что именно ломает запросы: плагин, сервер или ваш код.
Закрыли файл на сервере, но забыли про старые мобильные клиенты
Это частая история на сайтах, где админка используется с телефона или через внешний редактор. Если такие сценарии есть, лучше не рубить всё целиком, а отключить только pingback и проверить реальные точки входа.
Практика безопасности и производительности
Если цель — не “выключить всё”, а снизить риск, разумнее идти поэтапно: сначала убрать pingback, потом посмотреть логи, и только после этого принимать решение о полной блокировке. Такой подход помогает не сломать рабочие интеграции и не создавать себе лишнюю поддержку.
Для сайтов с высокой посещаемостью полезно дополнительно ограничить частые обращения к xmlrpc.php на уровне WAF или сервера. Но не стоит полагаться только на плагин безопасности: если он выключится или обновится с изменением логики, защита исчезнет. Код в теме или mu-plugin обычно предсказуемее для точечной настройки.
Если вам нужно не только убрать XML-RPC, но и почистить сайт от других технических дублей и лишних запросов, иногда удобнее собрать это в один набор настроек. Например, в Clearfy Pro есть отдельные инструменты для технической оптимизации и отключения части лишнего функционала: https://wpshop.ru/plugins/clearfy.
Что проверить после обновлений WordPress и плагинов
Даже если сегодня всё работает, после обновления ядра, темы или плагина безопасности стоит повторно проверить:
- не вернулся ли доступ к
xmlrpc.phpиз-за новых правил; - не появились ли ошибки в логах внешних сервисов;
- не изменился ли список методов, если вы отключали только pingback;
- не конфликтует ли ваш код с другим фильтром на
xmlrpc_methods.
Если у вас несколько технических правок в одном месте, лучше хранить их отдельно и комментировать, зачем каждая нужна. Через полгода это экономит время сильнее, чем любая “универсальная” инструкция.