XML-RPC в WordPress часто отключают по одной причине: через этот интерфейс удобно стучаться ботам, подбирать пароли и нагружать сайт лишними запросами. Но у него есть и легитимные сценарии — мобильное приложение WordPress, удалённая публикация, некоторые внешние сервисы. Поэтому задача не в том, чтобы «вырубить всё подряд», а в том, чтобы понять, нужен ли вам этот канал вообще, и если нет — закрыть его аккуратно.
Когда XML-RPC действительно стоит отключать
Если вы не используете старые внешние клиенты, не публикуете записи через сторонние приложения и не подключали сервисы, которым нужен XML-RPC, его можно отключить. На обычных сайтах этот интерфейс чаще создаёт лишнюю поверхность атаки, чем пользу. Особенно это заметно, если в логах есть частые обращения к /xmlrpc.php или попытки брутфорса через метод system.multicall.
Сценарии, где отключение обычно безопасно
- контент редактируется только из админки WordPress;
- мобильное приложение WordPress не используется;
- нет интеграций, которые отправляют записи через XML-RPC;
- сайт не синхронизируется со сторонними сервисами по старому протоколу.
Диагностика проблемы: как понять, нужен ли XML-RPC
Перед отключением проверьте, есть ли реальные обращения к файлу xmlrpc.php. Это можно увидеть в логах веб-сервера или в панели хостинга. Если логов нет, хотя бы проверьте, используете ли вы мобильное приложение WordPress или сторонние публикационные сервисы.
Быстрый тест из браузера или через curl покажет, отвечает ли endpoint сейчас:
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 200 или 405, файл доступен. Это ещё не проблема само по себе, но значит, что его можно атаковать или сканировать. Если после отключения вы видите 403 или 404, блокировка сработала.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных подхода: через код, через веб-сервер и через плагин безопасности. Я бы начинал с кода или конфигурации сервера, потому что это прозрачно и не добавляет лишней логики в админку.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль в репозитории, легко проверить | Нужно не забыть перенести при смене темы |
| Настройка веб-сервера | Блокирует запросы до WordPress | Нужен доступ к конфигу nginx/apache |
| Плагин безопасности | Быстро включить без правок кода | Лишняя зависимость, возможны конфликты |
Вариант 1. Отключить XML-RPC через фильтр
Самый простой способ — вернуть false в фильтре xmlrpc_enabled. Код можно добавить в functions.php дочерней темы или лучше в небольшой mu-plugin, чтобы он не исчез при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Но если у вас высокая нагрузка от ботов, лучше дополнительно закрыть файл на уровне сервера.
Вариант 2. Заблокировать xmlrpc.php на уровне nginx
Если сайт работает на nginx, можно отдать 403 ещё до загрузки WordPress. Это полезно, когда нужно снизить лишние обращения к PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить nginx. На практике это самый чистый вариант, если XML-RPC вам точно не нужен.
Вариант 3. Блокировка в Apache
Для Apache можно использовать правило в .htaccess. Оно не требует правок ядра WordPress и срабатывает до обработки PHP.
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через старую схему Apache 2.2, синтаксис будет другим, но на современных хостингах чаще используется именно Require all denied.
Пошаговое решение без лишнего риска
- Проверьте, используете ли вы мобильное приложение WordPress или внешнюю публикацию через XML-RPC.
- Сделайте резервную копию конфигурации или сохраните текущий
functions.php. - Добавьте отключение через
xmlrpc_enabledили правило на сервере. - Очистите кэш сайта и, если есть, CDN.
- Проверьте ответ на
/xmlrpc.phpчерезcurlили браузер. - Посмотрите логи в течение нескольких часов: не появились ли ошибки у интеграций.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте https://example.com/xmlrpc.php и убедитесь, что сервер больше не отдаёт рабочую страницу или стандартный ответ WordPress. Затем выполните запрос:
curl -I https://example.com/xmlrpc.phpОжидаемый результат после блокировки — 403 Forbidden или 404 Not Found. Если у вас стоит фильтр WordPress, а сервер всё ещё отдаёт 200, значит, запрос доходит до PHP, и лучше закрыть его ещё и на уровне nginx или Apache.
Дополнительно проверьте админку и публикацию записей. Если вы не используете XML-RPC, никаких изменений в обычной работе сайта быть не должно.
Частые ошибки и как их исправить
Отключили XML-RPC, а мобильное приложение перестало публиковать записи
Это ожидаемо. Если приложение реально нужно, не блокируйте endpoint полностью. Тогда придётся искать альтернативу: ограничить доступ по IP, закрыть только опасные методы или использовать более современный способ интеграции.
Добавили код в активную тему и забыли про него
При смене темы отключение исчезнет. Для технических правок лучше использовать mu-plugin или отдельный мини-плагин. Так настройка не зависит от дизайна.
Поставили плагин безопасности, но XML-RPC всё ещё доступен
У некоторых плагинов отключение работает только частично: они блокируют отдельные методы, но не сам файл. Проверьте ответ сервера напрямую. Если endpoint живой, добавьте правило в конфиг веб-сервера.
Сломали интеграцию, которая использовала XML-RPC скрыто
Такое бывает со старыми сервисами автопостинга и синхронизации. Перед блокировкой посмотрите, кто обращается к /xmlrpc.php в логах. Если там есть реальный клиент, сначала переведите его на REST API или другой поддерживаемый способ.
Что ещё стоит сделать для безопасности
Отключение XML-RPC не заменяет базовую защиту. Если сайт регулярно сканируют, проверьте и другие точки входа: ограничение попыток входа, двухфакторную аутентификацию для админов, актуальные версии ядра и плагинов. Если у вас есть плагин вроде Clearfy Pro, его имеет смысл рассматривать не как «волшебную кнопку», а как набор точечных настроек для удаления лишних поверхностей и дублей. Но даже в этом случае серверное правило против xmlrpc.php остаётся самым надёжным вариантом.
Практический ориентир простой: если XML-RPC вам не нужен, закройте его на сервере, проверьте ответ через curl и убедитесь, что ни одна рабочая интеграция не пострадала. Если нужен — не отключайте вслепую, а сначала найдите конкретный сценарий использования.