Отключение XML-RPC в WordPress: как убрать лишний входной вектор без поломки сайта

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

Если задача звучит как «сайт стал отвечать медленно, в логах много запросов к xmlrpc.php, а интеграции вроде бы не нужны», это как раз тот случай, где лучше не гадать, а проверить факты и убрать лишнее аккуратно.

Когда XML-RPC действительно стоит отключать

Файл xmlrpc.php нужен не всем. Исторически он использовался для удалённой публикации, синхронизации и некоторых внешних клиентов. Сейчас в большинстве проектов его роль минимальна, а вот нагрузку и шум в логах он создаёт вполне реальную.

Отключение уместно, если:

• вы не публикуете записи через старые внешние клиенты;
• не используете мобильное приложение WordPress для управления сайтом;
• не подключали сервисы, которым нужен XML-RPC для удалённой записи;
• в логах видно много обращений к /xmlrpc.php с ошибками авторизации;
• нужно сократить поверхность атаки без изменения основной логики сайта.

Если хотя бы один пункт под вопросом, сначала проверьте реальные зависимости. Отключать «на всякий случай» без проверки — плохая идея: потом обычно ищут, почему перестала работать публикация из внешнего сервиса или синхронизация заметок.

Диагностика: кто вообще обращается к xmlrpc.php

Начните с простого: посмотрите access log веб-сервера или логи в панели хостинга. Ищите запросы к /xmlrpc.php. Если их много и они идут с разных IP, это уже повод для действий. Если запросы единичные и приходят от понятного сервиса, отключение может сломать интеграцию.

Что проверить до изменений

• есть ли в админке активные плагины для публикации или синхронизации контента;
• используется ли мобильное приложение WordPress;
• подключён ли сторонний сервис, который отправляет записи через XML-RPC;
• есть ли в логах попытки system.multicall и массовые ошибки авторизации;
• не включён ли плагин кеша или безопасности, который уже блокирует этот файл.

Если доступа к логам нет, можно хотя бы проверить ответ сервера напрямую. Нормальный сайт обычно отвечает на запрос к xmlrpc.php либо сообщением WordPress, либо блокировкой на уровне сервера/плагина. Важно не сам ответ, а то, что вы понимаете, кто и зачем его вызывает.

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

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

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

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

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

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

Вариант 2. Заблокировать доступ через сервер

Если у вас Apache, можно закрыть файл через .htaccess. Это полезно, когда нужно не просто выключить функциональность, а ещё и не тратить ресурсы на обработку запроса.

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

Для Nginx логика будет другой, но смысл тот же: отдать 403 до передачи запроса в WordPress. Конкретный блок зависит от вашей конфигурации, поэтому не копируйте чужой фрагмент без проверки синтаксиса и структуры конфига.

Вариант 3. Использовать плагин безопасности

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

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

Пошаговое решение без лишнего риска

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

Если вы работаете через код, mu-plugin обычно надёжнее, чем правка темы. Пример минимального mu-plugin:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если каталога mu-plugins нет, создайте его вручную. Такой способ удобен тем, что отключение не зависит от темы и не исчезнет после обновления.

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

Проверка нужна не формальная, а практическая. Откройте /xmlrpc.php в браузере или выполните запрос через curl. Если доступ закрыт на уровне сервера, вы увидите 403 или похожий отказ. Если отключение сделано только через фильтр WordPress, ответ может отличаться, но сам функционал XML-RPC работать не должен.

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

После этого проверьте ещё три вещи:

• в логах больше не растут обращения к xmlrpc.php от неизвестных IP;
• админка WordPress работает как обычно;
• внешние сервисы публикации, если они есть, не потеряли связь.

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

Частые ошибки и как их исправить

Отключили XML-RPC, но забыли про нужную интеграцию

Это типичная ситуация, когда решение принимали по логам, а не по списку реальных подключений. Исправление простое: верните доступ, если сервис действительно нужен, и перенесите защиту на уровень ограничений по IP или на более точную настройку плагина безопасности.

Поставили тяжёлый плагин ради одной функции

Если задача только в блокировке xmlrpc.php, отдельный большой плагин часто избыточен. Он добавляет свои настройки, обновления и потенциальные конфликты. В таком случае код или серверный запрет обычно чище.

Закрыли файл в .htaccess, но сайт всё равно отвечает

Иногда правило добавили не в тот блок, либо сайт работает на Nginx, где .htaccess не используется. Проверьте стек сервера и место, где реально применяется конфигурация.

Сломали права на файлы или структуру mu-plugins

Если mu-plugin не подхватился, проверьте путь wp-content/mu-plugins/, имя файла и отсутствие синтаксических ошибок. WordPress не покажет красивую ошибку, если файл просто не загрузился.

Безопасность и производительность: что ещё имеет смысл сделать рядом

Отключение XML-RPC не заменяет базовую защиту входа. Если на сайте идут брутфорс-атаки, проверьте лимиты на авторизацию, двухфакторную аутентификацию для админов и защиту wp-login.php. XML-RPC — это только один из входов, а не вся проблема.

Для производительности полезно смотреть шире: если сайт регулярно получает мусорные запросы, блокировка на уровне сервера экономит ресурсы лучше, чем обработка через WordPress. А если у вас уже есть плагин кеша или безопасности, не дублируйте одну и ту же функцию в трёх местах — потом сложно понять, что именно сработало.

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