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

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

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

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

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

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

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

Проверка через браузер и curl

Откройте https://example.com/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка, а признак того, что endpoint открыт.

Для более точной проверки используйте curl:

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

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

Что проверить в админке и интеграциях

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

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

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

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

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

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

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

Вариант 2: блокировка через .htaccess для Apache

Если сайт работает на Apache и вы хотите отрезать доступ раньше, чем WordPress начнёт обрабатывать запрос, можно добавить правило в .htaccess. Но делайте это только если понимаете, что endpoint не нужен ни одному сервису.

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

Это жёсткий вариант. Он хорош для сайтов, где XML-RPC точно не используется. Если у вас Nginx, аналогичное правило настраивается в конфиге сервера, а не в .htaccess.

Вариант 3: плагин для защиты и чистки

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

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

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

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

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

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

Проверка ответа сервера

Снова выполните запрос:

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

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

Проверка зависимостей

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

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

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

Отключили XML-RPC, не проверив Jetpack

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

Закрыли endpoint на сервере и забыли про тестовый домен

Частая ситуация: правило добавили на боевом сайте, а тестовый поддомен остался открытым. В результате боты продолжают стучаться в старую копию сайта, а вы считаете, что проблема решена. Проверяйте все домены и поддомены, где крутится WordPress.

Использовали плагин, который делает слишком много

Если вам нужен только один технический фикс, не стоит ставить тяжёлый комбайн без понимания, что ещё он меняет. Иногда такой плагин отключает и полезные вещи: REST API, эмодзи, oEmbed или мета-теги. Читайте список функций до установки, а не после.

Проверили только главную страницу

Главная может открываться идеально, даже если /xmlrpc.php всё ещё доступен. Проверяйте именно endpoint, а не только общий статус сайта.

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

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

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

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

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

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

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