XML-RPC в WordPress часто отключают вместе с pingback, потому что эти механизмы нередко используют для брутфорса, лишних запросов и мусорных уведомлений. Но если просто «рубить всё подряд», можно неожиданно задеть Jetpack, мобильные приложения, внешние публикации и некоторые интеграции. Поэтому задача здесь не в том, чтобы выключить XML-RPC любой ценой, а в том, чтобы понять, что именно вам нужно оставить, а что можно безопасно закрыть.
Когда XML-RPC и pingback действительно мешают
Проблема обычно проявляется не в одном месте. На сайте могут одновременно быть:
- запросы к
/xmlrpc.phpв логах с большим количеством попыток входа; - спамные pingback-уведомления в комментариях или модерации;
- лишняя нагрузка на сервер из-за повторяющихся обращений;
- подозрительная активность от ботов, которые проверяют доступность XML-RPC;
- ошибки в интеграциях, если XML-RPC уже используется каким-то сервисом.
Если вы видите в логах постоянные обращения к xmlrpc.php, это уже повод проверить, нужен ли он вообще. Но перед отключением стоит понять, кто его использует.
Что проверить до изменений
Сначала посмотрите, есть ли у сайта реальные зависимости:
- Jetpack подключен и используется ли его синхронизация;
- есть ли мобильное приложение WordPress, которым реально пользуются;
- настроены ли внешние сервисы публикации или мониторинга, которые ходят через XML-RPC;
- используются ли старые интеграции, которым нужен
xmlrpc.php.
Если ничего из этого не нужно, отключение обычно безопасно. Если что-то используется, лучше не блокировать XML-RPC целиком, а ограничить только опасные методы или закрыть доступ на уровне сервера после теста.
Как отключить XML-RPC в WordPress: рабочие варианты
Есть три практических подхода: через код, через сервер и через плагин. Для большинства сайтов достаточно кода в functions.php дочерней темы или в небольшом mu-plugin. Если нужен более жесткий контроль, можно добавить блокировку на уровне веб-сервера.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в WordPress | Просто откатить, не требует доступа к серверу | Запрос всё равно доходит до WordPress |
| .htaccess / nginx | Отсекает запрос раньше, экономит ресурсы | Нужен доступ к конфигу сервера |
| Плагин | Быстро включить без правки кода | Лишняя зависимость, не всегда нужен отдельный плагин |
Вариант 1. Отключить XML-RPC через код
Если задача — запретить XML-RPC полностью, добавьте фильтр в functions.php дочерней темы или в собственный мини-плагин:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой вариант. WordPress перестанет принимать XML-RPC-запросы, а при обращении к /xmlrpc.php пользователь увидит отказ.
Если вы хотите оставить XML-RPC включенным, но убрать только pingback, можно отключить соответствующие методы:
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Этот вариант полезен, когда XML-RPC нужен для конкретного сервиса, но pingback вам точно не требуется.
Вариант 2. Закрыть xmlrpc.php на сервере
Если у вас Apache и сайт работает через .htaccess, можно заблокировать доступ к файлу напрямую:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика похожая, но правило пишется в конфиге сервера:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверная блокировка полезна тем, что запросы не доходят до WordPress вообще. Это снижает лишнюю нагрузку и убирает шум в логах.
Вариант 3. Использовать плагин
Если вы не хотите править код, можно использовать плагин, который отключает XML-RPC или связанные с ним функции. Но здесь важно не ставить что попало ради одной галочки. Если на сайте уже есть плагин для безопасности или оптимизации, проверьте, нет ли там готовой опции отключения XML-RPC и pingback.
Если нужен более широкий набор технических настроек, иногда удобнее использовать комплексный инструмент вроде Clearfy Pro: в нем есть функции для чистки сайта и отключения лишних возможностей WordPress. Это не обязательный путь, но он удобен, когда вы параллельно убираете и другие технические хвосты. Посмотреть Clearfy Pro
Диагностика: как понять, что отключение сработало
После изменения не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что запросы реально блокируются, а нужные сервисы не сломались.
Проверка через браузер и curl
Откройте https://ваш-домен.ru/xmlrpc.php. Если XML-RPC отключен на уровне WordPress, вы увидите сообщение о том, что сервис недоступен, либо отказ в доступе. Если блокировка сделана на сервере, ответ может быть 403 Forbidden.
Для более точной проверки используйте curl:
curl -I https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки:
403— если доступ запрещен на сервере;- ответ WordPress с сообщением об отключении XML-RPC — если используется фильтр в коде;
200— значит, блокировка не сработала или была применена не там, где нужно.
Проверка логов
Посмотрите access log и убедитесь, что обращения к /xmlrpc.php либо исчезли, либо получают отказ. Если после блокировки бот продолжает долбить этот файл, это нормально: важно, чтобы сервер не тратил на такие запросы лишние ресурсы.
Если вы отключали только pingback, проверьте, что обычная работа сайта не изменилась, а в комментариях больше не появляются новые pingback-уведомления.
Чек-лист после внедрения
- Проверен список сервисов, которые могут использовать XML-RPC.
- Выбран способ блокировки: код, сервер или плагин.
- Проверен ответ
/xmlrpc.phpчерез браузер или curl. - Просмотрены логи веб-сервера после изменения.
- Тестированы внешние интеграции, если они есть.
- Убедились, что комментарии и публикации работают как раньше.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий, если Jetpack использовался для синхронизации или удаленного управления. Решение простое: либо вернуть XML-RPC, либо отключать только pingback, либо пересмотреть, нужен ли вообще Jetpack в текущей конфигурации.
Поставили плагин, но запросы к xmlrpc.php остались
Некоторые плагины только отключают функциональность внутри WordPress, но не блокируют сам URL на уровне сервера. В логах вы все равно будете видеть обращения. Если цель — снизить нагрузку и шум, добавьте серверное правило.
Сломали мобильное приложение WordPress
Если кто-то реально публикует через мобильное приложение, полное отключение XML-RPC может мешать. В таком случае сначала проверьте, можно ли перевести процесс на REST API или другой способ публикации.
Заблокировали не тот файл
Иногда в конфиге сервера пишут правило слишком широко и случайно задевают другие запросы. Блокируйте именно /xmlrpc.php, а не весь каталог или похожие URL.
Что делать, если нужен баланс между безопасностью и совместимостью
Если сайт живой и у него есть внешние сервисы, не обязательно отключать всё сразу. Практичнее идти по шагам:
- сначала убрать pingback;
- потом проверить, есть ли реальные обращения к XML-RPC;
- если зависимостей нет, закрыть
xmlrpc.phpполностью; - после этого еще раз проверить интеграции и логи.
Такой подход безопаснее, чем резкое отключение без диагностики. Для небольших проектов это обычно лучший баланс между защитой и совместимостью. Если на сайте уже накопилось много технического мусора, имеет смысл параллельно проверить и другие лишние функции WordPress, чтобы не оставлять открытыми старые точки входа.