XML-RPC в WordPress часто отключают слишком грубо: вместе с pingback убирают и то, что ещё нужно для внешних подключений. На практике задача обычно не в полном запрете XML-RPC, а в том, чтобы убрать именно pingback и оставить рабочими нужные сценарии — если они у вас вообще используются.
Если на сайте идут ложные уведомления о входящих ссылках, в логах видны запросы к /xmlrpc.php, а в админке появляются подозрительные попытки авторизации, сначала проверьте, что именно вы хотите отключить: весь XML-RPC или только pingback. Для большинства сайтов достаточно убрать pingback и ограничить доступ к xmlrpc.php на уровне сервера или через фильтры WordPress.
Что именно ломается, если отключить XML-RPC целиком
Полное отключение XML-RPC может задеть внешние клиенты и сервисы, которые до сих пор используют этот протокол. Это не всегда критично, но решение нужно принимать после проверки реальных сценариев.
Когда XML-RPC ещё нужен
- подключение старых мобильных приложений WordPress;
- публикация через внешние редакторы и интеграции;
- некоторые сервисы автопостинга и синхронизации;
- редкие сценарии удалённого управления сайтом.
Если ничего из этого не используется, полный запрет допустим. Но если нужен только защитный эффект против pingback-спама и лишних запросов, лучше не рубить всё подряд.
Диагностика проблемы: как понять, что мешает именно pingback
Откройте логи веб-сервера или хотя бы статистику запросов и посмотрите, есть ли обращения к /xmlrpc.php. Если в ответах часто встречаются методы pingback.ping, system.multicall или массовые попытки авторизации, это типичный шум, который можно отсечь без удаления всего XML-RPC.
Ещё один признак — сайт получает уведомления о несуществующих ссылках или странные входящие пинги, хотя вы не публиковали материалы со ссылками на эти страницы. Это уже не функциональная необходимость, а лишняя поверхность атаки.
Пошаговое решение: отключаем pingback и оставляем остальное под контролем
Ниже два рабочих подхода: через код в теме или mu-plugin и через серверную блокировку. Для большинства проектов безопаснее начать с фильтра в WordPress, а не с жёсткого запрета на уровне nginx или Apache.
Вариант 1. Отключить pingback через фильтры WordPress
Добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Этот вариант отключает XML-RPC pingback, но не ломает сам файл xmlrpc.php для других методов.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );
add_filter( 'pings_open', '__return_false' );
add_filter( 'pre_option_default_ping_status', '__return_zero' );Первый фильтр убирает сами методы pingback. Второй и третий помогают не создавать новые пинги и не держать их открытыми по умолчанию для новых записей.
Вариант 2. Полностью отключить XML-RPC, если он не нужен
Если вы точно знаете, что внешние интеграции не используются, можно запретить весь XML-RPC. Делайте это только после проверки, потому что при полном запрете перестанут работать все методы, а не только pingback.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой вариант, но и самый грубый. Он подходит для сайтов, где вход через мобильные приложения и внешние сервисы не нужен вообще.
Вариант 3. Ограничить доступ на уровне сервера
Если у вас nginx или Apache, можно дополнительно закрыть xmlrpc.php по IP или полностью запретить доступ, если сайт не использует XML-RPC. Но серверное правило лучше применять только после проверки, что WordPress-интеграции не завязаны на этот файл.
Для nginx типовой вариант выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Это жёсткая мера. Она эффективна против массовых запросов, но не подходит, если вам нужен хотя бы один внешний клиент, который работает через XML-RPC.
Сравнение подходов: что выбрать на практике
| Подход | Что делает | Когда подходит | Компромисс |
|---|---|---|---|
Фильтр xmlrpc_methods | убирает pingback, оставляет другие методы | нужна точечная защита без поломки интеграций | не закрывает весь канал от атак на xmlrpc.php |
xmlrpc_enabled | отключает XML-RPC целиком | внешние подключения не используются | ломает все XML-RPC-сценарии |
| Правило nginx/Apache | блокирует запросы на сервере | сайт не использует XML-RPC вообще | самый жёсткий вариант, нужен контроль зависимостей |
Проверка результата после внедрения
После изменений не ограничивайтесь тем, что страница открывается. Проверьте именно поведение XML-RPC и pingback.
- Откройте
/xmlrpc.phpв браузере: при полном отключении должен быть отказ, а не обычный ответ WordPress. - Проверьте, что новые записи не создают pingback на внешние ссылки.
- Если используете внешний клиент или мобильное приложение, выполните тестовый вход и публикацию черновика.
- Посмотрите логи: количество обращений к
xmlrpc.phpдолжно снизиться, а ошибки авторизации не должны расти из-за ваших же сервисов.
Для более точной проверки можно отправить тестовый XML-RPC-запрос из внешнего клиента или через curl, если вы понимаете, какой ответ ожидаете. Но для большинства админов достаточно проверки доступа к файлу и теста реального сценария публикации.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать мобильный клиент
Причина простая: вы использовали xmlrpc_enabled или серверный deny, хотя нужен был только запрет pingback. Верните доступ и оставьте только фильтрацию методов pingback.
Поставили правило в .htaccess, но оно не сработало
Часто правило пишут не в тот блок или забывают, что сайт работает не на Apache. Если у вас nginx, .htaccess не поможет вообще. Проверьте стек сервера перед внесением правок.
Отключили пинги, но уведомления о ссылках всё равно приходят
Значит, отключён только один слой. Проверьте настройки обсуждения в WordPress, а также плагины, которые могут переопределять поведение комментариев и уведомлений.
После правок выросло число 403 в логах
Это нормально, если сайт атакуют по старым адресам. Но если 403 идут от ваших же сервисов, значит, вы заблокировали слишком много. Сверьте источники запросов по IP и User-Agent.
Практические советы по безопасности и производительности
Отключение pingback не заменяет базовую защиту. Если на сайте идут массовые запросы к xmlrpc.php, дополнительно проверьте лимиты на авторизацию, двухфакторную защиту для админов и наличие актуальных обновлений ядра, тем и плагинов.
Если вам нужен более широкий набор мер по чистке сайта от лишних функций, дублей и технического мусора, посмотрите Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, что именно он меняет, чтобы не отключить лишнее на живом проекте.
Для рабочих сайтов я бы рекомендовал такой порядок: сначала проверить реальные зависимости, затем убрать pingback через фильтр, потом уже решать, нужен ли полный запрет XML-RPC на сервере. Это снижает риск поломки интеграций и даёт понятный путь отката.