Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

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

Сначала проверьте, есть ли у вас хоть один сценарий, который зависит от XML-RPC. Это не абстрактный вопрос: если сайт обслуживает редакторов через внешние приложения, подключен к Jetpack или использует старую автоматизацию публикаций, отключение сломает рабочий процесс. Если же сайт обычный, а входы идут только через wp-admin, XML-RPC чаще всего не нужен.

Типичные признаки, что XML-RPC можно убрать

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

Когда отключать нельзя или нужно заменить сценарий

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

Диагностика: как понять, используется ли xmlrpc.php

Самый простой способ — посмотреть обращения к файлу в логах веб-сервера или в логах безопасности. Если у вас включен доступ к access.log, ищите запросы к /xmlrpc.php. Если таких запросов много и они идут с разных IP, это еще не означает полезную нагрузку: часто это просто перебор паролей или массовые сканеры.

Проверить наличие ответа можно и вручную. Откройте URL https://ваш-домен/xmlrpc.php. Нормальный ответ WordPress обычно содержит сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не доказательство использования, но подтверждение того, что endpoint доступен.

Если хотите проверить, не завязаны ли на XML-RPC плагины или внешние сервисы, посмотрите:

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

Как отключить XML-RPC: сравнение подходов

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

Пошаговое решение через mu-plugin

Если вы хотите отключить XML-RPC без зависимости от темы, лучше создать маленький mu-plugin. Он загружается раньше обычных плагинов и не исчезнет после смены темы. Это удобнее, чем вставлять код в functions.php.

Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте ее вручную.

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Отключает XML-RPC на уровне WordPress.
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Отключает XML-RPC на уровне WordPress.
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

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

Если нужен серверный вариант

На уровне веб-сервера можно заблокировать доступ к xmlrpc.php напрямую. Это полезно, если у вас много брутфорс-запросов и вы хотите отсечь их до загрузки WordPress. Но правила зависят от сервера, поэтому слепо копировать чужой конфиг не стоит.

Apache через .htaccess

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

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

Nginx

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

Этот вариант тоже рабочий, но его лучше применять только если вы уверены, что endpoint не нужен. Иначе вы отключите не только вредный трафик, но и полезные подключения.

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

После отключения XML-RPC не ограничивайтесь тем, что «сайт открылся». Нужна проверка именно целевого сценария.

• Откройте /xmlrpc.php в браузере или через curl и убедитесь, что доступ закрыт или ответ изменился ожидаемым образом.
• Проверьте вход в админку и публикацию записей из самой панели WordPress.
• Если используется Jetpack или внешняя интеграция, проверьте ее статус отдельно.
• Посмотрите логи сервера: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ.

Для быстрой проверки через консоль можно использовать:

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

Если вы блокировали файл на уровне сервера, ожидайте статус вроде 403. Если отключали только фильтром WordPress, поведение может отличаться в зависимости от конфигурации и кэша.

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

Отключили XML-RPC, а потом перестал работать Jetpack

Это самый частый сценарий. Решение простое: либо вернуть XML-RPC, либо проверить, можно ли перевести конкретную функцию Jetpack на другой механизм. Если сервис критичен, не блокируйте endpoint до теста на staging.

Вставили код в functions.php и забыли про тему

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

Поставили плагин, который блокирует вообще все XML-RPC-запросы, но не проверили интеграции

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

Сделали блокировку в .htaccess, но забыли про Nginx-прокси или CDN

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

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

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

• ограничение попыток входа;
• двухфакторная аутентификация для админов;
• актуальные версии ядра, тем и плагинов;
• отключение лишних REST-эндпоинтов только если вы точно знаете, что они не нужны;
• регулярная проверка логов на повторяющиеся запросы к /wp-login.php и /xmlrpc.php.

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

Мини-чек-лист перед отключением

• Проверил, используется ли Jetpack.
• Посмотрел логи на обращения к /xmlrpc.php.
• Уточнил у редакторов, не работают ли они через мобильное приложение WordPress.
• Проверил внешние сервисы автопостинга и публикации.
• Выбрал способ отключения с возможностью быстрого отката.
• После изменения протестировал вход, публикацию и интеграции.

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