XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, перебору паролей и странным обращениям к /xmlrpc.php. На практике это не обязательный компонент для большинства сайтов, но отключать его вслепую тоже не стоит: иногда через него работают старые мобильные клиенты, внешние сервисы публикации и некоторые интеграции.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без побочных эффектов и чем проверить результат после внедрения.
Когда XML-RPC действительно мешает
Сам по себе файл xmlrpc.php не является уязвимостью, но он часто становится точкой входа для брутфорса и массовых запросов. Если сайт не использует удалённую публикацию, pingback’и и старые внешние клиенты, держать этот интерфейс открытым обычно нет смысла.
Типичные признаки, что XML-RPC вам не нужен:
- вы публикуете записи только из админки WordPress;
- нет подключённых мобильных приложений и внешних редакторов;
- не используете Jetpack-функции, завязанные на XML-RPC;
- в логах сервера регулярно видны запросы к
/xmlrpc.phpс ошибками авторизации; - на хостинге растёт нагрузка из-за повторяющихся POST-запросов к этому файлу.
Что обычно ломается при отключении
Чаще всего страдают не «обычные» функции сайта, а внешние сценарии: публикация через старые приложения, удалённые команды для блогов, некоторые сервисы автопостинга. Если у вас есть интеграции, которые вы настраивали давно и уже не помните, сначала проверьте их список, а потом меняйте поведение.
Диагностика: используется ли XML-RPC сейчас
Перед отключением полезно быстро проверить, есть ли реальные обращения к этому интерфейсу. Самый простой путь — посмотреть access log веб-сервера или логи в панели хостинга. Ищите строки с /xmlrpc.php.
Если есть доступ к серверу, можно отфильтровать обращения так:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет, проверьте косвенно:
- включён ли Jetpack и какие его модули используются;
- есть ли сторонние сервисы автопубликации;
- используются ли мобильные приложения WordPress для публикации;
- есть ли в коде темы или плагинов вызовы, связанные с XML-RPC.
Для быстрой проверки снаружи можно отправить тестовый запрос. Если XML-RPC активен, WordPress обычно отвечает сообщением об ошибке метода, а не 404:
curl -I https://example.com/xmlrpc.phpЭто не полноценная диагностика использования, но она помогает понять, доступен ли endpoint вообще.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вы хотите контролировать поведение: в коде, на уровне плагина или на уровне сервера. Если нужен управляемый и предсказуемый вариант, лучше начинать с кода или правила веб-сервера, а не с «тяжёлых» универсальных плагинов.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Код в functions.php или MU-плагине | Просто, прозрачно, легко откатить | Не сработает, если тема сменится и код потеряется | Если нужен быстрый и понятный контроль |
| Правило на уровне Nginx/Apache | Запросы режутся до WordPress | Нужен доступ к конфигу сервера | Если важна защита от лишней нагрузки |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость, иногда больше функций, чем нужно | Если уже используете security-плагин |
Вариант 1: отключить через код
Если вам нужен понятный и обратимый способ, добавьте фильтр xmlrpc_enabled. Лучше размещать его в MU-плагине, чтобы он не зависел от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если MU-плагинов у вас нет, можно создать файл, например wp-content/mu-plugins/disable-xmlrpc.php. Папка mu-plugins должна существовать. Такой файл WordPress подхватывает автоматически.
Вариант 2: закрыть доступ на уровне сервера
Этот способ полезен, если вы хотите не просто отключить XML-RPC внутри WordPress, а вообще не отдавать запросы на этот файл. Для Nginx можно добавить отдельное правило:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Такой подход особенно полезен на сайтах с заметным фоновым трафиком к xmlrpc.php: запросы отсекаются раньше, чем WordPress начнёт загружаться.
Вариант 3: отключить через плагин безопасности
Если у вас уже стоит плагин, который умеет закрывать XML-RPC, можно использовать его настройки. Но не стоит ставить отдельный плагин только ради одной галочки, если задача решается одной строкой кода или правилом сервера. Лишний плагин — это ещё одна точка обновления и ещё один слой, который может конфликтовать с кэшем или WAF.
Если вы используете комплексную чистку и оптимизацию сайта, имеет смысл посмотреть и на инструменты, которые помогают убрать лишние системные сущности WordPress, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и в этом случае сначала проверьте, не нужен ли вам XML-RPC для конкретной интеграции.
Пошаговое решение без сюрпризов
- Проверьте логи и список интеграций, которые могут использовать XML-RPC.
- Если зависимостей нет, выберите один способ отключения: код или серверное правило.
- Внесите изменение на staging, а не сразу на боевом сайте.
- Проверьте, что сайт открывается, а
/xmlrpc.phpбольше не отвечает как раньше. - Посмотрите логи ещё раз: новые обращения должны либо исчезнуть, либо получать отказ.
Если вы отключаете через код, лучше не править functions.php активной темы. При обновлении темы изменение легко потерять. MU-плагин здесь надёжнее.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужны минимум три шага: ответ endpoint, логи и функциональные тесты.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт или поведение изменилось согласно выбранному способу. - Проверьте access log: новых запросов к этому файлу не должно быть, либо они должны получать отказ на уровне сервера.
- Если у вас есть внешняя интеграция, которая могла зависеть от XML-RPC, выполните её тестовый сценарий вручную.
Для более точной проверки можно отправить POST-запрос и посмотреть код ответа:
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/xmlrpc.phpЕсли вы закрывали endpoint на уровне сервера, ожидаемым результатом обычно будет 403 или 404 в зависимости от конфигурации. Если отключали через фильтр WordPress, поведение может отличаться, но endpoint не должен работать как раньше.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина почти всегда в том, что Jetpack использовал XML-RPC для части функций. Решение простое: проверьте, какие модули Jetpack реально нужны, и не отключайте XML-RPC, пока не убедитесь, что они не завязаны на него. Иногда лучше закрыть endpoint на уровне WAF или ограничить доступ, а не рубить полностью.
Сделали правку в теме и потеряли её после обновления
Это классическая ошибка. Для системных ограничений используйте MU-плагин или серверную конфигурацию. Тема не должна быть местом для таких изменений.
Поставили плагин, который отключает слишком много
Некоторые security-плагины не только блокируют XML-RPC, но и меняют поведение REST API, логина или заголовков. Если после установки появились проблемы с авторизацией или интеграциями, временно отключите плагин и проверьте, что именно он меняет.
Закрыли endpoint, но нагрузка не упала
Если запросы продолжают идти, возможно, их режет не WordPress, а внешний бот, и сервер всё равно тратит ресурсы на обработку до момента отказа. В таком случае лучше перенести блокировку на уровень Nginx/Apache или подключить WAF.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC — это только один шаг. Если вы уже чистите поверхность атаки, проверьте и другие лишние точки входа: неиспользуемые плагины, старые учётные записи, открытые endpoint’ы REST API для лишних типов данных, публичные pingback’и. Но не смешивайте всё в одну правку без теста: так сложнее понять, что именно сломалось.
Практичный минимум после отключения XML-RPC:
- обновить ядро, тему и плагины;
- убедиться, что включён HTTPS;
- проверить права доступа к файлам;
- смотреть логи авторизации и 403/404 по подозрительным запросам;
- убрать неиспользуемые плагины и темы.
Если сайт работает на высокой нагрузке, блокировка XML-RPC на уровне сервера обычно предпочтительнее: она снижает лишние обращения ещё до запуска PHP. Это не заменяет нормальную защиту, но помогает убрать один из самых шумных каналов атак.