Файл xmlrpc.php в WordPress часто оставляют включённым по умолчанию, а потом удивляются лишним запросам, попыткам подбора пароля и шуму в логах. Если вы не используете Jetpack, старые мобильные клиенты или внешнюю публикацию через XML-RPC, этот интерфейс обычно можно отключить без потери основной функциональности сайта.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, чем его лучше отключать, как проверить результат и какие ошибки встречаются чаще всего.
Когда XML-RPC действительно мешает
Проблема обычно проявляется не как одна явная ошибка, а как набор мелких симптомов:
- в логах много запросов к
/xmlrpc.phpс разных IP; - на сайте идут попытки брутфорса через метод
system.multicall; - хостинг фиксирует лишнюю нагрузку, хотя сам сайт почти не посещают;
- в отчётах безопасности появляется предупреждение о доступном XML-RPC endpoint;
- вы не используете внешнюю публикацию, а файл всё равно открыт.
Что важно проверить до отключения
Не отключайте интерфейс вслепую, если у вас есть хотя бы один из этих сценариев:
- Jetpack подключён к сайту и использует XML-RPC;
- вы публикуете записи из стороннего клиента, который работает через XML-RPC;
- у вас есть интеграция со старым сервисом, который не умеет REST API;
- мобильное приложение или внешняя система управления контентом завязаны на XML-RPC.
Если ничего из этого нет, отключение обычно безопасно.
Диагностика: как понять, что запросы идут именно через xmlrpc.php
Самый простой способ — посмотреть access log веб-сервера или отчёт в панели хостинга. Ищите строки с xmlrpc.php. Если логов нет, можно временно проверить endpoint вручную:
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает кодом 200 или 405, файл доступен. Это не означает уязвимость само по себе, но подтверждает, что endpoint открыт.
Для более точной проверки можно отправить тестовый POST-запрос. WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы:
curl -s -X POST https://example.com/xmlrpc.phpЕсли endpoint нужен, вы увидите ожидаемый ответ WordPress. Если нет — дальше имеет смысл его закрыть.
Как отключить XML-RPC: сравнение вариантов
| Способ | Когда подходит | Минус |
|---|---|---|
| Через код в теме или mu-plugin | Нужен контролируемый и прозрачный способ | Надо не забыть, где лежит код |
| Через плагин безопасности | Уже используете плагин с таким переключателем | Лишняя зависимость от настроек плагина |
| Через серверную блокировку | Нужно отсечь запросы ещё до WordPress | Требует доступа к конфигу сервера |
Для большинства рабочих сайтов удобнее код или серверная блокировка. Если у вас нет доступа к серверу, код — самый предсказуемый вариант.
Пошаговое решение через код
Самый безопасный путь — добавить небольшой фрагмент в functions.php дочерней темы или, что лучше, в отдельный mu-plugin. Тогда отключение не потеряется после обновления темы.
<?php
/**
* Disable XML-RPC.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает сам XML-RPC в WordPress. После добавления файл xmlrpc.php может продолжать отвечать на запросы, но функциональность XML-RPC будет заблокирована на уровне WordPress.
Если вам нужно не просто отключить XML-RPC, а ещё и отрезать доступ к файлу на уровне сервера, можно использовать правило для Apache:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика другая — блокировка делается в конфиге сервера:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверная блокировка полезна тем, что запросы не доходят до PHP. Это снижает лишнюю нагрузку, особенно если атаки идут массово.
Если нужен только частичный контроль
Иногда XML-RPC нужен не полностью, а только для конкретного сервиса. В таком случае лучше не отключать его полностью, а ограничить доступ на уровне сети или WAF. Например, можно разрешить запросы только с доверенных IP, если интеграция статична.
Но здесь важно не переусердствовать: у многих сервисов IP меняются, а жёсткий allowlist быстро ломает интеграции. Если нет уверенности, что список адресов стабилен, лучше переходить на REST API или полностью отключать XML-RPC.
Проверка результата после внедрения
После отключения проверьте не только сам endpoint, но и связанные сценарии.
- Откройте
https://example.com/xmlrpc.phpв браузере — доступ не должен давать рабочий XML-RPC ответ. - Повторите запрос через
curlи убедитесь, что endpoint не выполняет методы. - Проверьте логи сервера: число обращений к
xmlrpc.phpдолжно снизиться или исчезнуть. - Если используется Jetpack, убедитесь, что он не потерял связь с сайтом.
- Проверьте публикацию и редактирование записей в админке — они должны работать как раньше.
Если после отключения сайт начал ругаться на подключение к внешнему сервису, значит, у вас была зависимость, которую нужно заменить или перенастроить.
Частые ошибки и как их исправить
Отключили XML-RPC, но атаки в логах остались
Это нормально, если вы закрыли только WordPress-фильтр, а не сам файл на сервере. Запросы всё ещё доходят до веб-сервера, просто WordPress их не обрабатывает. Если цель — снизить нагрузку, добавьте серверную блокировку.
Сломался Jetpack или внешний клиент
Значит, сервис использовал XML-RPC. Проверьте, можно ли перевести его на REST API или другой способ авторизации. Если нет — не отключайте XML-RPC полностью, а ограничьте доступ точечно.
Добавили код в родительскую тему
После обновления темы настройка исчезнет. Для таких изменений лучше использовать дочернюю тему или mu-plugin в wp-content/mu-plugins/.
Сделали блокировку в .htaccess, но сайт на Nginx
.htaccess на Nginx не работает. Для Nginx правило нужно добавлять в конфигурацию сайта и после этого перезагружать веб-сервер.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа. Если сайт регулярно атакуют, проверьте ещё и другие точки:
- ограничение попыток входа;
- двухфакторную аутентификацию для администраторов;
- скрытие или защита
/wp-login.phpтам, где это уместно; - актуальность плагинов и тем;
- логи на предмет повторяющихся запросов с одного диапазона IP.
Если вы используете плагин безопасности, проверьте, не дублирует ли он вашу серверную блокировку. Два одинаковых правила обычно не вредят, но иногда мешают диагностике: сложно понять, где именно запрос был остановлен.
Для сайтов с высокой посещаемостью полезно блокировать xmlrpc.php на уровне веб-сервера, а не только в WordPress. Это уменьшает количество лишних PHP-запусков и помогает не тратить ресурсы на заведомо ненужные запросы.
Короткий чек-лист перед публикацией изменений
- Проверили, нужен ли XML-RPC конкретным интеграциям.
- Добавили отключение через дочернюю тему или mu-plugin.
- При необходимости закрыли
xmlrpc.phpна уровне сервера. - Протестировали доступ через браузер и
curl. - Убедились, что Jetpack и внешние сервисы не сломались.
- Посмотрели логи и убедились, что лишние обращения сократились.
Если нужен более широкий набор мер по чистке и снижению технического шума на сайте, иногда удобнее собрать это в одном наборе инструментов, чем держать десяток разрозненных правок. Но сам XML-RPC лучше отключать отдельно и проверять вручную — здесь важнее предсказуемость, чем автоматизация ради автоматизации.