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

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

Если задача именно в безопасности, то правильный подход — сначала понять, нужен ли вам xmlrpc.php вообще, а уже потом выбирать способ блокировки: на уровне WordPress, веб-сервера или через WAF. Ниже — рабочая схема без лишних рисков.

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

Файл xmlrpc.php нужен для удалённого взаимодействия со старым API WordPress. На практике его используют редко, но полностью списывать со счетов нельзя. Отключение оправдано, если вы не пользуетесь:

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

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

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

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

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

Быстрая проверка через HTTP-ответ

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

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

Ответ 200 или 405 сам по себе не проблема. Важнее понять, есть ли реальные запросы и ошибки в логах после отключения.

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

Пошаговое решение через код темы или mu-plugin

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

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

Лучше не вставлять это в активную тему, если сайт обслуживается командой или тема может меняться. Надёжнее создать маленький mu-plugin:

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

Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Такой вариант не зависит от темы и не слетит после обновления.

Если нужен жёсткий запрет на уровне Nginx

Когда нужно отсечь запросы ещё до загрузки WordPress, можно закрыть доступ к xmlrpc.php в конфиге сервера. Для Nginx это выглядит так:

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

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

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

После внедрения проверьте не только сам ответ файла, но и побочные эффекты. Нужна именно функциональная проверка, а не формальный статус.

• Откройте https://example.com/xmlrpc.php в браузере или через curl.
• Убедитесь, что WordPress не принимает XML-RPC-запросы.
• Проверьте мобильное приложение, если оно используется.
• Посмотрите логи на предмет ошибок у внешних сервисов.
• Проверьте, не выросло ли число 403/404 на этом URL после изменения.

Если вы отключали через фильтр, WordPress должен перестать обрабатывать XML-RPC-вызовы. Если блокировали на сервере, запросы должны отрезаться ещё до PHP.

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

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

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

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

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

Закрыли файл в Nginx, а в логах остались попытки авторизации

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

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

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

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

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

Что делать, если XML-RPC нужен частично

Иногда полностью отключать его нельзя, но и оставлять открытым без контроля тоже не хочется. Тогда практичнее не рубить с плеча, а ограничить поверхность атаки:

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

Такой подход особенно полезен на старых проектах, где отключение «в один клик» может привести к тихой поломке внешних публикаций. Сначала диагностика, потом блокировка, и только после этого — контроль результата.