XML-RPC в WordPress часто нужен только в редких сценариях: старые мобильные клиенты, внешние сервисы публикации, некоторые интеграции. Если вы этим не пользуетесь, endpoint /xmlrpc.php становится лишней точкой входа для перебора паролей и шумных запросов. Отключать его стоит не «на всякий случай», а когда вы точно понимаете, что сайт не зависит от этого механизма.
Ниже — рабочие способы отключить XML-RPC без плагинов, как проверить, что всё действительно выключилось, и что делать, если после правки что-то сломалось.
Когда XML-RPC лучше отключить
На обычном корпоративном сайте, блоге или лендинге XML-RPC чаще всего не используется. Если вы входите в админку через браузер, публикуете записи вручную и не подключали внешние клиенты, endpoint можно закрывать. Это особенно полезно, если в логах уже есть попытки обращения к xmlrpc.php или брутфорс по методу system.multicall.
Сначала проверьте, нужен ли он вам
- используете ли вы мобильное приложение WordPress для публикации;
- подключён ли внешний сервис, который отправляет записи через XML-RPC;
- есть ли интеграции со старыми клиентами или десктопными редакторами;
- не завязан ли на XML-RPC какой-то legacy-плагин.
Если на все пункты ответ «нет», отключение обычно безопасно.
Диагностика проблемы: как понять, что XML-RPC открыт
Самый простой признак — файл /xmlrpc.php отвечает на запрос. Это можно проверить из браузера или через curl. Если endpoint доступен, WordPress обычно возвращает сообщение о том, что XML-RPC сервер принимает только POST-запросы.
curl -I https://example.com/xmlrpc.phpЕсли вы видите ответ сервера, значит endpoint не закрыт. Это ещё не означает уязвимость, но точка входа существует и её можно убрать, если она не нужна.
Дополнительно проверьте логи веб-сервера. Частые POST-запросы к xmlrpc.php почти всегда говорят о сканировании или попытках подбора пароля.
Пошаговое решение: отключаем XML-RPC без плагинов
Есть два нормальных подхода: отключить XML-RPC на уровне WordPress и дополнительно закрыть файл на уровне веб-сервера. Лучше использовать оба, если у вас нет зависимости от этого механизма.
Вариант 1. Отключение через хук WordPress
Добавьте код в functions.php дочерней темы или, что надёжнее, в небольшой mu-plugin. Так вы не потеряете настройку после обновления темы.
<?php
add_filter('xmlrpc_enabled', '__return_false');Этот вариант отключает XML-RPC внутри WordPress. Для большинства сайтов этого достаточно. Но если сервер продолжает отдавать сам файл, лучше закрыть его ещё и на уровне Apache или Nginx.
Вариант 2. Блокировка через .htaccess для Apache
Если сайт работает на Apache, можно запретить доступ к xmlrpc.php напрямую. Добавьте правило выше стандартных правил WordPress:
<Files xmlrpc.php>
Require all denied
</Files>Если у вас старая конфигурация Apache 2.2, может встречаться формат с Deny from all, но на актуальных серверах лучше использовать Require all denied.
Вариант 3. Блокировка через Nginx
Для Nginx правило добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Иначе правило просто не применится.
nginx -t
systemctl reload nginxЧто выбрать: код, сервер или оба способа
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Быстро, без правок сервера | Файл остаётся доступным на уровне веб-сервера | Если нужен простой и обратимый вариант |
| .htaccess / Nginx | Закрывает endpoint раньше WordPress | Нужно иметь доступ к конфигу сервера | Если нужна более жёсткая блокировка |
| Оба способа | Максимально надёжно | Нужно следить за конфигурацией в двух местах | Если XML-RPC точно не нужен |
Проверка результата после внедрения
После внесения изменений проверьте не только страницу в браузере, но и фактический ответ сервера. Если XML-RPC отключён корректно, запрос к /xmlrpc.php должен возвращать 403 или другой запрет доступа, а не рабочий ответ WordPress.
curl -I https://example.com/xmlrpc.phpТакже проверьте, не ломаются ли внешние интеграции. Если у вас есть мобильное приложение WordPress или сторонний сервис публикации, попробуйте выполнить тестовую отправку записи. Если публикация перестала работать, значит XML-RPC всё-таки был нужен.
Ещё один практический тест — посмотреть логи доступа через 24–48 часов. Если правило сработало, запросы к xmlrpc.php либо исчезнут из логов, либо будут получать отказ без нагрузки на PHP.
Частые ошибки и как их исправить
Отключили только в functions.php, но endpoint всё ещё отвечает
Это нормально: фильтр WordPress не блокирует сам файл на уровне веб-сервера. Если нужен жёсткий запрет, добавьте правило в .htaccess или конфиг Nginx.
Правило добавили не туда
В Apache блок с <Files xmlrpc.php> должен находиться в корне сайта или в том каталоге, где реально лежит файл. Если правило вставлено в неподходящий .htaccess, оно может не сработать.
После правки Nginx сайт не перезапустился
Если забыть проверить конфиг командой nginx -t, можно оставить сайт с невалидной конфигурацией. Всегда проверяйте синтаксис до reload.
Сломались интеграции
Если после отключения перестали работать публикации из внешнего клиента, значит этот клиент использовал XML-RPC. В таком случае не закрывайте endpoint полностью: либо оставьте фильтр без серверной блокировки, либо ограничьте доступ только по IP, если источник запросов фиксированный.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не заменяет защиту от брутфорса, но убирает лишнюю поверхность атаки. Если на сайте уже есть проблемы с перебором паролей, дополнительно проверьте ограничение попыток входа, двухфакторную аутентификацию и актуальность плагинов.
Если вы используете решение для технической чистки и SEO-оптимизации вроде Clearfy Pro, там есть полезные настройки для отключения лишних функций WordPress и уменьшения количества дублей и служебных запросов. Но для XML-RPC в большинстве случаев достаточно кода и серверного правила — без лишней зависимости от плагина.
Короткий чек-лист перед публикацией изменений
- проверили, что XML-RPC реально не нужен сайту;
- добавили
add_filter('xmlrpc_enabled', '__return_false')или серверное правило; - протестировали
/xmlrpc.phpчерезcurlили браузер; - проверили логи на ошибки и отказанные запросы;
- убедились, что внешние интеграции не сломались.
Если нужен обратимый вариант, начните с фильтра WordPress. Если задача именно в снижении поверхности атаки, лучше закрыть endpoint и на уровне сервера. Так настройка будет предсказуемой и не потребует постоянного контроля.