XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, мобильное приложение или внешняя публикация через старые интеграции. Проблема в том, что этот интерфейс нужен не всем, но и выключать его без проверки зависимостей нельзя. Ниже — практический сценарий: как понять, используется ли XML-RPC, как отключить его безопасно и как проверить, что ничего лишнего не сломалось.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удалённую публикацию, старые клиенты для блога, Jetpack-функции, завязанные на XML-RPC, или внешние сервисы, которым нужен этот протокол, его можно убрать. На большинстве современных сайтов это снижает поверхность атаки: XML-RPC часто используют для перебора паролей и массовых запросов к xmlrpc.php.
Но есть важная оговорка: отключение должно быть осознанным. Если у вас включены:
- Jetpack с функциями, которые ходят через XML-RPC;
- мобильное приложение WordPress для публикации и редактирования;
- внешние сервисы автопостинга или мониторинга, использующие XML-RPC;
- старые интеграции с блог-клиентами;
— сначала проверьте, чем именно пользуетесь. Иначе получите не «усиление безопасности», а сломанный рабочий процесс.
Диагностика: используется ли XML-RPC на вашем сайте
Самый простой путь — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в аналитике безопасности. Если у вас есть доступ к access log, ищите запросы к этому файлу. Если логов нет, можно проверить вручную через браузер: при открытии https://example.com/xmlrpc.php WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает использование, но подтверждает, что файл доступен.
Дальше проверьте зависимости:
- в Jetpack откройте список активных модулей и посмотрите, не завязаны ли они на соединение с WordPress.com;
- в мобильном приложении WordPress попробуйте обновить список сайтов и выполнить тестовую синхронизацию;
- если есть внешние интеграции, посмотрите их документацию: старые плагины и сервисы часто прямо пишут, нужен ли им XML-RPC.
Если сайт работает только через обычную админку и REST API, а внешних клиентов нет, отключение обычно безопасно.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужна быстрая настройка без кода | Просто включить, часто есть дополнительные фильтры | Лишняя зависимость, иногда блокирует больше, чем нужно |
| Код в теме или mu-plugin | Нужен точечный контроль | Прозрачно, без лишнего функционала | Нужно аккуратно разместить код |
| Правило на уровне сервера | Есть доступ к nginx/apache и понятна инфраструктура | Режет запросы раньше WordPress | Можно случайно задеть легитимные запросы |
Для большинства сайтов практичнее код или серверное правило. Плагин имеет смысл, если у вас уже есть централизованный security-плагин и вы не хотите плодить ещё один.
Вариант 1: отключить XML-RPC через код
Самый предсказуемый способ — вернуть __return_false на фильтр xmlrpc_enabled. Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Если хотите не просто отключить сам интерфейс, а ещё и отдать 403 на прямой доступ к файлу, можно добавить отдельную проверку на раннем этапе:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );
Первый вариант обычно достаточно. Второй полезен, если вы хотите жёстко пресечь обращения, но его стоит тестировать внимательнее: на некоторых конфигурациях достаточно фильтра xmlrpc_enabled, и дополнительная логика не нужна.
Вариант 2: закрыть xmlrpc.php на уровне сервера
Если у вас nginx, можно заблокировать сам файл. Это особенно удобно, когда нужно отсечь запросы до загрузки WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
Этот вариант хорош, если вы уверены, что XML-RPC не нужен вообще. Если есть сомнения по Jetpack или мобильному приложению, сначала проверьте рабочие сценарии, а уже потом режьте на сервере.
Пошаговое решение без сюрпризов
- Проверьте, используете ли Jetpack, мобильное приложение WordPress или внешние интеграции, которые завязаны на XML-RPC.
- Сделайте резервную копию файла конфигурации или подготовьте отдельный mu-plugin.
- Сначала примените фильтр
xmlrpc_enabledи проверьте сайт. - Если всё работает, при необходимости добавьте блокировку на уровне сервера.
- После внедрения проверьте логи и реальные сценарии публикации.
Если у вас несколько администраторов, предупредите их заранее. Иначе кто-то может открыть мобильное приложение и решить, что «сломался WordPress», хотя на самом деле отключён только старый канал связи.
Как проверить, что решение сработало
Проверка должна быть не формальной, а прикладной. Откройте /xmlrpc.php в браузере или выполните POST-запрос тестовым клиентом. Если XML-RPC отключён корректно, вы не должны получать рабочий ответ метода.
Для быстрой проверки через curl можно отправить минимальный запрос:
curl -i -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Ожидаемое поведение зависит от способа блокировки: это может быть 403 Forbidden, 405 Method Not Allowed или ответ WordPress с сообщением об отключённом XML-RPC. Главное — не должен возвращаться список методов и не должна проходить авторизованная работа через XML-RPC.
Дополнительно проверьте:
- вход в админку и публикацию записей;
- работу REST API, если он используется внешними сервисами;
- Jetpack и мобильное приложение, если они остались в стеке;
- логи веб-сервера на предмет повторяющихся ошибок после блокировки.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Это типичный сценарий. Не надо сразу возвращать всё назад. Сначала проверьте, какие именно функции Jetpack вам нужны. Если без XML-RPC не работает критичный модуль, оставьте протокол включённым и ограничьте доступ другими способами: ограничение по IP, защита от brute force, WAF или более точечная фильтрация запросов.
Поставили плагин, а он сломал мобильное приложение
Некоторые security-плагины блокируют XML-RPC вместе с REST API или добавляют слишком агрессивные правила. Если мобильное приложение WordPress нужно, переходите на кодовый вариант и проверяйте поведение без лишних фильтров.
Закрыли файл на сервере, но забыли про кэш и прокси
Иногда старые ответы или промежуточные правила мешают понять, что именно происходит. После изменений очистите кэш плагина, серверный кэш и, если есть, CDN. Иначе вы будете тестировать не текущую конфигурацию, а старую копию ответа.
Добавили код в родительскую тему
После обновления темы правило исчезнет. Для таких задач лучше использовать дочернюю тему или mu-plugin. Это не только надёжнее, но и проще сопровождать, если на сайте несколько точек кастомизации.
Практические советы по безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа. Если цель именно безопасность, дополнительно проверьте:
- сложность паролей и наличие двухфакторной аутентификации;
- ограничение попыток входа;
- актуальность ядра, темы и плагинов;
- наличие лишних пользователей с правами администратора.
С точки зрения производительности выгода обычно не драматическая, но на сайтах с большим количеством мусорных запросов к xmlrpc.php блокировка уменьшает лишнюю нагрузку на PHP и логирование. Это особенно заметно, если сайт регулярно атакуют перебором паролей через XML-RPC.
Если вам нужен более широкий набор настроек для технической чистки WordPress, имеет смысл смотреть не на точечные костыли, а на инструменты, которые позволяют централизованно управлять дублями, служебными элементами и безопасностью. Например, в Clearfy Pro есть набор функций для технической оптимизации и отключения лишнего, но применять его стоит только если вам реально нужен такой стек, а не ради одной галочки.
Когда XML-RPC лучше не трогать
Не отключайте его, если у вас есть рабочие интеграции, которые вы не готовы быстро заменить. Особенно это касается старых цепочек публикации и мобильного редактирования. В таких случаях разумнее оставить XML-RPC включённым и закрыть риски другими мерами: WAF, ограничение доступа, мониторинг логов и нормальная защита авторизации.
Если же зависимостей нет, отключение через фильтр xmlrpc_enabled — самый чистый и обратимый вариант. Он не ломает структуру сайта, не затрагивает контент и легко откатывается, если выяснится, что какой-то сервис всё-таки нужен.