XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации, старые интеграции или Jetpack. Проблема обычно не в самом файле xmlrpc.php, а в том, что его закрывают без проверки зависимостей и без понятного плана отката.
Ниже — рабочая схема: как понять, нужен ли вам XML-RPC, как отключить его на уровне кода или сервера, чем это отличается от блокировки через плагин и как проверить результат без гадания по логам.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешнюю публикацию, мобильные клиенты WordPress, старые десктопные редакторы и сервисы, которые ходят в XML-RPC, этот интерфейс чаще всего не нужен. На практике его оставляют включённым по инерции, а потом получают лишнюю поверхность атаки и шум в логах.
Но есть важная оговорка: отключение XML-RPC — это не универсальная «кнопка безопасности». Если у вас завязаны:
- Jetpack с отдельными функциями синхронизации;
- мобильное приложение WordPress;
- внешние сервисы автопостинга;
- старые интеграции, которые не переведены на REST API;
то сначала проверьте, что именно использует XML-RPC в вашем проекте. Иначе вы получите не защиту, а сломанный сценарий публикации.
Диагностика: как понять, используется ли xmlrpc.php
Самый быстрый способ — посмотреть логи веб-сервера и запросы к /xmlrpc.php. Если там есть регулярные обращения от ваших сервисов, отключать интерфейс без замены нельзя.
Что проверить перед изменениями
- есть ли в логах запросы к
xmlrpc.phpот ваших IP или сервисов; - использует ли сайт Jetpack;
- есть ли внешние публикации через сторонние инструменты;
- работает ли мобильное приложение WordPress у редакторов;
- не завязаны ли на XML-RPC старые скрипты импорта.
Если доступа к логам нет, можно хотя бы вручную проверить ответ сервера. На включённом XML-RPC обычно видно, что файл доступен, даже если метод не вызывается корректно.
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает не как на обычную страницу, это ещё не значит, что интерфейс безопасен. Важно не просто получить 403 на уровне приложения, а убедиться, что запрос вообще не доходит до WordPress там, где это возможно.
Пошаговое решение: как отключить XML-RPC без лишнего риска
Есть три рабочих подхода: через код, через сервер и через плагин. Для продакшена я обычно выбираю серверный запрет, если точно не нужны исключения. Если нужна гибкость — отключение через код в теме или mu-plugin.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в mu-plugin | Контролируемо, легко откатить | Запрос всё равно попадает в WordPress |
| Правило на сервере | Режет раньше, меньше нагрузки | Нужно аккуратно настраивать nginx/apache |
| Плагин безопасности | Быстро включить | Лишняя зависимость, не всегда прозрачно |
Вариант 1: отключение через код
Если нужен простой и понятный контроль, добавьте код в mu-plugin. Это лучше, чем править functions.php активной темы: отключение не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC на уровне WordPress. Если какой-то сервис продолжит стучаться в xmlrpc.php, он получит отказ уже после загрузки WordPress.
Вариант 2: блокировка на уровне сервера
Если цель — снизить лишнюю нагрузку и не пускать запросы в PHP вообще, блокируйте xmlrpc.php на веб-сервере. Для Apache это обычно делается через .htaccess, для nginx — через конфигурацию сайта.
Для Apache можно использовать такое правило:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика другая: запрос нужно отдать с 403 до передачи в PHP-FPM. Пример зависит от вашей конфигурации, но суть одна — не обрабатывать файл как обычный PHP-скрипт.
Если вы не уверены в конфиге nginx, лучше сначала протестировать на staging. Ошибка в location-блоке может задеть не только XML-RPC, но и другие PHP-обработчики.
Вариант 3: плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, это допустимо, но только если вы понимаете, что именно он меняет. Для точечной задачи обычно удобнее код или сервер, потому что там меньше «магии».
Из практики: плагин хорош как временное решение или для админов без доступа к конфигам. Но если у вас строгая поддержка и понятный деплой, лучше держать правило в коде или на сервере.
Как проверить, что XML-RPC действительно закрыт
После внедрения не ограничивайтесь тем, что «сайт открывается». Нужно проверить именно целевой endpoint и убедиться, что ответ соответствует выбранному способу блокировки.
Минимальный чек-лист проверки
- запрос
/xmlrpc.phpвозвращает403или другой ожидаемый отказ; - в логах нет успешных обращений к XML-RPC после изменения;
- Jetpack и внешние интеграции не потеряли связь, если они нужны;
- мобильное приложение WordPress не используется в рабочих сценариях;
- нет ошибок в PHP-логах после включения фильтра.
Проверить ответ можно так:
curl -I https://example.com/xmlrpc.phpЕсли вы отключали XML-RPC через фильтр xmlrpc_enabled, полезно дополнительно посмотреть, не остались ли старые запросы в access log. Если блокировали на сервере, убедитесь, что WordPress вообще не получает эти обращения.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина обычно в том, что Jetpack всё ещё использует XML-RPC для части функций на конкретной установке. Решение простое: либо вернуть доступ, либо перевести нужный сценарий на другой механизм и проверить, что он реально работает до отключения.
Поставили правило в .htaccess, но файл всё равно доступен
Это бывает, если правило не применяется к нужному виртуальному хосту, или сервер вообще работает не на Apache. В таком случае проверяйте реальный стек: Apache, nginx, reverse proxy, CDN. Иногда блокировку нужно делать на уровне прокси, а не в WordPress.
Получили 403, но WordPress всё равно грузится
Это нормально для фильтра на уровне WordPress: запрос дошёл до PHP, а потом был отклонён. Если цель — экономия ресурсов и снижение шума, лучше блокировать раньше, на сервере.
Сломали внешнюю публикацию, но не заметили сразу
Самая неприятная ошибка — отключить XML-RPC без списка зависимостей. Перед изменением зафиксируйте, какие сервисы ходят на сайт, и проверьте их после внедрения вручную, а не по косвенным признакам.
Безопасность и производительность: что ещё имеет смысл сделать рядом
Отключение XML-RPC полезно, но не заменяет базовую гигиену. Если вы уже чистите поверхность атаки, посмотрите на соседние точки входа: /wp-login.php, REST API, устаревшие плагины, лишние авторы с админскими правами.
Если нужен более широкий набор мер по чистке и удалению лишнего технического шума, можно посмотреть в сторону инструментов вроде Clearfy Pro: Clearfy Pro. Но даже с плагином важно понимать, какие именно функции вы отключаете и как это влияет на интеграции.
Для производительности отдельный плюс в том, что сервер перестаёт тратить ресурсы на обработку бесполезных запросов. На нагруженных сайтах это заметно не по «магическим процентах», а по уменьшению мусора в логах и более предсказуемому поведению под брутфорсом.
Когда лучше не отключать XML-RPC
Если у вас есть активные внешние интеграции, а перевести их на REST API быстро нельзя, не ломайте рабочий процесс ради абстрактной «безопасности». В таких случаях лучше ограничить доступ точечно: по IP, через WAF или отдельные правила на сервере, а не рубить всё подряд.
Хорошая практика — сначала составить список зависимостей, потом отключать, потом проверять. Это звучит банально, но именно на этом шаге чаще всего и ломаются сайты: не в коде, а в отсутствии инвентаризации.
