XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack, публикация через внешние сервисы или интеграции, которые до сих пор используют этот старый интерфейс. Если задача именно в безопасности и снижении лишней поверхности атаки, отключать XML-RPC можно. Но делать это нужно после проверки зависимостей, а не вслепую.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его без лишних побочных эффектов и как проверить, что всё действительно сработало.
Когда XML-RPC стоит отключать, а когда лучше оставить
XML-RPC — это не «ошибка» WordPress, а старый способ удалённого доступа к сайту. Через него исторически работали публикация из внешних клиентов, часть мобильных приложений и некоторые сервисы синхронизации. Проблема в том, что в большинстве современных установок он не нужен, но при этом остаётся доступным и может использоваться для перебора паролей или лишних запросов к сайту.
Отключать XML-RPC имеет смысл, если:
- вы не используете Jetpack для функций, завязанных на XML-RPC;
- не публикуете записи из внешних клиентов и мобильных приложений WordPress;
- не подключали сторонние сервисы, которым нужен удалённый доступ к
xmlrpc.php; - вам важнее уменьшить поверхность атаки, чем сохранить устаревший канал интеграции.
Оставить XML-RPC лучше, если сайт реально использует старые интеграции. В этом случае безопаснее не ломать доступ, а ограничить конкретные риски: например, закрывать лишние методы на уровне плагина безопасности или веб-сервера, если это поддерживается вашей конфигурацией.
Диагностика: как понять, кто использует xmlrpc.php
Перед отключением проверьте, есть ли обращения к xmlrpc.php в логах веб-сервера. Это самый практичный способ понять, используется ли endpoint вообще. Если логов нет, проверьте хотя бы список активных плагинов и интеграций: Jetpack, мобильные клиенты, сервисы автопостинга, некоторые резервные копии и мониторинги могут завязываться на этот механизм.
Что искать в логах
В access.log обычно видны запросы к /xmlrpc.php. Если запросы идут регулярно, посмотрите IP-адреса и User-Agent. Важно отличать реальные интеграции от массового сканирования: боты часто стучатся в этот файл без остановки, но это не значит, что его можно отключить без последствий для ваших сервисов.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам может отличаться, но сама идея та же: сначала смотрим факты, потом меняем поведение сайта.
Быстрая проверка через браузер
Откройте https://ваш-домен.ru/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением вида XML-RPC server accepts POST requests only. Это не доказательство уязвимости, но подтверждение, что endpoint открыт. После отключения ответ должен измениться на 403, 404 или другой контролируемый отказ в зависимости от способа блокировки.
Как отключить XML-RPC: три рабочих подхода
Универсального варианта нет: выбор зависит от того, где вам удобнее контролировать доступ — в WordPress, на уровне плагина или на веб-сервере. Ниже — сравнение без лишней теории.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Код в functions.php или mu-plugin | Быстро, прозрачно, без лишних плагинов | Нужно не забыть про обновления темы; лучше использовать mu-plugin | Если нужен точечный контроль внутри WordPress |
| Плагин безопасности | Удобно для админов без кода | Добавляет зависимость и может дублировать функции | Если уже используете плагин с такой опцией |
| Блокировка на сервере | Режет запросы до загрузки WordPress | Нужно аккуратно настроить, чтобы не задеть нужные сервисы | Если хотите закрыть endpoint максимально рано |
Вариант 1: отключить XML-RPC через код
Самый предсказуемый способ — добавить фильтр xmlrpc_enabled. Для постоянного решения лучше использовать mu-plugin, а не functions.php активной темы: так настройка не пропадёт после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Сохраните файл как disable-xmlrpc.php в папке wp-content/mu-plugins/. Если папки mu-plugins нет, создайте её вручную. WordPress подхватит такой файл автоматически.
Если вы хотите не просто отключить XML-RPC, а ещё и убрать сам доступ к файлу на уровне WordPress, можно дополнительно повесить отказ на ранний хук:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
header( 'Content-Type: text/plain; charset=utf-8' );
echo 'XML-RPC disabled';
exit;
}
} );Этот вариант полезен, если вам нужен явный ответ 403. Но если задача только в отключении функции, первого фильтра обычно достаточно.
Вариант 2: закрыть xmlrpc.php на уровне Nginx или Apache
Если вы хотите отрезать запросы ещё до WordPress, блокируйте xmlrpc.php в конфигурации веб-сервера. Это особенно уместно на сайтах с высокой нагрузкой или при постоянных бот-атаках.
Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess или конфигурации виртуального хоста:
<Files "xmlrpc.php">
Require all denied
</Files>Этот способ хорош тем, что WordPress даже не стартует для такого запроса. Но если у вас есть интеграция, которой XML-RPC всё-таки нужен, она тоже перестанет работать.
Вариант 3: использовать плагин, если нужен интерфейс в админке
Если вы не хотите править код и у вас уже стоит плагин безопасности с соответствующей настройкой, отключение через интерфейс допустимо. Но не ставьте отдельный плагин только ради одной галочки, если ту же задачу можно решить кодом или серверным правилом. Лишний плагин — это ещё один слой обновлений и потенциальных конфликтов.
Пошаговое решение без лишних рисков
- Проверьте логи на обращения к
xmlrpc.php. - Убедитесь, что не используете Jetpack, мобильные приложения и внешние клиенты, завязанные на XML-RPC.
- Выберите способ отключения: mu-plugin, серверное правило или существующий плагин безопасности.
- Внесите изменение сначала на staging, если он есть.
- Проверьте ответ
/xmlrpc.phpи работу всех интеграций. - Только после этого переносите настройку на боевой сайт.
Если сайт обслуживает несколько редакторов, предупредите их заранее. Частая проблема — один человек отключил XML-RPC, а другой продолжает публиковать через старый клиент и получает «непонятную ошибку» без связи с изменением.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Нужны как минимум три уровня контроля: ответ endpoint, отсутствие ошибок в интеграциях и отсутствие лишних запросов в логах.
1. Проверка ответа сервера
Откройте /xmlrpc.php в браузере или через curl:
curl -I https://example.com/xmlrpc.phpПосле блокировки вы должны увидеть отказ в доступе или другой контролируемый ответ, а не стандартное сообщение WordPress о том, что XML-RPC принимает только POST-запросы.
2. Проверка интеграций
Если у вас подключён Jetpack или другой сервис, попробуйте выполнить типичную для него операцию: синхронизацию, публикацию, обновление статистики. Если что-то сломалось, значит XML-RPC был нужен и отключать его полностью нельзя.
3. Проверка логов
После изменения посмотрите access.log ещё раз. Если запросы к xmlrpc.php продолжают идти и получают 403, значит блокировка работает. Если запросов нет, но сервисы жалуются, ищите альтернативный канал, который использует интеграция.
Частые ошибки и как их исправить
- Отключили XML-RPC в теме. После смены темы настройка пропадает. Для постоянного решения используйте mu-plugin или серверное правило.
- Сразу заблокировали файл на сервере без проверки зависимостей. В результате перестал работать Jetpack или внешний клиент публикации. Сначала проверьте, кто обращается к endpoint.
- Поставили отдельный плагин, хотя уже есть функция в существующем. Это лишняя зависимость и потенциальный конфликт с другими средствами безопасности.
- Судили по одному тесту в браузере. Открытие
xmlrpc.phpв браузере не показывает, используются ли методы POST из интеграций. Проверяйте логи и реальные сценарии. - Отключили XML-RPC, но не проверили мобильные приложения редакторов. У WordPress до сих пор встречаются старые рабочие процессы, о которых вспоминают только после поломки.
Что сделать для безопасности и производительности дополнительно
Если цель — не просто убрать XML-RPC, а уменьшить лишнюю нагрузку и поверхность атаки, посмотрите на соседние настройки: ограничение попыток входа, двухфакторную аутентификацию для админов, актуальные версии ядра и плагинов, отключение ненужных REST-эндпоинтов только там, где это действительно оправдано. Но не смешивайте всё в одну правку: когда ломается сразу несколько механизмов, потом сложно понять причину.
Для сайтов, где важна техническая чистота и контроль над SEO- и системными настройками, удобно держать такие изменения в одном месте — через mu-plugins или через набор понятных правил на сервере. Если вам нужен более широкий набор инструментов для чистки сайта и отключения лишних функций, можно посмотреть в сторону Clearfy Pro, но только если его функции реально закрывают вашу задачу и не дублируют уже существующую конфигурацию.
Главный критерий здесь простой: после изменения сайт должен вести себя предсказуемо. Если XML-RPC не нужен — он должен быть закрыт, а если нужен хотя бы одному сервису — отключать его полностью не стоит, лучше ограничить доступ точечно.