XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестаёт работать Jetpack, мобильное приложение WordPress или внешняя публикация через сторонний сервис. На практике задача не в том, чтобы просто закрыть endpoint, а в том, чтобы понять, кто именно его использует, и отключить его без побочных эффектов.
Если сайт не принимает удалённую публикацию и не использует интеграции, XML-RPC обычно можно убрать. Но делать это лучше после проверки логов и списка подключений, а не по совету из случайного чек-листа.
Когда XML-RPC действительно стоит отключать
XML-RPC — это отдельный входной канал в WordPress, доступный по адресу /xmlrpc.php. Его используют старые клиенты, некоторые сервисы автопостинга, Jetpack и мобильное приложение WordPress. Если вы ничего из этого не используете, endpoint только расширяет поверхность атаки и даёт лишнюю нагрузку при переборе запросов.
Отключение особенно уместно, если у сайта уже есть REST API для интеграций, а публикация идёт только через админку. В этом случае XML-RPC не нужен как функционально, так и технически.
Диагностика: кто реально обращается к xmlrpc.php
Перед изменениями проверьте, есть ли обращения к endpoint в логах веб-сервера. Это самый надёжный способ понять, нужен ли он вообще.
Что искать в access log
Ищите запросы к /xmlrpc.php, особенно с кодами 200, 401, 403 и повторяющимися попытками с одного IP. Если запросы есть, посмотрите User-Agent и частоту. Для легитимных интеграций обычно виден понятный паттерн, а не хаотичный перебор.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам будет другим, но смысл тот же: сначала посмотреть фактические обращения, потом что-то отключать.
Проверка зависимостей в самом сайте
- используете ли вы Jetpack;
- публикуете ли записи через мобильное приложение WordPress;
- есть ли внешние сервисы автопостинга или синхронизации;
- подключён ли старый клиент для удалённой публикации;
- есть ли кастомные интеграции, которые отправляют запросы через XML-RPC.
Если хотя бы один пункт подтверждается, сначала тестируйте отключение на staging-копии или в окно низкой нагрузки.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, нужен ли endpoint полностью или только для защиты от атак. Ниже — варианты от самого жёсткого к более мягкому.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Отключение на уровне сервера | XML-RPC не нужен вообще | Не доходит до WordPress, меньше лишней нагрузки | Нужно править конфиг веб-сервера |
| Фильтр в WordPress | Нужен контроль из кода темы или плагина | Просто внедрить, легко откатить | Запрос всё равно попадает в WordPress |
| Плагин безопасности | Нужен UI и быстрый запуск | Удобно для админов без доступа к серверу | Ещё один плагин в системе |
Вариант 1: запретить доступ на уровне Nginx
Если XML-RPC точно не нужен, лучше закрыть его на уровне веб-сервера. Тогда запросы не будут доходить до PHP вообще.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите Nginx. Конкретные команды зависят от дистрибутива, но принцип один: сначала тест конфигурации, потом reload.
Вариант 2: отключить через код WordPress
Если серверный доступ ограничен, можно отключить XML-RPC через фильтр xmlrpc_enabled. Это рабочий вариант для темы или небольшого mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код лучше не класть в активную тему, если вы планируете её менять. Надёжнее вынести в небольшой must-use плагин или в собственный функциональный плагин.
Вариант 3: отключить только опасные методы
Иногда XML-RPC нужен частично, например для конкретной интеграции. Тогда можно не рубить endpoint полностью, а ограничить отдельные методы. Это уже более тонкая настройка, и её стоит делать только если вы понимаете, какие вызовы реально используются.
На практике такой подход сложнее поддерживать, чем полный запрет, поэтому он оправдан только при наличии зависимостей.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что XML-RPC не используется легитимными сервисами.
- Сделайте резервную копию конфигурации сервера или файла с кодом, который будете менять.
- Выберите способ отключения: сервер, код или плагин безопасности.
- Внесите изменение на staging-сайте, если он есть.
- Проверьте, не сломались ли Jetpack, мобильное приложение и внешняя публикация.
- После успешной проверки перенесите изменение на боевой сайт.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Нужен фактический ответ сервера и отсутствие побочных эффектов.
Проверка endpoint
Откройте https://ваш-домен/xmlrpc.php. Если доступ закрыт на уровне сервера, вы увидите отказ в доступе или 403. Если отключение сделано через WordPress-фильтр, ответ может отличаться, но endpoint не должен работать как раньше.
Для более точной проверки можно отправить простой POST-запрос и посмотреть код ответа:
curl -i -X POST https://example.com/xmlrpc.phpЕсли вы видите, что endpoint больше не принимает запросы как рабочий канал, задача выполнена.
Проверка зависимостей
- Jetpack не должен терять соединение, если он используется;
- мобильное приложение WordPress должно продолжать публиковать записи, если это ваш сценарий;
- внешние сервисы автопостинга не должны падать с ошибкой авторизации;
- в логах не должно быть новых массовых ошибок после изменения.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина простая: Jetpack использует XML-RPC для части сценариев. Если он нужен, не отключайте endpoint полностью. Либо оставьте его открытым, либо пересмотрите саму необходимость Jetpack на сайте.
Поставили плагин безопасности, но запросы всё равно доходят до WordPress
Некоторые плагины блокируют XML-RPC уже после загрузки WordPress. Это лучше, чем ничего, но не так эффективно, как серверный запрет. Если нагрузка и атаки заметны в логах, переносите блокировку на уровень Nginx или Apache.
Добавили код в тему и забыли про него
Когда отключение лежит в теме, его легко потерять при редизайне или смене шаблона. Для системной настройки используйте mu-plugin или отдельный функциональный плагин.
Сломали интеграцию, но не поняли какую
Если после отключения что-то перестало работать, ищите обращения к /xmlrpc.php в логах до и после изменения. Обычно источник проблемы быстро находится по User-Agent, IP или времени запроса.
Практические советы по безопасности и производительности
Если XML-RPC не нужен, его отключение — нормальная гигиена, а не «жёсткая оптимизация». Это снижает число лишних запросов и уменьшает риск перебора логинов через старый канал.
Но не стоит считать это полноценной защитой сайта. Пароли, ограничение попыток входа, обновления ядра и плагинов, а также контроль прав пользователей остаются обязательными.
- не отключайте XML-RPC вслепую на клиентских проектах с интеграциями;
- проверяйте логи до и после изменения;
- если нужен быстрый интерфейс для админа, используйте плагин только как временное решение;
- для постоянной защиты лучше серверный запрет, а не косметическая блокировка в WordPress.
Если у вас уже стоит набор для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не закрывает ли он XML-RPC и связанные настройки уже из интерфейса. Это удобнее, чем держать разрозненные правки в нескольких местах, но всё равно требует проверки на вашем конкретном сайте.
Когда лучше не отключать XML-RPC
Не трогайте endpoint, если он нужен для реальной рабочей схемы: удалённая публикация, синхронизация, мобильный редактор, часть связки с Jetpack. В таких случаях безопаснее ограничить доступ по IP, усилить аутентификацию и отдельно проверить, какие методы используются.
Если сомневаетесь, сначала отключите на staging и прогоните типовые сценарии. Это дешевле, чем потом ловить сломанные публикации на боевом сайте.