Если на сайте регулярно идут брутфорс-атаки, в логах много запросов к xmlrpc.php, а в панели безопасности снова всплывают предупреждения, первое желание — просто закрыть XML-RPC. Это рабочий шаг, но только если вы понимаете, что именно используете на сайте: Jetpack, мобильное приложение WordPress, внешние сервисы публикации и некоторые интеграции могут опираться на XML-RPC.
Отдельная история — pingback. Даже когда XML-RPC нужен не весь, а только часть сценариев, pingback часто оставляют включённым по привычке. На практике это лишняя поверхность атаки и шум в логах. Ниже — как отключать точечно, без гаданий и без поломки нужных функций.
Когда отключение XML-RPC действительно нужно
Сначала стоит понять, есть ли у вас реальная зависимость от этого механизма. XML-RPC нужен не всем. Если сайт редактируется только из админки, а публикация идёт вручную, чаще всего его можно отключить. Но если вы используете Jetpack для синхронизации, мобильное приложение WordPress, внешние клиенты публикации или старые интеграции, полное отключение может создать проблемы.
Типичные признаки, что XML-RPC можно убрать
- в логах много запросов к
/xmlrpc.phpс ошибками авторизации; - сайт не использует мобильное приложение WordPress;
- Jetpack не нужен или уже отключён;
- нет внешних сервисов, которые публикуют записи по XML-RPC;
- в панели безопасности есть отдельные предупреждения именно по XML-RPC brute force.
Когда лучше не рубить с плеча
- Jetpack подключён и используется для статистики, публикации или синхронизации;
- редакторы работают через мобильное приложение WordPress;
- есть интеграции со сторонними CMS, которые отправляют записи по XML-RPC;
- вы не уверены, кто именно обращается к
xmlrpc.php.
Диагностика: что именно использует сайт
Перед изменениями проверьте, есть ли обращения к XML-RPC не только от атакующих, но и от ваших сервисов. Самый простой способ — посмотреть логи веб-сервера или отчёты в панели хостинга. Ищите запросы к xmlrpc.php и сопоставляйте их с IP, временем и частотой.
Если у вас есть доступ к серверу, можно быстро проверить наличие файла и ответ сервера:
curl -I https://example.com/xmlrpc.phpНормальный ответ не означает, что XML-RPC нужен; он лишь показывает, что файл доступен. Для диагностики важнее понять, кто и зачем его вызывает. Если Jetpack подключён, откройте его настройки и проверьте, нет ли активных функций, завязанных на соединение с WordPress.com.
Что проверить до отключения
- используется ли Jetpack;
- работает ли мобильное приложение WordPress;
- есть ли сторонние сервисы автопостинга;
- есть ли в логах частые POST-запросы к
xmlrpc.php; - не стоит ли на сайте плагин, который прямо просит не отключать XML-RPC.
Как отключить XML-RPC и pingback через код
Самый предсказуемый вариант — добавить код в functions.php дочерней темы или в небольшой mu-plugin. Для боевого сайта mu-plugin надёжнее: он не зависит от темы и не исчезнет после обновления.
Если нужно отключить XML-RPC полностью, используйте фильтр xmlrpc_enabled:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если задача — убрать только pingback, но не ломать остальное, отключите соответствующие заголовки и методы. На практике чаще всего достаточно убрать pingback из генератора и из HTTP-заголовков:
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
} );
add_filter( 'wp_headers', function ( $headers ) {
unset( $headers['X-Pingback'] );
return $headers;
} );
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );Если вам нужен более жёсткий вариант, можно заблокировать сам файл xmlrpc.php на уровне веб-сервера. Но это уже серверная настройка, и она может быть избыточной, если достаточно отключить XML-RPC через WordPress.
Что выбрать: плагин, код или сервер
| Подход | Плюсы | Минусы | Когда уместен |
|---|---|---|---|
| Код в mu-plugin | Контроль, минимум зависимостей | Нужно аккуратно тестировать | Если нужен точечный и прозрачный контроль |
| Плагин безопасности | Быстро включить, есть UI | Лишняя нагрузка и зависимость от интерфейса | Если админка уже ведётся через security-плагин |
| Блокировка на сервере | Жёстко и эффективно | Можно случайно сломать интеграции | Если XML-RPC точно не нужен вообще |
Пошаговое решение без сюрпризов
Если нужен безопасный порядок действий, не начинайте с тотальной блокировки. Сначала уберите pingback, потом проверьте зависимые функции, и только после этого отключайте XML-RPC полностью.
- Проверьте, использует ли сайт Jetpack или мобильное приложение WordPress.
- Посмотрите логи на обращения к
xmlrpc.php. - Отключите только pingback и лишние заголовки.
- Протестируйте публикацию, вход в админку и работу интеграций.
- Если зависимостей нет, отключите XML-RPC полностью.
Для сайтов, где нужен более широкий контроль над технической чисткой, иногда удобнее использовать набор настроек вроде Clearfy Pro: он помогает убирать лишние элементы и закрывать типовые технические хвосты без ручного редактирования темы. Но даже в этом случае проверка зависимостей остаётся обязательной.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужны конкретные признаки, что XML-RPC действительно отключён или урезан так, как вы планировали.
- при открытии
/xmlrpc.phpсервер больше не отдаёт рабочий XML-RPC-ответ; - в логах снижается число запросов к этому файлу;
- Jetpack и мобильное приложение продолжают работать, если вы их оставили;
- пингбэки больше не появляются в комментариях и уведомлениях;
- в HTTP-ответе нет заголовка
X-Pingback, если вы его убирали.
Проверить заголовки можно так:
curl -I https://example.com/ | grep -i pingbackЕсли команда ничего не выводит, это хороший знак, но не финальная гарантия. Для полной уверенности откройте страницу записи, проверьте исходный код и убедитесь, что ссылки на RSD и pingback не присутствуют в <head>.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Это происходит, когда на сайте используется синхронизация или функции, которые завязаны на соединение с WordPress.com. Решение простое: не отключайте XML-RPC полностью, пока не проверили, какие модули Jetpack реально активны. Если Jetpack нужен, ищите более точечную настройку или оставляйте XML-RPC включённым.
Убрали pingback, но атаки не прекратились
Pingback — не единственный вектор. Если боты массово стучатся в xmlrpc.php, отключение pingback не остановит сам факт запросов. В этом случае нужен либо полный запрет XML-RPC, либо блокировка на уровне WAF, либо ограничение по IP и rate limiting.
Скрыли проблему плагином, но не поняли причину
Плагины безопасности иногда маскируют симптомы, но не помогают разобраться, кто и зачем обращается к файлу. Если сайт небольшой и управляется вами, лучше один раз посмотреть логи и принять решение осознанно. Иначе через месяц вы вернётесь к той же проблеме, только уже после обновления плагина.
Добавили код в тему, а после обновления он исчез
Это классическая ошибка. Для технических ограничений используйте дочернюю тему или mu-plugin. Если код лежит в основной теме, обновление может его перезаписать, и защита тихо пропадёт.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не универсальная защита, а только один слой. Если сайт регулярно атакуют, проверьте ещё несколько вещей: ограничение попыток входа, актуальные версии ядра и плагинов, двухфакторную аутентификацию для админов, а также наличие WAF на стороне хостинга или CDN.
С точки зрения производительности сам по себе XML-RPC не является тяжёлой частью сайта, если его никто не трогает. Проблема обычно в шуме от ботов и в лишних обработках запросов. Поэтому эффект от отключения чаще заметен не по скорости страницы, а по снижению мусорной нагрузки и логов.
Если вы ведёте несколько сайтов и часто делаете техническую чистку, удобно держать отдельный набор проверок: XML-RPC, pingback, лишние эмодзи, дубли архивов, canonical, индексация служебных страниц. Тогда изменения не превращаются в хаотичный набор правок, а проходят по одному чек-листу.