Как отключить XML-RPC в WordPress и проверить, что сайт не использует его запросы

Автор: Максим Попов | Опубликовано: 21.09.2026

XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам к xmlrpc.php, попыткам перебора паролей и странной нагрузке на сайт. Если вы не используете мобильное приложение WordPress, внешние публикации через старые клиенты или специфические интеграции, этот интерфейс обычно можно отключить без потерь.

Но делать это нужно не вслепую. Сначала стоит понять, кто именно обращается к xmlrpc.php, какие функции реально завязаны на XML-RPC и чем безопаснее закрыть доступ: кодом, настройкой сервера или через плагин.

Когда XML-RPC действительно мешает

Проблема обычно проявляется не в админке, а на уровне логов и безопасности. В access-логах появляются повторяющиеся POST-запросы к /xmlrpc.php, иногда с одинаковых IP и с большим числом неудачных попыток авторизации. На слабых хостингах это ещё и лишняя нагрузка: даже если запросы отклоняются, сервер всё равно их обрабатывает.

Есть и обратная ситуация: сайт работает нормально, но после отключения XML-RPC перестают синхронизироваться старые мобильные клиенты, внешние редакторы или сервисы автопостинга. Поэтому сначала проверьте, используется ли интерфейс вообще.

Что проверить до изменений

есть ли в логах регулярные обращения к xmlrpc.php;
используете ли вы мобильное приложение WordPress;
подключены ли внешние сервисы публикации или мониторинга, которые работают через XML-RPC;
нет ли у сайта старых интеграций, завязанных на pingback или trackback;
есть ли на сервере WAF или модуль защиты, который уже режет такие запросы.

Диагностика: как понять, кто стучится в xmlrpc.php

Самый надёжный способ — посмотреть access-лог веб-сервера. Если у вас Nginx или Apache, ищите строки с xmlrpc.php. Обычно этого достаточно, чтобы увидеть частоту запросов, IP-адреса и коды ответа.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если доступ к логам есть только через панель хостинга, ищите фильтр по пути xmlrpc.php или по статусу ответа. Важно не просто увидеть факт обращений, а понять, это единичная интеграция или постоянный шум.

Дополнительно можно проверить, не используется ли XML-RPC косвенно. Например, если у вас есть старый клиент для публикации записей, приложение для телефона или сервис, который отправляет контент на сайт, отключение интерфейса сломает именно этот сценарий.

Как отключить XML-RPC: рабочие варианты

Есть три практических подхода: отключить через код, закрыть на уровне сервера или использовать плагин безопасности. Выбор зависит от того, есть ли у вас доступ к конфигам и насколько часто вы меняете окружение.

Способ	Когда подходит	Плюс	Минус
Код в теме или mu-plugin	Есть доступ к файлам сайта	Прозрачно и быстро	Нужно не забыть при смене темы
Правило на сервере	Есть доступ к Nginx/Apache	Режет запросы раньше WordPress	Нужны права на конфиг
Плагин безопасности	Нужна настройка без кода	Удобно для админов	Добавляет зависимость от плагина

Вариант 1: отключить XML-RPC через код

Если нужен простой и понятный способ, добавьте фильтр в functions.php дочерней темы или лучше в mu-plugin. Так настройка не пропадёт при обновлении темы.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант отключает сам XML-RPC на уровне WordPress. Если кто-то обратится к xmlrpc.php, сайт вернёт отказ в обработке. Для большинства сайтов этого достаточно.

Вариант 2: закрыть xmlrpc.php на сервере

Если вы хотите отсечь запросы ещё до загрузки WordPress, можно ограничить доступ на уровне веб-сервера. Для Nginx это обычно делается отдельным location-блоком.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache логика похожая, но синтаксис будет другой. Смысл один: запросы к файлу не доходят до PHP и не расходуют ресурсы WordPress.

Вариант 3: отключить только опасные части

