XML-RPC в WordPress часто нужен только в редких сценариях: старые мобильные клиенты, внешние сервисы публикации, некоторые интеграции. На обычном сайте он чаще создаёт лишнюю поверхность атаки и шум в логах. Если задача — убрать ненужный удалённый доступ, важно не просто «выключить файл», а понять, кто и зачем к нему обращается.
Когда XML-RPC действительно стоит отключать
Если вы не используете внешние приложения для публикации через xmlrpc.php, не подключали старые интеграции и не видите в логах легитимных запросов, отключение обычно оправдано. На практике это полезно для сайтов, где уже есть REST API, обычная админка и никаких сторонних клиентов не требуется.
Но есть нюанс: некоторые плагины и сервисы могут проверять доступность XML-RPC не для публикации, а для синхронизации или удалённых операций. Поэтому сначала проверьте фактическое использование, а уже потом режьте доступ на уровне кода или сервера.
Диагностика: кто обращается к xmlrpc.php
Начните с логов веб-сервера. Если у вас Nginx или Apache пишет access log, ищите обращения к /xmlrpc.php. Это даст ответ, есть ли вообще трафик и откуда он идёт.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, можно временно посмотреть запросы через инструменты хостинга или мониторинг безопасности. Важны не только IP, но и частота. Серии однотипных POST-запросов обычно указывают на сканирование или попытки подбора, а не на нормальную интеграцию.
Что считать нормальным, а что подозрительным
- Нормально: редкие запросы с понятного IP, который принадлежит вашему сервису.
- Подозрительно: массовые POST-запросы с разных адресов.
- Нужно проверить: запросы от плагинов резервного копирования, мобильных клиентов, внешних редакторов.
Если вы не уверены, временно включите журналирование на уровне сервера или используйте staging-копию сайта, чтобы не ломать рабочий процесс редакторов.
Пошаговое решение: как отключить XML-RPC без лишнего риска
Есть два рабочих подхода: через PHP-фильтр и через веб-сервер. Для большинства сайтов достаточно фильтра в functions.php дочерней темы или в небольшом mu-plugin. Это проще откатить и легче сопровождать.
Вариант 1: отключение через WordPress
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC на уровне WordPress. Если кто-то откроет xmlrpc.php, WordPress вернёт отказ. Для многих сайтов этого достаточно.
Если нужен более жёсткий вариант, можно дополнительно блокировать доступ на уровне сервера. Тогда запрос даже не дойдёт до PHP.
Вариант 2: блокировка на уровне Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой блок лучше использовать, если вы уверены, что XML-RPC не нужен вообще. Это снижает нагрузку и убирает лишний шум в логах. На Apache аналогичную задачу обычно решают через .htaccess, но там важно не сломать остальную конфигурацию.
Вариант 3: блокировка через .htaccess
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант подходит для Apache 2.4+. Если у вас старый синтаксис, правила будут другими, но на современных хостингах чаще используется именно такой формат.
Что выбрать: код, сервер или плагин
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Быстро, просто откатить | Запрос доходит до WordPress | Если нужен мягкий и безопасный старт |
| Блокировка на сервере | Жёстко, меньше нагрузки | Нужен доступ к конфигу сервера | Если XML-RPC точно не нужен |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость от плагина | Если вы уже используете security-плагин |
Если у вас уже стоит комплексный плагин вроде Clearfy Pro, проверьте, нет ли там отдельной опции отключения XML-RPC и других лишних сервисов. Это удобно, когда вы хотите закрыть сразу несколько технических «дыр» без ручного редактирования конфигов.
Проверка результата после внедрения
После отключения проверьте не только открытие xmlrpc.php в браузере, но и реальный ответ сервера. Если всё настроено правильно, вы не должны получать рабочий XML-RPC-ответ.
curl -I https://example.com/xmlrpc.phpДля более точной проверки отправьте тестовый POST-запрос. В ответе не должно быть успешного XML-RPC-метода.
curl -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Дополнительно посмотрите логи через несколько часов или дней. Если обращения к xmlrpc.php исчезли, а редакторы и интеграции не жалуются, решение можно считать успешным.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали внешнюю публикацию
Причина обычно в том, что сайт всё ещё использует старый клиент или сервис, который работает через XML-RPC. Решение простое: верните доступ на staging, проверьте список интеграций и замените их на REST API или другой поддерживаемый способ подключения.
Поставили правило в .htaccess, но оно не сработало
Частая причина — сайт работает на Nginx, а не на Apache, либо правило вставлено не в тот блок. Проверьте, какой веб-сервер реально обслуживает сайт, и применяйте конфигурацию именно для него.
Отключили только в WordPress, но запросы всё равно идут
Это нормально: запросы продолжают приходить, просто WordPress их отклоняет. Если цель — убрать сам трафик и снизить нагрузку, нужна блокировка на уровне сервера.
Сразу поставили security-плагин и не проверили совместимость
Некоторые плагины безопасности меняют поведение XML-RPC вместе с другими правилами. После установки проверьте логин, публикацию, REST API и работу редактора, чтобы не искать проблему вслепую.
Практические советы по безопасности и обслуживанию
Если вы отключаете XML-RPC ради безопасности, не останавливайтесь только на этом. Проверьте ещё и другие точки, которые часто оставляют без внимания: устаревшие плагины, лишние публичные endpoints, открытые файлы резервных копий, доступ к wp-config.php через неверные права.
- Делайте изменения сначала на staging-копии.
- После правки конфигов очищайте кеш страницы и кеш объекта, если он есть.
- Не смешивайте несколько способов отключения сразу без необходимости: сначала один метод, потом проверка.
- Если используете CDN или WAF, проверьте, не кэширует ли он старый ответ на
xmlrpc.php.
Для сайтов с регулярной технической чисткой удобно держать такие настройки в одном месте и документировать, что именно отключено и почему. Это экономит время, когда через полгода кто-то из команды спросит, зачем был закрыт XML-RPC и не мешает ли это интеграциям.
Если нужен более широкий аудит технических дублей, лишних сервисов и мусорных запросов, похожие задачи часто закрывают через набор настроек в плагинах оптимизации и безопасности, но сам принцип остаётся тем же: сначала диагностика, потом точечное отключение, потом проверка по логам и реальному поведению сайта.