XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или интеграции, которые до сих пор используют этот интерфейс. Поэтому правильный вопрос не «как выключить XML-RPC», а как отключить его безопасно и понять, нужен ли он вообще.
Если на сайте нет старых интеграций, удалённой публикации и сторонних сервисов, которые обращаются к /xmlrpc.php, этот интерфейс обычно только расширяет поверхность атаки. Но отключать его лучше осознанно: сначала диагностика, потом способ блокировки, затем проверка.
Когда XML-RPC мешает и как это понять
Проблема обычно всплывает в одном из трёх сценариев: в логах видно много запросов к xmlrpc.php, хостинг ругается на нагрузку от брутфорса, либо после «усиления безопасности» перестаёт работать внешняя публикация. Сам по себе файл xmlrpc.php в корне WordPress — нормальная часть ядра, и удалять его вручную не нужно.
Что проверить перед отключением
- Используете ли вы мобильное приложение WordPress для публикации.
- Есть ли интеграции с внешними сервисами, которые отправляют записи через XML-RPC.
- Нужны ли pingback/trackback на сайте — чаще всего нет.
- Есть ли в логах частые POST-запросы к
/xmlrpc.phpс одинаковых IP.
Если сайт давно живёт без внешней публикации, отключение обычно проходит безболезненно. Если же у вас есть автоматизация через старые клиенты, сначала проверьте её на тестовой копии.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, что вам важнее: простота, контроль на уровне кода или блокировка на сервере. Ниже — варианты от самого мягкого к более жёсткому.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужен быстрый способ без правки кода | Просто включить и выключить | Лишняя зависимость от плагина |
| Код в теме или mu-plugin | Есть доступ к файлам и нужен контроль | Не зависит от интерфейса админки | Нужно аккуратно обновлять |
| Блокировка на сервере | Нужно отсечь запросы до WordPress | Снижает нагрузку раньше PHP | Требует доступа к конфигу сервера |
Вариант 1. Отключить XML-RPC через код
Самый предсказуемый способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку после обновления темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужно не просто отключить интерфейс, а ещё и убрать pingback-запросы, можно дополнительно запретить соответствующие методы. Но в большинстве случаев достаточно фильтра выше.
Вариант 2. Блокировать запросы к xmlrpc.php на уровне сервера
Если цель — снизить нагрузку от массовых запросов, блокировка на сервере часто эффективнее. Для Apache можно использовать .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот способ хорош тем, что запросы не доходят до WordPress вообще. Но если у вас есть легитимный клиент, он тоже перестанет работать сразу.
Вариант 3. Использовать плагин безопасности или оптимизации
Если на сайте уже стоит плагин, который умеет управлять XML-RPC, можно использовать его настройки вместо отдельного кода. Например, в Clearfy Pro есть инструменты для технической чистки и отключения лишних возможностей WordPress. Это удобно, когда вы одновременно убираете и другие ненужные функции, но важно не включать всё подряд без проверки.
Пошаговое решение без сюрпризов
- Сделайте резервную копию файлов и базы.
- Проверьте, есть ли у сайта внешние клиенты или интеграции, завязанные на XML-RPC.
- Выберите способ отключения: код, сервер или плагин.
- Внесите изменение сначала на staging-копии.
- Проверьте доступность сайта и работу публикации.
- Посмотрите логи на предмет ошибок и повторных обращений к
/xmlrpc.php.
Если вы работаете через код, лучше вынести отключение в mu-plugin. Это удобно для технических правок, которые должны жить независимо от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой файл можно положить в wp-content/mu-plugins/. Если папки нет, её нужно создать вручную. WordPress подхватит mu-plugin автоматически.
Как проверить, что отключение сработало
Проверка нужна не только для безопасности, но и чтобы не сломать нужные интеграции. Самый простой тест — открыть /xmlrpc.php в браузере. Если всё отключено корректно, вы не должны видеть рабочий XML-RPC-ответ. На серверной блокировке чаще будет 403 Forbidden, при отключении через фильтр поведение может отличаться в зависимости от окружения, но сам интерфейс должен быть недоступен для использования.
Дополнительно проверьте:
- не отправляются ли POST-запросы к
/xmlrpc.phpиз внешних сервисов; - не появились ли ошибки в логах WordPress или веб-сервера;
- работает ли обычная авторизация, публикация и REST API;
- не сломалась ли мобильная публикация, если вы её используете.
Если на сайте есть мониторинг, посмотрите, исчез ли шум от массовых обращений к XML-RPC. Это особенно заметно на небольших проектах, где брутфорс идёт волнами и создаёт лишнюю нагрузку на PHP-FPM.
Частые ошибки и как их исправить
Удаляют файл xmlrpc.php вручную
Так делать не стоит. Обновление WordPress может вернуть файл, а часть хостингов и проверок целостности начнёт ругаться. Правильнее блокировать доступ или отключать функциональность через фильтр.
Отключают XML-RPC, не проверив интеграции
После этого внезапно перестают работать старые приложения, автопостинг или внешние клиенты. Перед изменением обязательно найдите все точки, где сайт принимает публикации извне.
Ставят тяжёлый security-плагин только ради одной галочки
Если вам нужен только запрет XML-RPC, отдельный громоздкий плагин может быть лишним. Лучше либо использовать уже установленный инструмент, либо добавить короткий код. Лишние плагины — это дополнительная нагрузка и ещё одна точка обновления.
Блокируют всё подряд на уровне сервера
Иногда вместе с xmlrpc.php случайно режут и другие важные endpoints. После правок всегда проверяйте не только главную страницу, но и вход в админку, REST API и формы, если они есть.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не панацея. Если на сайте есть массовые попытки входа, проверьте ещё и другие базовые меры: сложные пароли, ограничение попыток входа, двухфакторную аутентификацию для админов, актуальные версии ядра и плагинов. Это даст больше пользы, чем точечная правка одного файла.
Если вы уже занимаетесь технической чисткой сайта, имеет смысл смотреть на лишние функции комплексно: отключать ненужные эмодзи, embeds, pingbacks и другие элементы, которые не используются в проекте. Но каждую опцию нужно проверять отдельно, а не включать пакетно без понимания последствий.
Для сайтов, где важна минимальная поверхность атаки и чистая техническая конфигурация, удобно держать такие настройки в одном месте и документировать, что именно отключено и почему. Это экономит время при передаче проекта другому разработчику и снижает риск случайно вернуть уязвимую функцию при очередном обновлении.