XML-RPC в WordPress часто отключают по одной причине: он открывает лишнюю поверхность атаки и почти никогда не нужен на обычном сайте. Но если просто поставить запрет «в лоб», можно неожиданно сломать мобильное приложение, внешнюю публикацию через старый клиент или интеграцию, которая до сих пор ходит в /xmlrpc.php.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его безопасно, чем проверить результат и где чаще всего ошибаются.
Когда XML-RPC реально мешает
На практике проблема обычно выглядит так:
- в логах появляются регулярные запросы к
/xmlrpc.php; - хостинг фиксирует всплески POST-запросов на этот файл;
- сайт начинает отвечать медленнее из-за мусорного трафика;
- нужно закрыть лишнюю точку входа после аудита безопасности;
- вы точно не используете публикацию через старые внешние клиенты WordPress.
Если у вас есть интеграции с Jetpack, мобильным приложением WordPress или внешними сервисами, которые работают через XML-RPC, сначала проверьте их список. В современных установках чаще используется REST API, а не XML-RPC, но это не повод отключать протокол без проверки.
Диагностика: нужен ли XML-RPC именно вам
Самый простой способ — посмотреть, кто и как обращается к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, найдите запросы к этому файлу и оцените источник. Если запросы идут только от ботов и сканеров, отключение обычно безопасно. Если видите обращения от вашего приложения или сервиса — сначала проверьте, можно ли перевести его на REST API или другой способ авторизации.
Быстрая проверка через браузер и curl
Откройте https://example.com/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не признак проблемы, а просто подтверждение, что точка входа открыта.
Для более точной проверки используйте curl:
curl -i https://example.com/xmlrpc.phpЕсли после отключения вы видите 403 Forbidden или 404 Not Found, значит доступ закрыт на уровне сайта или сервера. Если ответ по-прежнему приходит от WordPress, запрет сработал не полностью.
Как отключить XML-RPC: сравнение подходов
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин безопасности | Быстро, без правки кода | Лишняя зависимость, иногда закрывает больше, чем нужно | Если нужен быстрый результат без разработки |
Код в functions.php или mu-plugin | Контроль, минимум лишнего | Нужно аккуратно обновлять тему или хранить код отдельно | Если вы ведёте сайт как проект и хотите предсказуемое поведение |
| Отключение на уровне сервера | Ранний запрет, меньше нагрузки | Зависит от конфигурации хостинга | Если есть доступ к nginx/apache и нужен жёсткий блок |
Если задача — именно убрать XML-RPC, а не ставить «комбайн» безопасности, чаще всего достаточно кода или правила на сервере.
Пошаговое решение через код
Самый предсказуемый вариант — отключить XML-RPC через фильтр xmlrpc_enabled. Это не выдуманный хук, он есть в WordPress и используется именно для этой задачи.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы, но на практике удобнее вынести его в небольшой mu-plugin, чтобы он не зависел от темы. Например, создайте файл wp-content/mu-plugins/disable-xmlrpc.php:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант проще сопровождать: код не потеряется при смене темы и не требует отдельной активации в админке.
Если нужен жёсткий запрет на уровне сервера
Иногда полезно закрыть файл ещё до загрузки WordPress. Для Apache можно использовать .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный запрет хорош тем, что не тратит ресурсы на загрузку WordPress. Но если вы не уверены в конфигурации хостинга, сначала проверьте это на тестовой среде.
Как не сломать интеграции
Перед отключением проверьте, не используется ли XML-RPC в одном из сценариев:
- старое мобильное приложение WordPress;
- публикация через внешние клиенты и десктопные редакторы;
- Jetpack и связанные с ним функции, если они завязаны на XML-RPC в вашей конфигурации;
- сторонние сервисы, которые подключались к сайту до перехода на REST API.
Если интеграция нужна, но вы хотите снизить риск атак, лучше ограничить доступ на уровне сервера по IP или перевести сервис на другой способ подключения. Полностью оставлять открытым xmlrpc.php только ради «на всякий случай» — плохая идея.
Проверка результата после внедрения
После отключения проверьте не только ответ на прямой запрос, но и реальные логи. Это важнее, чем просто увидеть ошибку в браузере.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Проверьте, что ответ стал
403или404, если вы закрывали файл на сервере. - Посмотрите access log: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Проверьте админку, публикацию записей и подключённые сервисы.
Если после отключения сайт начал вести себя странно, не ищите проблему в XML-RPC автоматически. Чаще всего причина в том, что вместе с ним отключили лишнее правило в .htaccess или добавили слишком широкий блок на уровне nginx.
Частые ошибки и как их исправить
Отключили не XML-RPC, а REST API
Это типичная путаница. XML-RPC — это /xmlrpc.php, а REST API работает через /wp-json/. Если после правок перестали работать мобильное приложение, Gutenberg-части или внешние интеграции, проверьте, не трогали ли вы правила для REST API.
Добавили код в родительскую тему
Если отключение прописано в functions.php родительской темы, оно может исчезнуть после обновления. Для постоянной настройки используйте дочернюю тему или mu-plugin.
Закрыли файл, но оставили доступным через кэш или CDN
Иногда CDN или промежуточный кэш продолжает отдавать старый ответ. После изменения правил очистите кэш сайта, серверный кэш и CDN, если он есть.
Сделали слишком широкий блок в nginx
Если правило написано не только для /xmlrpc.php, а для более общего шаблона, можно случайно задеть другие PHP-файлы. Блокируйте только конкретный путь.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает одну лишнюю точку входа. Это особенно полезно, если у сайта есть проблемы с брутфорсом, а логика авторизации уже защищена нормальными паролями, ограничением попыток входа и 2FA.
Если вы ведёте несколько сайтов, удобно держать такой запрет в одном mu-plugin-шаблоне и разворачивать его одинаково. Это снижает шанс забыть настройку на отдельном проекте.
Если вам нужна более широкая чистка технических дублей, служебных страниц и лишних запросов, посмотрите Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но для самой задачи отключения XML-RPC отдельный плагин не обязателен — код выше решает вопрос без лишней нагрузки.
Что должно получиться в итоге
После внедрения у вас должен быть понятный и проверяемый результат: /xmlrpc.php закрыт, нужные интеграции не пострадали, а в логах больше нет лишнего шума. Если это так, настройка выполнена правильно. Если нет — сначала проверьте, где именно стоит блок: в WordPress, на сервере или в кэше.