XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации, интеграции с сервисами автопостинга или старые клиенты для блога. Проблема в том, что это не просто один файл, а точка входа для нескольких сценариев обмена данными. Поэтому правильный подход здесь не «вырубить всё», а сначала понять, используется ли endpoint вообще, и только потом отключать его полностью или ограничивать точечно.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удалённую публикацию, Pingback и сторонние клиенты, XML-RPC обычно не нужен. На практике его оставляют включённым по привычке, а потом получают лишнюю поверхность атаки и шум в логах. Особенно это заметно на сайтах, где уже настроен REST API и весь контент редактируется из админки или через современные интеграции.
Но есть важная оговорка: если вы используете мобильное приложение WordPress, старые десктопные клиенты, внешние CMS-агрегаторы или сервисы, которые публикуют записи через XML-RPC, полное отключение сломает эти сценарии. Поэтому сначала нужна диагностика.
Диагностика: используется ли XML-RPC на вашем сайте
Проверка начинается с простого запроса к /xmlrpc.php. Если endpoint отвечает, это ещё не значит, что он реально нужен, но уже понятно, что он доступен извне.
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 200, 405 или даже 403, это не всегда говорит о фактическом использовании. Дальше смотрим логи веб-сервера и логи безопасности, если они есть. Ищите обращения к xmlrpc.php, а также методы вроде system.multicall и pingback.ping.
Полезно проверить и сам WordPress на наличие внешних клиентов:
- есть ли мобильное приложение WordPress у редакторов;
- используются ли сервисы автопостинга;
- есть ли интеграции с IFTTT-подобными сценариями или внешними CMS;
- нужны ли pingback и trackback на старых проектах;
- есть ли плагины, которые явно пишут в документации про XML-RPC.
Быстрый тест без риска
Если сомневаетесь, не отключайте endpoint сразу. Сначала временно ограничьте доступ по IP или включите блокировку только для самых опасных методов. Это позволит увидеть, ломается ли что-то в реальном использовании, а не по догадке.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее управлять правилом: в коде темы, в mu-plugin или на уровне веб-сервера. Для большинства сайтов самый предсказуемый вариант — небольшой mu-plugin. Он не зависит от темы и не потеряется при обновлении.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в mu-plugin | Нужно отключить XML-RPC стабильно и без привязки к теме | Нужно иметь доступ к файлам сайта |
| Правило в веб-сервере | Есть доступ к nginx/apache и нужен быстрый отказ на уровне сервера | Сложнее сопровождать, если конфигурация меняется |
| Плагин безопасности | Нужна быстрая настройка без кода | Лишняя зависимость от плагина и его интерфейса |
Вариант 1: отключить XML-RPC через mu-plugin
Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, её нужно создать вручную. Такой файл WordPress подхватывает автоматически.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам XML-RPC endpoint на уровне WordPress. Если какой-то внешний сервис продолжит стучаться в xmlrpc.php, он не получит рабочий ответ для публикации или авторизации.
Вариант 2: заблокировать файл на уровне nginx
Если у вас nginx, можно отдать 403 ещё до загрузки WordPress. Это полезно, когда сайт получает много мусорных запросов и вы хотите убрать их раньше, чем они дойдут до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache логика будет другой, но смысл тот же: закрыть прямой доступ к файлу. Этот вариант хорош для производительности, но его нужно применять аккуратно, если вы не уверены, что XML-RPC нигде не используется.
Вариант 3: отключить только опасные методы
Иногда полный запрет не нужен. Например, вы хотите оставить удалённую публикацию, но убрать pingback, который часто используют для спама и лишней нагрузки. Тогда можно фильтровать методы XML-RPC.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Такой подход полезен для старых проектов, где ещё живы внешние интеграции, но pingback уже не нужен. Это компромисс между безопасностью и совместимостью.
Проверка результата после внедрения
После изменения нужно проверить не только сам endpoint, но и реальные сценарии, которые могли зависеть от него. Иначе можно получить «тихую» поломку: сайт открывается, но публикация из внешнего сервиса больше не работает.
- Откройте
https://example.com/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт или endpoint ведёт себя ожидаемо. - Проверьте логи веб-сервера: обращения к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Если у вас есть мобильное приложение WordPress, попробуйте войти и создать тестовую запись.
- Если используются внешние сервисы публикации, отправьте тестовый пост.
- Проверьте, не появились ли ошибки в логах PHP или в журнале безопасности плагина.
Для более точной проверки можно отправить тестовый XML-RPC запрос. Если endpoint отключён корректно, ответ будет неуспешным, а не обычным рабочим ответом WordPress.
<?xml version="1.0"?>
<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>Этот запрос можно отправить любым HTTP-клиентом. Если вы видите отказ или пустой ответ от сервера, а не список методов WordPress, значит ограничение сработало.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про мобильное приложение
Это самая частая ситуация. Пользователь видит, что сайт «защищён», а редактор внезапно не может публиковать записи из приложения. Решение простое: либо вернуть XML-RPC, либо перевести процесс публикации на админку и REST API.
Поставили плагин безопасности, но правило дублируется
Иногда XML-RPC отключают и плагином, и серверным правилом одновременно. В результате сложно понять, что именно ломает интеграцию. Лучше оставить один источник правды: либо mu-plugin, либо веб-сервер, либо один конкретный security-плагин.
Заблокировали файл, но не проверили логи
Если после блокировки резко выросло число 403/404 на xmlrpc.php, это может быть просто шум ботов. Но если рядом появились ошибки авторизации или публикации, значит кто-то из ваших сервисов всё ещё зависит от этого endpoint.
Отключили pingback, но не почистили старые ссылки
Pingback сам по себе не нужен большинству сайтов, но старые записи и внешние ссылки могут продолжать генерировать обращения. Это не критично, но создаёт лишний мусор в логах. Если задача именно в чистоте сайта, имеет смысл дополнительно проверить старые настройки обсуждений и отключить trackback/pingback в админке.
Что выбрать: код, сервер или плагин
Если нужен быстрый и понятный результат без лишней зависимости от интерфейса, лучше использовать mu-plugin. Если важна разгрузка PHP и у вас есть доступ к конфигурации nginx или Apache, блокировка на уровне сервера будет жёстче. Плагин безопасности удобен, когда нужно включить правило без правки файлов, но тогда вы зависите от его логики и обновлений.
Для сайтов, где XML-RPC не используется вообще, я бы начинал с mu-plugin или серверного правила. Для старых проектов с внешними интеграциями — с точечного отключения опасных методов и только после проверки логов.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не заменяет базовую защиту. Если сайт регулярно получает брутфорс по wp-login.php, стоит отдельно ограничить попытки входа, включить нормальный парольный режим и проверить, не открыт ли REST API для лишних публичных сценариев.
Если вы ведёте несколько сайтов, удобно держать такие правила в одном месте — через mu-plugin или через конфигурацию сервера в шаблоне. Так меньше шансов, что после обновления темы или переезда на другой хостинг правило случайно исчезнет.
Если вам нужно не только отключить XML-RPC, но и почистить сайт от лишних технических хвостов, имеет смысл посмотреть на инструменты вроде Clearfy Pro: он закрывает часть типовых задач по чистке и SEO-настройкам, но применять его стоит только после понимания, какие функции реально нужны проекту. Для этой задачи важнее не набор галочек, а контроль над тем, что именно отключается.
В итоге рабочая схема простая: сначала проверка зависимостей, потом точечное отключение, затем тест реального сценария публикации и только после этого — жёсткая блокировка, если она действительно не ломает сайт.