XML-RPC в WordPress до сих пор часто оставляют включенным по умолчанию, а потом удивляются лишним запросам к /xmlrpc.php, попыткам подбора паролей и странной нагрузке на сайт. Проблема не в самом файле, а в том, что он открывает отдельный канал доступа к сайту, который многим проектам уже не нужен.
Если вы не используете мобильное приложение WordPress, удаленную публикацию через внешние клиенты или старые интеграции, XML-RPC обычно проще отключить. Но делать это стоит не «на глаз», а с проверкой, чтобы не сломать нужные сценарии и не получить ложное ощущение безопасности.
Когда XML-RPC действительно мешает
Чаще всего вопрос всплывает после одного из трех симптомов: в логах много запросов к xmlrpc.php, сайт получает серию неудачных попыток входа с одного IP, либо хостинг показывает всплеск нагрузки без видимой причины. XML-RPC удобен для автоматизации, но именно поэтому его любят использовать для массовых проверок логинов и паролей.
Что проверить до отключения
Сначала убедитесь, что вы не завязаны на XML-RPC функционально. Проверьте, пользуетесь ли вы:
- мобильным приложением WordPress для публикации;
- Jetpack или похожими сервисами, которым нужен удаленный обмен данными;
- внешними редакторами и клиентами, которые работают через XML-RPC;
- старыми интеграциями, где в настройках прямо указан XML-RPC endpoint.
Если ничего из этого нет, отключение обычно безопасно. Если есть хотя бы один сценарий, лучше сначала протестировать на staging-копии или ограничить доступ на уровне сервера, а не рубить функциональность полностью.
Диагностика: как понять, что проблема именно в XML-RPC
Самый простой способ — посмотреть, идут ли запросы к /xmlrpc.php в access-логах веб-сервера. На практике это выглядит как частые POST-запросы с одинаковым URI и разными IP. Если у вас есть доступ к логам, ищите именно этот путь, а не только неудачные попытки входа в админку.
Еще один признак — нагрузка на PHP без роста обычного трафика. XML-RPC может использоваться для перебора паролей пакетами, и тогда сайт получает много однотипных запросов, которые не всегда заметны в обычной статистике посещаемости.
# Пример поиска запросов к xmlrpc.php в access.log
# Подставьте путь к своему логу
grep 'xmlrpc.php' /var/log/nginx/access.log | tail -n 50
Если вы видите регулярные POST-запросы с разных адресов, это хороший повод закрыть endpoint или хотя бы ограничить его доступ. Но прежде чем менять конфигурацию, проверьте, не используется ли XML-RPC легитимно.
Как отключить XML-RPC в WordPress
Есть несколько рабочих подходов. Выбор зависит от того, хотите ли вы просто выключить функциональность в WordPress, или еще и отрезать сам путь на уровне веб-сервера.
| Способ | Плюсы | Минусы |
|---|---|---|
| Фильтр в WordPress | Быстро, не требует правок сервера | Запросы все равно доходят до PHP |
| Правило в Nginx/Apache | Режет запросы раньше, экономит ресурсы | Нужен доступ к конфигу сервера |
| Плагин безопасности | Удобно для админов без кода | Дополнительная зависимость |
Вариант 1: отключить через код
Если нужен быстрый и понятный способ, добавьте фильтр в functions.php дочерней темы или в небольшой mu-plugin. Для продакшена mu-plugin обычно надежнее, потому что он не зависит от темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот вариант отключает XML-RPC на уровне WordPress. Если кто-то обратится к /xmlrpc.php, WordPress не будет обрабатывать запрос как рабочий API. Но сам файл на сервере останется доступен, поэтому часть нагрузки все равно может доходить до PHP.
Вариант 2: закрыть доступ на уровне Nginx
Если у вас Nginx, лучше отрезать endpoint раньше, чем он попадет в WordPress. Это особенно полезно на сайтах с большим количеством мусорного трафика.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
После изменения конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. Для Nginx это стандартная практика, и здесь не стоит полагаться на «кажется, работает».
Вариант 3: ограничить через Apache
Если сайт работает на Apache, можно закрыть файл через .htaccess. Это не так изящно, как серверное правило, но для многих проектов вполне достаточно.
<Files xmlrpc.php>
Require all denied
</Files>
Важно: если у вас смешанная инфраструктура или проксирование через CDN, проверьте, что правило реально применяется на том уровне, где проходят запросы.
Пошаговое решение без лишнего риска
- Проверьте, нужен ли XML-RPC вашим текущим интеграциям.
- Сделайте резервную копию конфигурации или хотя бы сохраните текущий фрагмент кода.
- Выберите способ: код в WordPress, правило на сервере или плагин безопасности.
- Внедрите изменение сначала на staging, если он есть.
- Проверьте ответ
/xmlrpc.phpи логи. - Убедитесь, что обычный вход в админку и публикация записей не сломались.
Если вы предпочитаете плагин, смотрите не на «красивую галочку», а на то, что именно он делает: отключает XML-RPC полностью, блокирует только pingback или просто скрывает endpoint. Для части сайтов достаточно отключить только pingback, но это не решает проблему brute force полностью.
Как проверить, что решение сработало
Проверка должна быть технической, а не визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере или через curl. Если endpoint закрыт на уровне сервера, вы должны увидеть отказ в доступе или пустой ответ в зависимости от правила. Если отключение сделано через WordPress, ответ обычно будет отличаться от рабочего XML-RPC-метода.
curl -i https://example.com/xmlrpc.php
Дополнительно проверьте логи после внедрения. Если правило на сервере работает, запросы к этому пути либо не должны попадать в PHP-логи, либо должны завершаться отказом раньше обработки WordPress. Это особенно важно на нагруженных сайтах, где экономия даже на мусорных запросах заметна.
Еще один практический тест — попробовать легитимный сценарий, если он у вас есть. Например, публикацию через внешний клиент или подключение сервиса, который использовал XML-RPC. Если такой сценарий перестал работать, значит, вы закрыли больше, чем планировали.
Частые ошибки и как их исправить
Отключили XML-RPC, но атаки не прекратились
Так бывает, если вы выключили только обработку в WordPress, но не закрыли сам endpoint на сервере. В этом случае запросы все равно будут долетать до PHP. Решение — добавить серверное правило или ограничить доступ на уровне WAF/CDN.
Сломали мобильное приложение или Jetpack
Значит, XML-RPC был нужен для реального сценария. Не пытайтесь «починить» это возвратом всего подряд. Лучше отдельно разберитесь, какой сервис использует endpoint, и либо оставьте его доступным, либо перенесите интеграцию на другой способ авторизации, если он поддерживается.
Скрыли проблему, но не устранили источник нагрузки
Иногда XML-RPC — лишь один из каналов атаки. Если на сайте слабые пароли, нет ограничения попыток входа и не обновляются плагины, закрытие одного файла не решит общую проблему безопасности. Проверьте также /wp-login.php, состояние учетных записей и актуальность ядра, тем и плагинов.
Добавили правило в неправильное место
Для Nginx правило должно попадать в активный server block, а не в абстрактный конфиг «на всякий случай». Для Apache важно, чтобы .htaccess вообще читался сервером. Если после правки ничего не изменилось, сначала проверьте, применяется ли конфигурация, а уже потом ищите ошибку в синтаксисе.
Что еще стоит сделать для безопасности
Отключение XML-RPC — это не замена базовой гигиене. На практике лучше сразу закрыть несколько типовых дыр: включить двухфакторную аутентификацию для админов, ограничить число попыток входа, убрать неиспользуемые плагины и проверить права на файлы. Если сайт регулярно получает мусорный трафик, имеет смысл смотреть и в сторону CDN или WAF, чтобы отсеивать очевидный брутфорс до PHP.
Если вы ведете сайт с помощью редакторов и не хотите вручную собирать набор технических правок, удобно держать часть чистки и SEO-оптимизации в одном инструменте. Например, Clearfy Pro помогает закрывать типовые дубли и лишние элементы, но для XML-RPC все равно лучше понимать, что именно вы отключаете и где.
В итоге рабочая схема простая: сначала выясняете, нужен ли XML-RPC, потом закрываете его на том уровне, который реально экономит ресурсы, и только после этого проверяете логи и живые сценарии. Тогда отключение не превращается в случайную поломку сайта.