Как отключить XML-RPC в WordPress без поломки Jetpack и мобильных приложений

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

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

Когда XML-RPC можно отключать

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

• Jetpack и связанные с ним функции синхронизации;
• мобильное приложение WordPress, если вы им реально пользуетесь;
• внешние сервисы автопостинга и мониторинга, которые работают по XML-RPC;
• старые интеграции, написанные до массового перехода на REST API.

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

Диагностика: используется ли XML-RPC сейчас

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

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

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

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

Если вы видите 200 OK или похожий ответ, файл доступен извне. Дальше важно понять, кто его использует.

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

В access.log ищите запросы к /xmlrpc.php. Полезно смотреть не только факт обращения, но и частоту, IP и user-agent. Если запросы идут сериями с одинаковым payload, это типичный брутфорс или сканирование.

grep "xmlrpc.php" access.log | tail -n 50

Если у вас есть плагин безопасности или серверный WAF, проверьте его журнал блокировок. Иногда XML-RPC уже фильтруется, но сам файл остается доступным, и это создает ложное ощущение защиты.

Как отключить XML-RPC: три рабочих варианта

Выбор зависит от того, нужен ли вам полный запрет или только ограничение доступа. Для большинства сайтов достаточно серверного или кодового отключения. Плагин имеет смысл, если вы хотите быстро включать и выключать защиту без правок темы.

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

Самый понятный способ — добавить фильтр в functions.php дочерней темы или, лучше, в mu-plugin. Так вы не потеряете настройку при обновлении темы.

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

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

Вариант 2: закрыть на уровне сервера

Если у вас Nginx, можно отдать 403 на запросы к /xmlrpc.php. Это полезно, когда вы хотите отрезать вход еще до загрузки WordPress.

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

Для Apache обычно используют правило в .htaccess:

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

Серверный вариант хорош тем, что не зависит от темы и плагинов. Но если у вас несколько сайтов на одном хостинге и нет уверенности в конфигурации, сначала проверьте правило на тестовой среде.

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

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

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

Пошаговое решение для продакшена

1. Проверьте логи и убедитесь, что XML-RPC не нужен активным интеграциям.
2. Сделайте бэкап конфигурации и файлов, если меняете серверное правило.
3. Выберите один способ отключения: код или сервер.
4. Примените изменение сначала на staging, если он есть.
5. Проверьте ответ /xmlrpc.php и работу входа в админку, публикаций и внешних сервисов.
6. Если используете Jetpack или мобильное приложение, протестируйте их отдельно.

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

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

Проверка должна быть не формальной, а прикладной. Недостаточно увидеть «что-то изменилось» — важно понять, что закрыт именно нежелательный доступ, а нужные сценарии не пострадали.

• Откройте /xmlrpc.php в браузере: должен быть отказ или пустой ответ в зависимости от способа блокировки.
• Сделайте curl -I и проверьте код ответа: для жесткого запрета ожидаем 403 или 404.
• Посмотрите access.log: новые обращения к /xmlrpc.php должны либо отсеиваться, либо не доходить до WordPress.
• Проверьте вход в админку, создание записей и загрузку медиа.
• Если есть Jetpack, мобильное приложение или внешняя публикация, протестируйте именно их.

Если после отключения сайт работает, а запросы к /xmlrpc.php больше не доходят до WordPress, задача решена.

Частые ошибки и почему они возникают

Отключили XML-RPC и сломали Jetpack

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

Поставили сразу несколько способов блокировки

Когда XML-RPC закрыт и в WordPress, и на сервере, и еще плагином безопасности, потом сложно понять, где именно возникла ошибка. Для продакшена лучше один основной способ и один резервный, если это действительно нужно.

Правило в .htaccess не сработало

Причина обычно в том, что сайт работает не на Apache, а на Nginx, либо правила перезаписываются другой конфигурацией. В этом случае проверяйте именно активный веб-сервер, а не копируйте универсальные инструкции.

Считают, что XML-RPC и REST API — одно и то же

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

Что делать, если XML-RPC нужен частично

Иногда полный запрет не подходит. Например, сайт использует старый сервис публикации, но вы хотите убрать лишние методы и снизить поверхность атаки. В таких случаях лучше не придумывать самодельные костыли, а пересмотреть сам сценарий интеграции: перевести его на REST API, webhook или прямую отправку через админку.

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

Главное правило простое: не отключайте XML-RPC ради абстрактной «безопасности», если у вас есть живые зависимости. Сначала диагностика, потом одно понятное изменение, потом проверка по логам и реальным сценариям.