Файл xmlrpc.php в WordPress часто оставляют без внимания, пока не появляются странные попытки входа, лишняя нагрузка или жалобы на брутфорс. Сам по себе XML-RPC не «плохой», но на многих сайтах он просто не нужен. Если вы не используете мобильное приложение WordPress, внешние публикации через старые клиенты или интеграции, которые завязаны именно на XML-RPC, доступ к нему можно закрыть.
Ниже — рабочие способы, как это сделать без лишней магии: через код, через сервер и с проверкой результата. Отдельно разберём, когда отключение ломает интеграции и как этого избежать.
Когда xmlrpc.php действительно стоит отключать
Отключение имеет смысл, если сайт не использует функции, которые идут через XML-RPC. Чаще всего это:
- старые мобильные клиенты WordPress;
- публикация записей из внешних редакторов;
- интеграции, которые до сих пор работают через XML-RPC, а не REST API;
- сайты, где регулярно фиксируются попытки перебора паролей через
xmlrpc.php.
Если у вас обычный корпоративный сайт, блог или лендинг на WordPress, XML-RPC обычно не нужен. Для таких проектов закрытие доступа — нормальная техническая мера, а не «перестраховка ради перестраховки».
Диагностика: как понять, что именно xmlrpc.php создаёт проблему
Перед изменениями проверьте, есть ли обращения к этому файлу и нет ли зависимых сервисов. Это можно сделать по логам веб-сервера или по событиям в панели хостинга. В access.log обычно видно много запросов к /xmlrpc.php, особенно если сайт атакуют перебором логинов.
Что искать в логах
Обратите внимание на повторяющиеся POST-запросы к xmlrpc.php с разных IP, а также на ошибки 200/403/404 в большом количестве. Если запросов много, а вы не используете XML-RPC, это хороший кандидат на отключение.
Если есть сомнения, временно ограничьте доступ и проверьте, не сломались ли внешние публикации, мобильное приложение или сторонний сервис синхронизации.
Пошаговое решение: как закрыть xmlrpc.php
Есть три практичных варианта: отключить на уровне WordPress, заблокировать на уровне веб-сервера или совместить оба подхода. Для большинства сайтов достаточно одного из них, но если нагрузка и атаки заметные, лучше закрыть и в приложении, и на сервере.
Вариант 1. Отключить через код WordPress
Это самый простой способ, если у вас есть доступ к functions.php дочерней темы или к собственному мини-плагину. Такой вариант не требует правок конфигурации сервера.
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает XML-RPC на уровне WordPress. Если кто-то обратится к xmlrpc.php, WordPress не будет обрабатывать запрос как обычно.
Если нужен более жёсткий вариант, можно принудительно отдавать 403 при прямом обращении к файлу:
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );На практике первый вариант обычно достаточно понятный и безопасный. Второй полезен, если вы хотите явно блокировать запросы, а не просто отключать функциональность.
Вариант 2. Заблокировать на уровне Apache
Если сайт работает на Apache или LiteSpeed с поддержкой .htaccess, можно запретить доступ к файлу напрямую. Это снижает лишнюю нагрузку ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Если сервер старый и использует синтаксис Apache 2.2, встречается вариант с Deny from all, но на современных конфигурациях лучше использовать Require all denied.
Вариант 3. Заблокировать на уровне Nginx
Для Nginx правило обычно добавляют в конфигурацию сайта. Это хороший вариант, если вы управляете сервером и хотите отрезать запросы до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить Nginx. Иначе правило просто не применится.
Что выбрать: код, сервер или оба варианта
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Быстро, не требует доступа к серверу | Запрос всё равно доходит до WordPress | Если нет доступа к конфигу веб-сервера |
.htaccess | Простая блокировка на Apache | Не подходит для Nginx | Если сайт на Apache/LiteSpeed |
| Nginx rule | Блокирует до PHP, экономит ресурсы | Нужен доступ к конфигу | Если вы администрируете сервер |
Если у вас есть доступ к серверу, лучше блокировать там. Если доступа нет — используйте фильтр WordPress. На нагруженных сайтах можно совместить оба подхода.
Как проверить, что решение сработало
Проверка нужна обязательно, иначе легко получить ложное ощущение безопасности. Самый простой тест — открыть /xmlrpc.php в браузере или отправить запрос через curl.
curl -I https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки:
- 403 Forbidden — если доступ запрещён на сервере;
- 405 Method Not Allowed или похожий ответ — если сервер/прокси ограничивает метод;
- 200 OK с сообщением WordPress о XML-RPC — значит, блокировка не сработала;
- 404 Not Found — если файл скрыт или запрос перехвачен настройками сервера.
Дополнительно проверьте, не появляются ли новые обращения к файлу в логах после внедрения правила. Если запросы продолжают приходить, но получают 403, значит блокировка работает корректно.
Частые ошибки и как их исправить
Сломали мобильное приложение WordPress
Если кто-то в команде публикует записи через официальное приложение WordPress, отключение XML-RPC может убрать эту возможность. Решение простое: либо возвращаете доступ, либо переводите процесс на REST API и обычную авторизацию.
Добавили правило не в тот конфиг
На Nginx частая ошибка — править не тот server block или забыть перезагрузить сервис. После изменения всегда проверяйте nginx -t и только потом делайте reload.
В .htaccess правило стоит ниже конфликтующего блока
На Apache порядок правил имеет значение. Если в файле уже есть сложные rewrite-правила, блокировка может не сработать так, как ожидается. В таком случае проверьте, не переписывает ли другой блок запрос к xmlrpc.php.
Отключили XML-RPC, но атаки продолжаются
Это нормально: бот может продолжать стучаться в файл, даже если он закрыт. Важен не сам факт запроса, а то, что он не проходит дальше и не нагружает PHP. Если запросов слишком много, дополнительно настройте WAF, rate limit или блокировку на уровне CDN.
Практические советы по безопасности и производительности
Если вы закрываете XML-RPC ради защиты, не ограничивайтесь одним файлом. Проверьте ещё несколько вещей:
- обновлены ли ядро WordPress, тема и плагины;
- есть ли включённые двухфакторные методы входа для администраторов;
- не открыт ли доступ к
wp-login.phpбез ограничений; - не используются ли старые плагины, которые держатся на устаревших механизмах авторизации;
- есть ли базовая защита от перебора паролей на уровне хостинга или сервера.
Если вам нужно ещё и убрать дубли, мусорные страницы, лишние мета-теги и технический шум, такие задачи часто удобнее закрывать отдельным набором оптимизаций на стороне сайта. Но блокировка XML-RPC всё равно должна быть самостоятельным, проверяемым изменением.
После внедрения сохраните правило в документации проекта: где именно отключён XML-RPC, кто отвечает за поддержку и как быстро вернуть доступ, если появится интеграция, которой он действительно нужен.