Иногда XML-RPC нужен частично, например для конкретной интеграции. Тогда можно не выключать его полностью, а ограничить отдельные методы. Это уже более тонкая настройка и требует понимания, какие именно вызовы используются. Если точного списка нет, безопаснее не усложнять и закрыть интерфейс целиком.

Пошаговое решение без лишнего риска

Сделайте резервную копию файлов и базы, если планируете менять код или конфиг сервера.
Проверьте логи на наличие обращений к xmlrpc.php.
Убедитесь, что сайт не использует мобильное приложение WordPress и внешние клиенты публикации.
Отключите XML-RPC через код или серверное правило.
Очистите кэш, если на сайте есть page cache или reverse proxy.
Проверьте, что сайт продолжает нормально работать в админке и на фронтенде.

Как проверить, что решение сработало

Проверка должна быть не формальной, а прикладной. Откройте https://ваш-домен/xmlrpc.php в браузере или отправьте тестовый запрос. Если доступ закрыт, вы увидите отказ в доступе или пустой ответ в зависимости от способа блокировки.

Ещё лучше проверить через командную строку:

curl -I https://example.com/xmlrpc.php

Если вы закрывали файл на сервере, запрос должен возвращать отказ, а не обычный ответ WordPress. Если отключали через фильтр, WordPress не должен принимать XML-RPC-вызовы, даже если сам файл доступен по URL.

После этого снова посмотрите access-лог и убедитесь, что обращения либо исчезли, либо больше не доходят до PHP. Это особенно важно, если вы боролись не только с безопасностью, но и с нагрузкой.

Частые ошибки и как их исправить

Отключили XML-RPC, а интеграция перестала работать

Значит, интерфейс был нужен. Верните доступ и проверьте, какой именно сервис использует XML-RPC. Иногда проблему можно решить переходом на REST API, но это уже зависит от конкретной интеграции.

Добавили код в родительскую тему

После обновления темы настройка исчезнет. Для таких правок используйте дочернюю тему или mu-plugin. Это надёжнее и не требует помнить о каждом обновлении.

Закрыли файл на сервере, но запросы всё равно видны

Проверьте, не отдаёт ли сайт ответ из кэша или через другой слой защиты. Иногда в логах остаются старые записи, а реальная обработка уже заблокирована. Смотрите не только на факт обращения, но и на код ответа.

Сломали пингбеки и старые уведомления

Это ожидаемо: pingback и trackback исторически связаны с XML-RPC. Если вы их не используете, ничего делать не нужно. Если используете, придётся либо оставить интерфейс включённым, либо перенастроить процесс обмена ссылками.

Что ещё стоит отключить вместе с XML-RPC

Если цель — уменьшить поверхность атаки, одного XML-RPC мало. На практике часто отключают ещё и pingback, а также проверяют, не открыт ли лишний доступ к авторизации и REST-эндпоинтам для анонимных запросов. Но здесь важно не перегнуть: не стоит закрывать всё подряд без понимания, как сайт реально работает.

Для сайтов, где безопасность и чистка техдолга важнее экспериментов, удобно держать под рукой набор настроек вроде Clearfy Pro: он помогает убирать лишние функции WordPress и не собирать такие правки вручную по разным файлам. Но даже с плагином логику отключения лучше понимать самому — тогда проще отследить, что именно изменилось.

Практический чек-лист после внедрения

в логах больше нет успешных обращений к xmlrpc.php;
админка WordPress открывается без ошибок;
публикация записей из обычного редактора работает;
внешние сервисы, если они есть, протестированы отдельно;
кэш очищен, а CDN не отдаёт старую версию ответа;
правило отключения сохранено в месте, которое не потеряется после обновления.

Если у сайта нет явной зависимости от XML-RPC, отключение обычно даёт более чистую и предсказуемую конфигурацию. Главное — не ограничиваться одним кликом в плагине, а проверить, что именно перестало работать и почему.