XML-RPC в WordPress до сих пор встречается на живых сайтах, хотя большинству проектов он уже не нужен. Обычно его отключают из-за лишней поверхности атаки, брутфорса через xmlrpc.php или просто потому, что сайт не использует старые внешние клиенты, Jetpack-сценарии или мобильные приложения WordPress. Но выключать его «в лоб» опасно: можно неожиданно сломать публикацию через сторонний сервис, интеграцию с приложением или часть плагинов.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вам, как отключить его без лишних рисков и как проверить результат после внедрения.
Когда XML-RPC действительно можно отключать
Если сайт управляется только через wp-admin, а внешние сервисы не публикуют записи и не синхронизируют данные через XML-RPC, этот интерфейс обычно можно закрыть. Для большинства современных проектов достаточно REST API и обычной админки.
Перед изменениями проверьте, есть ли у вас зависимости:
- Jetpack, если он использует старые механизмы связи с сайтом;
- мобильные приложения WordPress, если ими реально пользуются;
- внешние редакторы и сервисы автопостинга;
- старые интеграции, которые отправляют запросы на
/xmlrpc.php; - плагины резервного копирования или мониторинга, если они настроены нетипично.
Диагностика: как понять, используется ли xmlrpc.php
Самый практичный способ — посмотреть логи веб-сервера и события безопасности. Если по xmlrpc.php идут регулярные запросы, но вы не видите легитимных обращений от своих сервисов, это хороший кандидат на отключение.
Что искать в access log
Ищите повторяющиеся POST-запросы к /xmlrpc.php, особенно с одинаковых IP или с большим количеством неудачных попыток авторизации. На nginx это обычно видно в access log, на Apache — в аналогичном журнале.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас есть WAF, fail2ban или плагин безопасности, проверьте, не завязан ли он на блокировку XML-RPC-атак. Иногда отключение самого файла не нужно, если атаки уже эффективно режутся на уровне сервера. Но если запросы просто доходят до WordPress, лучше закрыть точку входа.
Сравнение подходов: плагин, код или сервер
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Если нужен быстрый переключатель без правки кода | Просто включить, часто есть журнал событий | Лишняя зависимость, не всегда точный контроль |
| Код в теме или mu-plugin | Если нужен предсказуемый результат и контроль в репозитории | Минимум накладных расходов, легко ревьюить | Нужно аккуратно выбрать место размещения |
| Ограничение на сервере | Если хотите отсечь запросы до WordPress | Меньше нагрузки, запросы не доходят до PHP | Нужен доступ к конфигу nginx/Apache |
Пошаговое решение: отключаем XML-RPC через код
Если нужен управляемый вариант без плагинов, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Для production-сайта mu-plugin надежнее: он не зависит от активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
* Description: Отключает XML-RPC на сайте.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC, но файл xmlrpc.php может продолжать отвечать с ошибкой или заголовком, в зависимости от окружения. Для большинства сайтов этого достаточно, если цель — убрать функциональность WordPress.
Если нужно закрыть доступ точечно
Иногда удобнее не ломать поведение WordPress целиком, а просто запретить доступ к файлу на уровне сервера. Это полезно, если вы хотите уменьшить количество запросов еще до запуска PHP.
Для 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 в браузере или выполните запрос из терминала. Поведение зависит от способа блокировки, но главное — не должно быть доступного XML-RPC-ответа с рабочими методами.
curl -I https://example.com/xmlrpc.phpЧто считать нормой:
- при серверной блокировке —
403 Forbidden; - при отключении через WordPress — отсутствие доступного XML-RPC-функционала;
- в логах больше не появляются успешные обращения к XML-RPC;
- внешние сервисы, которые вы тестировали, не могут авторизоваться через этот канал.
После этого проверьте критичные сценарии вручную:
- вход в админку;
- публикацию и обновление записей;
- работу REST API, если он используется интеграциями;
- связанные плагины, особенно Jetpack и инструменты автопостинга.
Частые ошибки и как их исправить
Отключили XML-RPC, а сломалась внешняя публикация
Значит, у вас был живой клиент или интеграция, о которой забыли. Решение простое: вернуть доступ, найти источник запросов в логах и либо перевести интеграцию на REST API, либо оставить XML-RPC только для нужного IP через серверные правила.
Поставили блокировку в теме, а потом сменили тему
Если код лежит в functions.php, он исчезнет при смене темы. Для системного ограничения используйте mu-plugin или серверную настройку.
Закрыли файл на сервере, но не проверили логи
Иногда боты продолжают долбить в xmlrpc.php, и вы не видите, что атаки просто стали 403. Это нормально, но полезно убедиться, что правила не создают лишнюю нагрузку и не маскируют реальные ошибки.
Отключили все подряд через плагин безопасности
Некоторые плагины умеют отключать XML-RPC вместе с другими функциями, которые вам еще нужны. Перед включением проверьте, что именно меняет настройка, и не полагайтесь на название опции без теста.
Практические советы по безопасности и производительности
Если сайт не использует XML-RPC, лучше закрыть его на уровне сервера и дополнительно отключить в WordPress. Это уменьшает число бесполезных запросов и убирает лишнюю точку атаки. Но не стоит делать из этого «магическую кнопку безопасности»: основная защита все равно строится на обновлениях, сильных паролях, ограничении попыток входа и нормальной настройке ролей.
Если вы ведете несколько сайтов, удобно держать такие изменения в маленьком mu-plugin или в конфигурации сервера, а не в разрозненных правках темы. Так проще понять, что именно включено на каждом проекте, и быстрее откатить изменение, если появится зависимость.
Если вам нужно регулярно чистить сайт от дублей, мусора и лишних технических настроек, такие задачи удобно держать в одном чек-листе администрирования. В экосистеме WPShop для этого есть Clearfy Pro: он закрывает часть типовых технических правок, связанных с SEO и чисткой сайта, но использовать его стоит только там, где это реально нужно, а не «на всякий случай».
Короткий чек-лист перед отключением
- Проверить логи на обращения к
/xmlrpc.php. - Убедиться, что нет активных внешних клиентов и автопостинга.
- Выбрать способ: код, сервер или плагин.
- Сделать изменение в mu-plugin или конфиге, а не в случайной теме.
- Проверить
curl -Iи ручные сценарии после внедрения. - Посмотреть, не сломались ли связанные интеграции и уведомления.
Если XML-RPC на сайте не нужен, его отключение — одна из тех технических правок, которые дают понятный эффект без сложной архитектуры. Главное здесь не сам факт блокировки, а аккуратная проверка зависимостей до и после изменения.