XML-RPC в WordPress часто оставляют включённым по привычке, а потом удивляются лишним запросам к /xmlrpc.php, попыткам подбора паролей и шуму в логах. Если вы не используете мобильное приложение WordPress, Jetpack, внешние публикации или старые интеграции, этот интерфейс обычно можно отключить без потери функциональности сайта.
Ниже — рабочая схема: как понять, нужен ли XML-RPC именно вам, как отключить его безопасно, чем проверить результат и где чаще всего ломают сайт при попытке «закрыть всё сразу».
Когда XML-RPC реально нужен, а когда его можно выключать
XML-RPC — это не «лишний файл», а отдельная точка входа для удалённых запросов. Исторически через неё работали мобильные клиенты, публикация через внешние редакторы и часть плагинов. Сейчас в большинстве проектов она не нужна, потому что админка, REST API и современные интеграции закрывают те же задачи.
Оставлять включённым стоит, если
- вы публикуете записи из мобильного приложения WordPress;
- используете Jetpack и у вас есть функции, завязанные на XML-RPC;
- есть внешняя система, которая отправляет посты через XML-RPC, и вы это точно проверили;
- старый рабочий процесс в редакции ещё зависит от этого интерфейса.
Отключать можно, если
- сайт управляется только через wp-admin;
- нет мобильной публикации и внешних клиентов;
- в логах видны регулярные обращения к
/xmlrpc.phpс попытками brute-force; - нужно уменьшить поверхность атаки без вмешательства в контент и тему.
Диагностика: как понять, что XML-RPC действительно используется
Перед отключением не полагайтесь на предположение «у нас это точно не нужно». Сначала проверьте факты. Самый простой путь — посмотреть логи веб-сервера и список активных интеграций.
Что проверить в первую очередь
- логи доступа Nginx или Apache на обращения к
/xmlrpc.php; - активные плагины, которые могут использовать удалённую публикацию;
- наличие мобильного приложения WordPress у редакторов;
- подключён ли Jetpack и какие его модули реально используются.
Если доступа к логам нет, можно временно проверить сам endpoint снаружи. При включённом XML-RPC сервер обычно отвечает не как обычная страница, а отдельным сообщением сервиса. При отключении — отдаёт 403, 404 или блокируется на уровне сервера.
curl -I https://example.com/xmlrpc.phpЭтот запрос не доказывает, что XML-RPC используется, но показывает, доступен ли endpoint извне. Если он открыт, а вам он не нужен, это уже повод закрыть его.
Как отключить XML-RPC: сравнение подходов
Есть три практических варианта: плагин, код в functions.php или блокировка на уровне сервера. Для большинства сайтов достаточно кода или плагина. Серверный вариант хорош, если вы хотите отсечь запросы раньше, чем они дойдут до WordPress.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правки темы | Лишняя зависимость, не всегда нужен отдельный плагин | Если нет доступа к коду или нужен временный тест |
| Код в теме / mu-plugin | Контроль, минимум накладных расходов | Нужно аккуратно разместить код | Если вы управляете сайтом как разработчик |
| Блокировка на сервере | Режет запросы до WordPress | Нужен доступ к конфигу сервера | Если есть высокий поток мусорных запросов |
Пошаговое решение через код
Если вы не хотите ставить отдельный плагин, удобнее всего отключить XML-RPC через небольшой сниппет. Для постоянного сайта лучше положить его в mu-plugins, а не в тему: так код не исчезнет после смены шаблона.
Вариант 1: полностью отключить XML-RPC
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый прямой способ. WordPress перестанет принимать XML-RPC-запросы на уровне ядра.
Вариант 2: заблокировать доступ к xmlrpc.php на уровне WordPress
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Этот вариант полезен, если вам нужно явно отдавать 403 и не пускать запрос дальше. Но для большинства случаев достаточно фильтра xmlrpc_enabled.
Вариант 3: блокировка через сервер
Если у вас Nginx, можно закрыть доступ к файлу на уровне конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка особенно полезна, если сайт постоянно получает брутфорс по XML-RPC и вы хотите снизить нагрузку ещё до запуска WordPress.
Проверка результата после внедрения
После отключения не ограничивайтесь «страница открывается». Нужно проверить именно тот сценарий, который вы закрывали.
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт. - Проверьте логи сервера: запросы должны либо не доходить до WordPress, либо получать отказ.
- Если использовали плагин или код, убедитесь, что обычная авторизация в админке и публикация записей работают как раньше.
- Если на сайте есть Jetpack или мобильные клиенты, протестируйте их отдельно до полного отключения.
Полезно также проверить, не осталось ли в панели безопасности предупреждений о доступном XML-RPC. Некоторые плагины показывают это как отдельный пункт в отчётах.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо, если Jetpack использовал удалённые функции через XML-RPC. Решение простое: либо вернуть доступ, либо отказаться от этого сценария и проверить, можно ли заменить его REST API или встроенными функциями плагина.
Добавили код в тему и потеряли защиту после обновления
Если сниппет лежал в functions.php активной темы, при смене темы он исчезнет. Для системных ограничений лучше использовать mu-plugins или отдельный мини-плагин.
Закрыли файл на сервере, но запросы всё равно видны в логах
Это не ошибка блокировки как таковой: запросы всё ещё приходят на сервер, но отсекаются раньше WordPress. Если цель — убрать шум из логов, дополнительно настройте правила на уровне WAF или ограничение по IP, если это уместно.
Сломали мобильную публикацию у редакторов
Перед отключением проверьте, кто реально публикует контент и какими инструментами. Если редакция работает через мобильное приложение WordPress, отключение XML-RPC без замены сценария приведёт к сбою рабочего процесса.
Безопасность и производительность: что ещё имеет смысл сделать рядом
Отключение XML-RPC не заменяет нормальную защиту входа. Если на сайте идут атаки на авторизацию, проверьте ещё несколько вещей:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальные версии ядра, темы и плагинов;
- отсутствие лишних учётных записей с правами администратора;
- корректные правила кеша и исключения для
/wp-admin/и/wp-login.php.
Если вы уже чистите сайт от лишних служебных точек входа, иногда удобно собрать это в один набор настроек. Например, в Clearfy Pro есть функции для отключения части служебного мусора и упрощения технической гигиены сайта; это не обязательное решение, но как централизованный инструмент может быть удобнее разрозненных сниппетов. Ссылка: Clearfy Pro.
Короткий чек-лист перед публикацией изменений
- Проверили, нужен ли XML-RPC конкретно вашему сайту.
- Выбрали способ отключения: код, сервер или плагин.
- Сохранили резервную копию конфигурации перед правками.
- Проверили доступ к
/xmlrpc.phpпосле изменения. - Тестировали Jetpack, мобильные клиенты и внешние интеграции, если они есть.
- Посмотрели логи и убедились, что атаки не доходят до WordPress.
Если задача была именно в снижении brute-force и мусорных запросов, после этой настройки вы должны увидеть не «магическое ускорение», а более чистые логи и меньшую поверхность атаки. Это и есть нормальный результат для такого изменения.