Как отключить XML-RPC в WordPress без поломки сайта

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

Когда XML-RPC действительно стоит отключать

Отключение оправдано, если сайт не использует внешние клиенты WordPress, публикацию через сторонние сервисы и старые интеграции, завязанные на XML-RPC. Типичный сценарий — обычный корпоративный сайт, блог или лендинг, где этот endpoint только создаёт лишние запросы в логах и иногда участвует в брутфорсе по system.multicall.

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

Диагностика: кто обращается к xmlrpc.php

Перед изменениями посмотрите, есть ли реальные обращения к файлу. Это можно сделать по логам веб-сервера или через инструменты мониторинга. Если в логах много POST-запросов к /xmlrpc.php с разных IP, чаще всего это автоматические попытки подбора пароля или массовые проверки доступности.

Что искать в логах

• частые POST-запросы к /xmlrpc.php;
• ответы 200 или 403 на один и тот же путь;
• всплески запросов с одинаковым user-agent или без него;
• ошибки авторизации в связке с system.multicall.

Если доступа к логам нет, можно временно открыть страницу /xmlrpc.php в браузере. Сам по себе ответ WordPress ещё не означает проблему, но подтверждает, что endpoint доступен извне.

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

Выбор зависит от того, где вам удобнее управлять ограничением: в коде, на уровне плагина или на сервере. Для большинства сайтов достаточно одного способа. Дублировать все три сразу не нужно: это усложняет диагностику, если что-то перестанет работать.

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

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

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

Если нужно не просто отключить сам XML-RPC, а ещё и убрать pingback-заголовки, можно дополнить код:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
    if ( isset( $headers['X-Pingback'] ) ) {
        unset( $headers['X-Pingback'] );
    }
    return $headers;
} );

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

Вариант 2: отключить через плагин

Если не хочется трогать код, используйте плагин, который умеет отключать XML-RPC и связанные с ним функции. Важно не ставить случайный «security pack» ради одной галочки: лучше выбрать инструмент, где видно, что именно отключается, и можно быстро вернуть настройку назад.

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

Вариант 3: заблокировать доступ на сервере

Если у вас есть доступ к конфигурации Nginx или Apache, можно отрезать запросы ещё до загрузки WordPress. Это полезно на нагруженных сайтах, где лишние запросы к xmlrpc.php не должны доходить до PHP.

Для Nginx пример выглядит так:

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

Для Apache можно использовать правило в .htaccess:

<Files "xmlrpc.php">
    Require all denied
</Files>

Серверный способ хорош тем, что он не зависит от WordPress и срабатывает раньше. Но если сайт работает через нестандартный стек или прокси, сначала проверьте, как именно у вас обрабатываются правила доступа.

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

1. Проверьте, не используется ли XML-RPC внешними сервисами или мобильным приложением.
2. Выберите один способ блокировки: код, плагин или сервер.
3. Внесите изменение на тестовой копии сайта, если она есть.
4. Очистите кеш страницы и кеш сервера, если он используется.
5. Проверьте доступ к /xmlrpc.php и логи после изменения.

Если нужен минимальный и обратимый вариант, начните с фильтра xmlrpc_enabled. Если цель — ещё и сократить лишние запросы на уровне сервера, используйте блокировку в Nginx или Apache.

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

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

• при отключении через WordPress-фильтр часто виден стандартный ответ о том, что XML-RPC отключён;
• при серверной блокировке возможен 403 Forbidden;
• если правило не сработало, вы всё ещё увидите доступный endpoint или ответ WordPress.

Дополнительно проверьте логи веб-сервера: запросы к /xmlrpc.php должны либо исчезнуть, либо получать отказ до обработки PHP. Это особенно важно, если вы отключали XML-RPC из-за нагрузки или атак.

Что ещё стоит проверить после изменения

• работает ли вход в админку обычным способом;
• не сломалась ли публикация через сторонний сервис, если он был подключён;
• не появились ли новые ошибки в логах PHP;
• не остался ли старый кеш с доступной страницей.

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

Отключили XML-RPC, но endpoint всё ещё отвечает

Чаще всего причина в кеширующем слое или в том, что правило добавили не туда. Проверьте, что код лежит в активной теме, дочерней теме или mu-plugin, а не в файле, который не загружается. Если использовали серверное правило, убедитесь, что оно попало в нужный виртуальный хост.

Сломалась внешняя интеграция

Значит, XML-RPC действительно использовался. В этом случае не нужно возвращать всё обратно без разбора. Сначала выясните, какой сервис обращался к endpoint, и можно ли заменить его на REST API или другой способ интеграции.

Поставили несколько плагинов безопасности сразу

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

Заблокировали файл, но не убрали pingback

Если цель — уменьшить поверхность атаки, проверьте не только доступ к xmlrpc.php, но и наличие X-Pingback в заголовках. Иногда именно они выдают лишнюю информацию о сайте.

Практические советы по безопасности и производительности

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

• не отключайте XML-RPC вслепую, если сайт связан с внешними сервисами;
• предпочитайте mu-plugin, если хотите сохранить настройку между обновлениями темы;
• после блокировки проверьте кеш и логи, а не только страницу в браузере;
• не ставьте несколько плагинов, которые делают одно и то же;
• если задача комплексная, сначала составьте список лишних функций, а потом отключайте их по одной.

В реальной эксплуатации именно такой подход экономит время: сначала диагностика, потом одно точное изменение, потом проверка по логам и фактическому ответу сервера. Для WordPress это обычно надёжнее, чем «починить всё» одним тяжёлым плагином.