XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации или старые интеграции. На практике задача не в том, чтобы просто закрыть /xmlrpc.php, а в том, чтобы понять, нужен ли он вообще, и если нужен — ограничить доступ аккуратно.
Ниже разберём рабочие способы: через код, через сервер и через плагин, а также как проверить результат и не сломать то, что ещё зависит от XML-RPC.
Когда XML-RPC мешает, а когда он ещё нужен
XML-RPC — это старый интерфейс WordPress для удалённого доступа. Его используют не только злоумышленники для перебора паролей, но и вполне легитимные клиенты: некоторые мобильные приложения, внешние сервисы публикации, старые интеграции с редакторами и автоматизацией. Если сайт давно работает только через админку и REST API, XML-RPC чаще всего не нужен.
Отключать его стоит, если вы видите хотя бы один из сценариев:
- в логах много запросов к
/xmlrpc.php; - на сайте идут попытки brute force через
system.multicall; - интеграции переведены на REST API или прямую работу с админкой;
- вам не нужен удалённый постинг через старые клиенты.
Если у вас есть мобильное приложение WordPress, сторонний сервис публикации или старая синхронизация контента, сначала проверьте, использует ли она XML-RPC. Иначе можно получить «тихую» поломку без явной ошибки на сайте.
Диагностика: как понять, используется ли xmlrpc.php
Перед отключением полезно посмотреть, есть ли реальные обращения к файлу. Самый простой путь — логи веб-сервера. Если доступа к логам нет, можно временно включить мониторинг на уровне плагина безопасности или проверить статистику запросов в панели хостинга.
Что искать в логах
Ищите строки с /xmlrpc.php. Если видите много однотипных запросов с разных IP, это типичная атака на авторизацию. Если запросы редкие и идут от понятных сервисов, сначала разберитесь, кто их делает.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Для Apache путь к логам может отличаться, но логика та же: смотрим частоту, IP и user-agent. Если запросы идут постоянно, а полезной нагрузки от XML-RPC вы не используете, отключение оправдано.
Проверка зависимостей на стороне сайта
Проверьте, не завязаны ли на XML-RPC внешние инструменты:
- мобильное приложение WordPress;
- автопостинг из сторонних сервисов;
- интеграции старых CMS и редакторов;
- скрипты, которые обращаются к
xmlrpc.phpнапрямую.
Если сомневаетесь, сначала отключите доступ только для внешнего мира, а не удаляйте поддержку на уровне WordPress. Это безопаснее для диагностики.
Как отключить XML-RPC через код
Если нужен предсказуемый вариант без лишних плагинов, проще всего добавить фильтр в functions.php дочерней темы или в собственный mu-plugin. Это не удаляет файл физически, но блокирует обработку запросов WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ хорош тем, что его легко откатить. Но есть нюанс: сам файл xmlrpc.php остаётся доступен на уровне веб-сервера, и бот всё равно будет стучаться в него. Для снижения нагрузки и шума лучше дополнить блокировкой на сервере.
Блокировка на уровне Nginx
Если сайт работает на Nginx, можно закрыть доступ к файлу ещё до передачи запроса в PHP. Это снижает нагрузку и убирает лишние обращения к WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После правки конфигурации не забудьте проверить синтаксис и перезагрузить сервер. На shared-хостинге такой доступ может быть недоступен, тогда остаётся вариант с кодом или плагином.
Блокировка на уровне Apache
Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста. Важно не смешивать это с общими правилами WordPress, чтобы не сломать остальной сайт.
<Files "xmlrpc.php">
Require all denied
</Files>Если у вас старый стек с Apache 2.2, синтаксис может отличаться, но на актуальных версиях используется именно Require all denied.
Плагин или код: что выбрать на практике
Если на сайте уже есть плагин безопасности или оптимизации, иногда проще включить блокировку там. Но если задача точечная, код или серверное правило обычно надёжнее и прозрачнее.
| Способ | Плюсы | Минусы |
|---|---|---|
Код через xmlrpc_enabled | Быстро, просто откатить | Не режет запросы на уровне сервера |
| Nginx/Apache | Ранний отказ, меньше нагрузки | Нужен доступ к конфигу |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость, иногда дублирует другие правила |
Если вы уже используете Clearfy Pro для технической чистки сайта, имеет смысл проверить, не закрывает ли он XML-RPC вместе с другими лишними функциями. Но не включайте несколько одинаковых блокировок сразу, иначе потом сложнее понять, что именно сработало.
Пошаговое решение без лишнего риска
- Проверьте, используются ли интеграции, завязанные на XML-RPC.
- Сделайте резервную копию конфигурации и файлов темы.
- Сначала добавьте фильтр
xmlrpc_enabledили правило на сервере. - Проверьте, не сломались ли внешние публикации и мобильные клиенты.
- Если всё ок, оставьте блокировку и наблюдайте за логами 1–2 дня.
Если сайт под атакой, лучше начинать с серверной блокировки. Если задача — просто убрать поддержку без доступа к конфигу, достаточно фильтра в WordPress.
Как проверить, что XML-RPC действительно отключён
Проверка нужна не только на уровне интерфейса, но и на уровне ответа сервера. Откройте https://ваш-домен/xmlrpc.php в браузере или выполните запрос через curl. В норме вы не должны получать рабочий ответ WordPress на методы XML-RPC.
curl -I https://example.com/xmlrpc.phpЕсли блокировка сделана через Nginx или Apache, вы увидите 403 Forbidden или другой отказ, зависящий от конфигурации. Если отключали только фильтром WordPress, файл может отвечать, но методы будут недоступны. Это не ошибка, но такой вариант слабее с точки зрения защиты.
Дополнительно проверьте:
- мобильное приложение WordPress не теряет связь с сайтом;
- внешние сервисы публикации не перестали отправлять записи;
- в логах больше нет успешных обращений к
xmlrpc.php; - в админке не появилось ошибок авторизации, связанных с интеграциями.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать сервис публикации
Значит, сервис действительно использовал XML-RPC. Решение — либо вернуть доступ, либо перевести интеграцию на REST API, если сервис это поддерживает. Не стоит держать открытый XML-RPC только ради одного старого инструмента, если есть современная альтернатива.
Поставили сразу несколько блокировок и не понимаете, что сломалось
Так бывает, когда одновременно включают плагин безопасности, правило в .htaccess и фильтр в теме. Уберите лишнее и оставьте один понятный способ. Для диагностики лучше временно отключать по одному уровню защиты.
Файл отвечает 200 OK, хотя вы «всё отключили»
Это значит, что вы закрыли только обработку в WordPress, но не сам доступ к файлу. Если нужен именно отказ на уровне сервера, добавьте правило в Nginx или Apache.
Сломали сайт правкой в основной теме
Фильтры и служебный код не стоит писать в родительскую тему. Используйте дочернюю тему или mu-plugin, иначе обновление темы затрёт изменения.
Что учесть для безопасности и производительности
Если цель — снизить поверхность атаки, блокировка XML-RPC полезна, но не заменяет базовую гигиену: обновления ядра, тем и плагинов, ограничение попыток входа, нормальные пароли и двухфакторную аутентификацию для админов. XML-RPC часто используют как точку входа именно потому, что на слабых сайтах он остаётся открытым без необходимости.
С точки зрения производительности серверная блокировка лучше, чем только фильтр WordPress: запросы от ботов отсекаются раньше и не нагружают PHP. На сайтах с большим количеством мусорного трафика это заметно по логам, даже если пользовательский фронтенд не меняется.
Если вам нужен не только этот точечный фикс, а более широкая техническая чистка сайта, имеет смысл посмотреть на инструменты уровня Clearfy Pro: там удобно закрывать лишние функции и убирать ненужные элементы без ручного разбрасывания кода по теме. Но для одной задачи отдельное правило часто проще и надёжнее.
В итоге рабочая схема такая: сначала выясняете, нужен ли XML-RPC, потом выбираете уровень блокировки, а после внедрения проверяете не только код ответа, но и реальные интеграции. Это экономит время и избавляет от ситуации, когда защита включена, а сайт при этом тихо теряет полезный функционал.