XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация записей или старые интеграции. Проблема в том, что это не просто лишний файл xmlrpc.php, а отдельный канал обмена данными, который у части сайтов до сих пор используется осмысленно.
Если задача звучит как «убрать лишнюю поверхность атаки и при этом не сломать рабочие сценарии», подход должен быть не декоративным, а проверяемым: сначала понять, кто именно обращается к XML-RPC, потом отключить его так, чтобы это было обратимо, и только затем закрепить решение.
Когда XML-RPC можно отключать, а когда лучше не трогать
На практике XML-RPC можно отключать, если сайт не использует:
- мобильное приложение WordPress для публикации и редактирования;
- Jetpack в режимах, где он опирается на XML-RPC для части функций;
- внешние сервисы автопостинга и синхронизации, подключенные через XML-RPC;
- старые клиенты и скрипты, которые отправляют запросы в
/xmlrpc.php.
Если у вас есть редакторы, которые публикуют из сторонних приложений, или интеграции с CRM/автопостингом, сначала проверьте их документацию. Иногда переход на REST API уже сделан, но старый XML-RPC все еще включен «по привычке».
Что обычно ломается после отключения
Самый частый сценарий — не сайт в целом, а конкретная функция. Например, мобильное приложение перестает сохранять черновики, внешний сервис не может создать запись, а плагин мониторинга начинает сыпать ошибками авторизации. Поэтому отключение нужно делать не «вслепую», а с коротким списком зависимостей.
Диагностика: кто вообще ходит в xmlrpc.php
Перед изменениями посмотрите логи веб-сервера. Если в access log есть регулярные обращения к /xmlrpc.php, это уже повод не рубить доступ без проверки. На nginx и Apache путь будет один и тот же, меняется только формат логов.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, можно временно включить более подробный аудит на уровне сервера или посмотреть статистику в панели хостинга. Важен не только факт обращений, но и их источник: IP, user-agent, частота. Если это ваш офисный IP или IP интеграции, отключение без замены почти наверняка создаст проблему.
Полезно проверить и сам WordPress: нет ли активных плагинов, которые явно используют XML-RPC. В админке это не всегда видно, поэтому ориентируйтесь на документацию плагинов и список интеграций.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее контролировать поведение: в коде, на сервере или через плагин. Если нужен быстрый и обратимый вариант — начните с кода. Если важна защита на уровне веб-сервера — блокируйте запросы там. Если сайт обслуживает не разработчик, а редактор, иногда проще использовать плагин с понятной настройкой.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Прозрачно, легко откатить, не зависит от панели хостинга | Нужно аккуратно разместить код | Если есть доступ к файлам и нужен контролируемый вариант |
| Блокировка на сервере | Запросы не доходят до WordPress | Нужен доступ к конфигу nginx/Apache | Если нужно снизить нагрузку и поверхность атаки |
| Плагин | Подходит для админов без кода | Лишняя зависимость, иногда лишние функции | Если сайт ведет не разработчик |
Вариант 1: отключить через код
Самый практичный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так решение не исчезнет после обновления темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более точечный контроль, можно не отключать XML-RPC полностью, а блокировать только опасные методы. Но в большинстве случаев, когда интеграций нет, полный запрет проще и надежнее.
Вариант 2: закрыть доступ на сервере
На nginx можно отдать 403 для xmlrpc.php. Это полезно, если вы хотите отсечь запросы до запуска PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Серверный вариант хорош тем, что лишний трафик не попадает в WordPress вообще. Но если у вас нет доступа к конфигу, не стоит пытаться имитировать это через сложные костыли в теме.
Вариант 3: плагин для отключения XML-RPC
Если нужен интерфейс в админке, можно использовать плагин безопасности или оптимизации, который умеет отключать XML-RPC. Важно смотреть не на название, а на то, что именно делает плагин: иногда он не отключает XML-RPC полностью, а только ограничивает отдельные методы.
Если вы уже используете Clearfy Pro, проверьте, не решает ли он эту задачу вместе с другими пунктами технической чистки сайта. Для сайта, где важно убрать лишние точки входа и не раздувать набор плагинов, это часто удобнее, чем ставить отдельное решение. Ссылка на продукт: Clearfy Pro.
Пошаговое решение без сюрпризов
- Проверьте логи и список интеграций, которые могут использовать XML-RPC.
- Сделайте резервную копию файлов и базы, если вносите изменения в код или конфиг сервера.
- Выберите один способ отключения, а не несколько сразу.
- Внесите изменение в mu-plugin,
functions.phpдочерней темы или конфиг веб-сервера. - Проверьте ответ
/xmlrpc.phpи тестовые сценарии публикации. - Если что-то сломалось, откатите изменение и ищите конкретную зависимость.
Для mu-plugin можно сделать отдельный файл, например wp-content/mu-plugins/disable-xmlrpc.php:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант удобен тем, что он не зависит от темы и не потеряется при ее смене. Для технических сайтов это часто лучший баланс между простотой и управляемостью.
Как проверить, что XML-RPC действительно отключен
Проверка должна быть не «страница открылась», а именно ответ на запрос к /xmlrpc.php. Самый простой тест — открыть адрес в браузере или выполнить запрос через curl. Если все сделано правильно, вы не должны получать рабочий XML-RPC-ответ.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки: это может быть 403 Forbidden на уровне сервера или другой отказ в доступе. Если вы отключали через фильтр WordPress, сервер может вернуть страницу с сообщением о недоступности метода или ошибку, но не должен принимать XML-RPC-запросы как раньше.
Дополнительно проверьте:
- мобильное приложение WordPress, если оно использовалось;
- внешние сервисы публикации;
- Jetpack и связанные функции;
- логи сервера после тестового обращения к
/xmlrpc.php.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестали публиковаться записи из внешнего сервиса
Причина почти всегда одна: сервис работал через XML-RPC, а не через REST API. Решение — либо вернуть доступ, либо перевести интеграцию на другой способ авторизации и публикации. Не пытайтесь лечить это исключением из блокировки «наугад» без понимания, какой именно метод нужен.
Поставили плагин безопасности, но xmlrpc.php все равно отвечает
Некоторые плагины только ограничивают отдельные методы или добавляют дополнительные проверки, но не закрывают файл полностью. Проверьте настройки и документацию конкретного плагина. Если нужен жесткий запрет, надежнее сделать это на сервере или через xmlrpc_enabled.
Добавили код в родительскую тему и потеряли его после обновления
Это типичная ошибка. Для таких правок используйте дочернюю тему или mu-plugin. Если сайт уже живет на наборе технических доработок, mu-plugin обычно удобнее: он не зависит от темы и загружается стабильно.
Закрыли XML-RPC, но не уменьшили риск от других точек входа
Отключение XML-RPC не заменяет обновления ядра, плагинов и темы, а также базовую защиту админки. Если цель — снизить поверхность атаки, смотрите на сайт целиком: неиспользуемые плагины, лишние REST-эндпоинты, открытые авторизационные сценарии, слабые пароли.
Что еще стоит проверить после отключения
Если вы чистите сайт от лишних технических точек входа, имеет смысл заодно посмотреть и на другие вещи, которые часто остаются включенными без необходимости:
- неиспользуемые плагины и темы;
- старые формы авторизации и тестовые учетные записи;
- лишние REST-эндпоинты от плагинов, которые уже не нужны;
- дублирующиеся SEO-страницы и служебные архивы;
- кэширование и заголовки ответа для статических ресурсов.
Если вам нужен именно набор технических настроек для чистки WordPress без расползания по десятку отдельных плагинов, такие задачи обычно проще закрывать одним инструментом, чем собирать вручную. Но даже в этом случае сначала проверяйте, что конкретно меняется в конфигурации, а не ориентируйтесь только на список маркетинговых функций.
Практический критерий простой: после изменения сайт должен продолжать работать в тех сценариях, которые реально используются, а /xmlrpc.php — перестать быть доступной рабочей точкой входа. Если это так, решение можно считать удачным.