Как отключить XML-RPC в WordPress и не потерять удалённое управление

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

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

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

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

• старые мобильные приложения WordPress;
• внешние сервисы автопубликации и кросспостинга;
• клиенты для удалённой публикации;
• некоторые интеграции, которые до сих пор ходят в xmlrpc.php вместо REST API.

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

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

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

Проверка по логам

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если запросы есть, обратите внимание на источник, частоту и статус ответа. Постоянные попытки с разных IP — это уже не интеграция, а перебор паролей или сканирование.

Проверка из внешней точки

Можно сделать простой запрос и посмотреть ответ сервера:

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

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

Что лучше: плагин, код или серверное правило

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

Если задача — именно отключить XML-RPC, а не «прикрыть» его частично, серверное правило или mu-plugin обычно надёжнее плагина.

Пошаговое решение через код

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

Вариант 1: полностью отключить XML-RPC

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

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

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

Если вы уверены, что XML-RPC не нужен вообще, можно закрыть файл на веб-сервере:

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

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

Если XML-RPC нужен частично

Иногда отключать всё нельзя: например, сайт получает публикации из внешней системы, но при этом вы хотите убрать pingback и лишние методы. В таком случае лучше не рубить доступ полностью, а ограничить поверхность атаки.

Один из вариантов — оставить XML-RPC включённым, но отключить pingback-методы. Для этого можно использовать фильтр xmlrpc_methods:

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

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

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

После отключения важно не ограничиться «ошибок в админке не видно». Проверьте именно то, что ломается первым.

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

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

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

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

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

Поставили плагин, но запросы всё равно проходят

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

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

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

Сломали сайт из-за правки темы

Не вносите такие изменения в functions.php активной темы, если есть риск её замены. Для технических ограничений лучше использовать mu-plugin.

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

Отключение XML-RPC полезно, если вы точно им не пользуетесь, но это не универсальная защита. Параллельно стоит проверить:

• ограничение попыток входа;
• актуальность ядра, тем и плагинов;
• наличие двухфакторной аутентификации для админов;
• логи 401/403 и частоту обращений к xmlrpc.php;
• не используется ли старый сервис, который можно перевести на REST API.

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

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

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

1. Запросите /xmlrpc.php через curl.
2. Посмотрите access log и убедитесь, что обращения либо блокируются, либо отсутствуют.
3. Проверьте внешние интеграции, которые могли использовать XML-RPC.
4. Убедитесь, что в админке нет ошибок публикации и синхронизации.

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