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

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

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

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

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

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

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

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

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

Проверка через браузер и curl

Откройте https://example.com/xmlrpc.php. Если endpoint доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что он нужен, но значит, что он открыт.

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

Для более точной проверки можно отправить POST-запрос. Если XML-RPC работает, ответ будет отличаться от обычной 404/403. Если доступ закрыт, вы увидите отказ на уровне сервера или WordPress.

Что искать в логах

Проверьте:

частые POST-запросы к /xmlrpc.php;
повторяющиеся попытки авторизации;
запросы с одинаковых IP, но разными логинами;
ошибки 401, 403 или 200 на этом endpoint.

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

Как отключить XML-RPC в WordPress

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

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

Этот способ удобен тем, что не добавляет лишний плагин и легко откатывается. Добавьте код в functions.php дочерней темы или в отдельный файл в wp-content/mu-plugins/.

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

Это отключает XML-RPC на уровне WordPress. Если запрос всё равно доходит до сервера, WordPress вернёт отказ. Для большинства задач этого достаточно.

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

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

Для Apache можно закрыть доступ к xmlrpc.php через .htaccess. Это полезно, если вы хотите отсечь запросы до загрузки WordPress.

<Files xmlrpc.php>
    Require all denied
</Files>

Для Nginx правило обычно добавляют в конфигурацию сайта:

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

Серверный вариант быстрее и надёжнее, но требует доступа к конфигу. Если сайт на shared-хостинге, этот путь может быть недоступен.

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

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

Способ	Плюсы	Минусы
Код	Минимум зависимостей, быстро откатывается	Нужно не забыть, где именно лежит правка
Сервер	Закрывает доступ до WordPress	Нужен доступ к конфигу сервера
Плагин	Удобно для админов без доступа к коду	Зависимость от настроек и логики плагина

Пошаговое решение без лишнего риска

Если нужен безопасный порядок действий, делайте так:

Проверьте, нет ли активных интеграций, которым нужен XML-RPC.
Сделайте резервную копию файлов и базы.
Отключите XML-RPC через код или серверное правило.
Проверьте, не сломались ли публикации из внешних сервисов.
Посмотрите логи на предмет 403/401 и повторных обращений.

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

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и выполните запрос через curl. Если доступ закрыт, вы должны увидеть отказ, а не ответ WordPress.

curl -I https://example.com/xmlrpc.php
curl -X POST https://example.com/xmlrpc.php -d '<methodCall></methodCall>'

Дополнительно проверьте:

не работает ли публикация из мобильного приложения WordPress;
не отвалилась ли синхронизация с внешним сервисом;
не появились ли ошибки в логах после блокировки;
не открывается ли endpoint через CDN или кэширующий прокси.

Если вы закрывали XML-RPC через сервер, а WordPress всё ещё отвечает на запросы, значит правило не применилось к нужному виртуальному хосту или конфигурация не была перезагружена.

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

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

Это ожидаемо: часть функций Jetpack использует удалённый доступ. Решение простое — либо возвращаете XML-RPC, либо переходите на другой способ интеграции, если он доступен в конкретной задаче.

Добавили правило в .htaccess, но endpoint всё ещё открыт

Частая причина — сайт работает на Nginx, а .htaccess вообще не участвует в обработке запроса. В этом случае правило нужно добавлять в конфиг Nginx.

Использовали плагин, но защита сработала не полностью

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

Сломали интеграцию и не поняли, что именно виновато

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

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

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

актуальность ядра, темы и плагинов;
наличие ограничений на попытки входа;
правильные права на файлы;
отсутствие лишних публичных API-эндпоинтов;
логи на повторяющиеся попытки авторизации.

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

Если вам нужен более широкий набор технической чистки сайта — от отключения дублей и лишних скриптов до базовой SEO-оптимизации — иногда удобнее делать это через отдельный набор настроек, а не вручную по одному пункту. Например, в Clearfy Pro есть инструменты для технической уборки WordPress: https://wpshop.ru/plugins/clearfy.

Когда XML-RPC лучше не отключать

Не стоит отключать его без проверки, если:

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

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