XML-RPC в WordPress часто отключают ради безопасности и снижения лишних точек входа, но на живом сайте это не всегда можно сделать «в лоб». Проблема в том, что через этот интерфейс до сих пор работают некоторые внешние клиенты, мобильные приложения и старые интеграции. Если просто закрыть доступ без проверки, можно неожиданно сломать публикацию из стороннего сервиса или синхронизацию контента.
Ниже — рабочая схема: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без лишнего риска и как проверить, что ничего важного не отвалилось.
Когда XML-RPC действительно можно отключать
Если сайт не использует внешние приложения для публикации, не подключён к старым сервисам автопостинга и не работает с клиентами, которым нужен удалённый доступ к WordPress, XML-RPC обычно можно убрать. На большинстве современных проектов он не нужен, а лишний открытый endpoint только увеличивает поверхность атаки.
Но перед изменениями стоит проверить не «вообще нужен ли он», а конкретно какие интеграции завязаны на него. Особенно это касается:
- мобильного приложения WordPress;
- старых десктопных клиентов для публикации;
- сервисов автопостинга и синхронизации;
- некоторых внешних редакторов и CMS-мостов;
- плагинов, которые используют удалённую публикацию через XML-RPC.
Диагностика: как понять, используется ли XML-RPC сейчас
Самый практичный способ — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в логах безопасности. Если запросы идут регулярно, значит endpoint кто-то использует, и отключать его без проверки не стоит.
Что искать в логах
В access-логах Nginx или Apache ищите запросы к /xmlrpc.php. Если видите только редкие попытки брутфорса — это хороший знак. Если есть нормальные POST-запросы с рабочими кодами ответа, сначала разберитесь, кто их делает.
# Nginx access log: поиск обращений к XML-RPC
grep 'xmlrpc.php' /var/log/nginx/access.log
# Apache access log
grep 'xmlrpc.php' /var/log/apache2/access.logЕсли у вас включён плагин безопасности, проверьте его журнал. Но не полагайтесь только на него: плагины часто показывают блокировки, а не реальную картину использования.
Пошаговое отключение XML-RPC
Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Для большинства сайтов удобнее код или плагин, а серверный уровень имеет смысл, если вы хотите отрубить доступ ещё до загрузки WordPress.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро, без правки кода | Лишняя зависимость, не всегда прозрачно что именно блокируется |
| Код в теме или mu-plugin | Контроль, минимальная логика | Нужно аккуратно вносить изменения |
| Правило на сервере | Режет запросы раньше WordPress | Нужен доступ к конфигу сервера, легко ошибиться |
Вариант 1: отключить через код
Добавьте код в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой вариант: WordPress перестаёт отвечать на XML-RPC-запросы, но сам файл xmlrpc.php физически остаётся доступен. Для большинства проектов этого достаточно.
Вариант 2: заблокировать доступ на уровне Nginx
Если сайт под постоянным перебором паролей или вы хотите закрыть endpoint до WordPress, можно добавить правило в конфиг Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Это уже серверная настройка, поэтому делайте её только если понимаете, где именно лежит конфиг сайта.
nginx -t
systemctl reload nginxВариант 3: использовать плагин
Если вы не хотите трогать код, подойдёт плагин безопасности с точечной блокировкой XML-RPC. Это удобно для админов без доступа к серверу, но важно понимать, что плагин добавляет ещё один слой логики и иногда конфликтует с другими защитными модулями.
Если на сайте уже есть набор SEO- и cleanup-настроек, имеет смысл смотреть в сторону комплексных решений вроде Clearfy Pro: там удобно собирать техническую чистку в одном месте, не распыляя настройки по нескольким плагинам. Но даже в этом случае проверьте, что именно включено, а не ставьте всё подряд.
Как проверить, что отключение сработало
Проверка должна быть не «страница открылась», а именно по endpoint'у XML-RPC. Самый простой тест — отправить запрос к /xmlrpc.php и посмотреть ответ.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки. Если вы отключили XML-RPC через фильтр WordPress, сервер может вернуть стандартную страницу или ошибку доступа в зависимости от конфигурации. Если закрывали на уровне Nginx, обычно будет 403 Forbidden.
Дополнительно проверьте:
- вход в админку WordPress работает;
- публикация записей из самого WordPress не сломана;
- внешние сервисы, если они были, не теряют соединение;
- в логах больше нет успешных запросов к
/xmlrpc.php.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестало публиковаться из мобильного приложения
Значит, приложение реально использовало XML-RPC. Решение простое: либо вернуть доступ, либо перевести процесс публикации на другой инструмент. Не пытайтесь «починить» это через частичные исключения, если не понимаете, какой именно клиент ходит на endpoint.
Поставили плагин блокировки и получили конфликт с защитой входа
Некоторые security-плагины дублируют друг друга: один блокирует XML-RPC, второй пытается отслеживать те же запросы, третий добавляет rate limit. В итоге можно получить ложные срабатывания или лишнюю нагрузку. Если уже есть основной security-слой, не включайте дублирующую функцию без необходимости.
Скрыли проблему, но не убрали источник атак
Если в логах видно массовые запросы к /xmlrpc.php, одного отключения мало. Проверьте парольную политику, ограничение попыток входа и базовую защиту админки. XML-RPC часто атакуют не сам по себе, а как часть общей автоматизированной атаки на WordPress.
Что делать, если XML-RPC нужен частично
Иногда endpoint нужен только для одного сервиса, а всё остальное лучше закрыть. В таком случае безопаснее не держать XML-RPC открытым для всех, а пересмотреть сам сценарий интеграции. Если сервис поддерживает REST API или OAuth-авторизацию, лучше перейти на них. Если нет — оставьте XML-RPC включённым только после проверки, что риск оправдан.
Для сайтов, где важна чистота технической части и контроль над лишними возможностями, полезно держать такие настройки в одном месте и документировать, зачем они включены. Это особенно важно, если проект ведут несколько человек и через полгода никто уже не помнит, почему endpoint оставили открытым.
Практические советы по безопасности и производительности
- Если XML-RPC не нужен, отключайте его кодом или на сервере, а не только «прячьте» в плагине.
- Проверяйте логи до и после изменения, иначе можно не заметить рабочую интеграцию.
- Не ставьте несколько плагинов, которые делают одно и то же ограничение.
- Если у сайта есть внешние сервисы публикации, сначала тестируйте на staging-копии.
- После отключения проверьте не только endpoint, но и сценарии входа, публикации и обновления контента.
Если нужен более широкий технический аудит WordPress — от дублей и мусорных запросов до лишних функций в админке — удобно держать под рукой инструменты вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но в любом случае сначала определите, что именно вы отключаете и зачем, а потом уже автоматизируйте.