Как отключить XML-RPC в WordPress без поломки приложения и плагинов

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

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

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

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

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

Быстрая диагностика

Посмотрите, есть ли обращения к xmlrpc.php в логах веб-сервера или в логах безопасности. Если у вас установлен Wordfence, iThemes Security или аналогичный плагин, там тоже можно увидеть попытки доступа. Еще один практический признак — жалобы редакторов на то, что не работает публикация из приложения или через внешний сервис.

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

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

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

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

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Если нужен более жесткий вариант, можно дополнительно вернуть 403 на сам файл xmlrpc.php. Но тут важно не переборщить: если у вас есть зависимые сервисы, они перестанут работать сразу.

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

Этот вариант лучше использовать только если вы точно понимаете, что XML-RPC нигде не нужен. На практике фильтра xmlrpc_enabled обычно достаточно.

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

Если сайт работает на nginx, можно отрезать запросы к xmlrpc.php еще до запуска WordPress. Это полезно для нагрузки и безопасности, потому что PHP вообще не будет обрабатывать такие запросы.

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

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить nginx. На shared-хостинге этот вариант обычно недоступен, поэтому там чаще используют код или плагин.

Вариант 3: через плагин безопасности

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

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

Пошаговое решение без риска для интеграций

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

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

Если нужен именно кодовый вариант, mu-plugin выглядит так:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Отключает XML-RPC без привязки к теме.
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

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

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

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

Что смотреть после внедрения

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

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

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

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

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

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

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

Сломалась публикация из мобильного приложения

Значит, у команды реально был зависимый сценарий. Верните доступ, если приложение критично, или переведите редакторов на обычную админку. Лучше заранее согласовать это с теми, кто публикует контент ежедневно.

Правило добавили в тему, а после обновления оно исчезло

Это типичная ошибка. Для системных ограничений используйте mu-plugin или серверную конфигурацию. Тема — плохое место для таких правил, потому что она меняется чаще, чем политика безопасности сайта.

Поставили security-плагин, но XML-RPC все равно отвечает

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

Что еще стоит закрыть вместе с XML-RPC

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

Практически полезный минимум: отключить XML-RPC, убедиться, что REST API нужен и работает, проверить актуальность плагинов и убрать то, что давно не используется. Это дает больше пользы, чем набор случайных «hardening»-настроек без понимания последствий.