Как отключить XML-RPC в WordPress без поломки входа и отложенных задач

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

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

Когда XML-RPC можно отключать, а когда лучше не трогать

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

• используется Jetpack с функциями, завязанными на XML-RPC;
• есть мобильный клиент или сторонний редактор, который публикует записи через XML-RPC;
• настроен внешний сервис автопостинга или мониторинга, который обращается к xmlrpc.php;
• есть старый кастомный код, который вызывает system.multicall или wp.getPosts.

Если вы не уверены, сначала проверьте логи доступа и список интеграций. Отключать «вслепую» — плохая идея: ошибка проявляется не сразу, а в момент очередной публикации или синхронизации.

Диагностика: как понять, используется ли XML-RPC сейчас

Самый простой путь — посмотреть, есть ли обращения к /xmlrpc.php в веб-логах. На nginx это обычно access log, на Apache — аналогичный лог виртуального хоста. Ищите запросы не только от ботов, но и от реальных сервисов, которые вы узнаете по IP, user-agent или времени обращения.

Если доступа к логам нет, проверьте интеграции вручную:

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

Быстрая проверка с помощью запроса

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

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

Если сервер отвечает 200 OK и отдаёт XML-ответ, файл доступен. Это ещё не значит, что он используется, но значит, что поверхность атаки открыта.

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

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

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

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

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

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

Вариант 2: блокировка на уровне nginx

Если у вас nginx, можно запретить доступ к xmlrpc.php до передачи запроса в PHP. Это полезно, когда вы хотите снизить лишнюю нагрузку от сканеров и брутфорса.

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

После такой настройки WordPress даже не увидит запрос. Это хороший вариант для сайтов, где XML-RPC точно не нужен.

Вариант 3: блокировка в Apache

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

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

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

Пошаговое решение без сюрпризов

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

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

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

Проверка должна быть не только технической, но и функциональной. Сначала убедитесь, что сам endpoint закрыт, затем проверьте сценарии, которые могли зависеть от него.

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

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

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

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

Значит, сервис реально использовал XML-RPC. Решение простое: либо вернуть доступ, либо перевести интеграцию на другой способ. Если сервис поддерживает REST API WordPress, это обычно более современный путь.

Поставили плагин, но xmlrpc.php всё ещё отвечает

Некоторые плагины отключают только часть функций внутри WordPress, но не режут сам файл на уровне сервера. Для жёсткой блокировки добавьте правило в nginx или Apache.

Закрыли XML-RPC, но не проверили Jetpack

Jetpack не всегда ломается сразу, но отдельные функции могут перестать работать. Перед отключением проверьте, какие модули действительно используются на сайте.

Сделали правку в родительской теме

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

Безопасность и производительность: что ещё стоит учесть

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

Если вы чистите сайт и приводите техническую часть в порядок, имеет смысл параллельно проверить:

• не дублируются ли мета-теги и canonical;
• не открыты ли лишние REST-маршруты от старых плагинов;
• не висит ли на сайте устаревший код в functions.php;
• не создают ли плагины лишнюю нагрузку на админку и фронтенд.

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

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

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

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