XML-RPC в WordPress до сих пор встречается на старых сайтах, в мобильных приложениях и у некоторых внешних сервисов. На практике он часто не нужен, но остаётся включённым «на всякий случай». Это лишняя поверхность атаки и ещё один endpoint, который может создавать шум в логах и упираться в брутфорс-запросы.
Ниже разберём, как понять, используется ли XML-RPC именно у вас, как отключить его без поломки интеграций и как проверить результат после внедрения.
Когда XML-RPC действительно можно отключать
Сначала стоит не «рубить с плеча», а проверить реальные сценарии. XML-RPC нужен не всем, но если вы отключите его на сайте, который публикуется через сторонний клиент или синхронизируется с внешней системой, получите ошибки авторизации или недоступность функций.
Типичные признаки, что XML-RPC не используется
- в админке нет старых подключений через мобильные клиенты WordPress;
- сайт не принимает публикации из внешних сервисов через
xmlrpc.php; - в логах нет регулярных запросов к
/xmlrpc.phpот ваших приложений; - вы не используете Jetpack в режимах, где он опирается на XML-RPC для части функций;
- нет старых интеграций с десктопными редакторами и скриптами, которые работают через XML-RPC.
Что обычно ломается после отключения
Чаще всего страдают старые мобильные клиенты, внешняя публикация и некоторые плагины синхронизации. Если у вас только обычная работа через wp-admin и REST API, отключение XML-RPC обычно не мешает повседневной эксплуатации.
Диагностика: как проверить, используется ли xmlrpc.php
Самый надёжный путь — посмотреть фактические обращения к endpoint’у. Если у вас есть доступ к access log веб-сервера, это быстрее любых догадок.
grep -R "xmlrpc.php" /var/log/nginx/ /var/log/apache2/ 2>/dev/nullЕсли логов нет под рукой, можно проверить доступность endpoint снаружи. Это не доказывает использование, но показывает, что файл открыт и отвечает.
curl -I https://example.com/xmlrpc.phpДля WordPress обычно ответ будет 405 или 200 в зависимости от окружения и способа запроса. Сам по себе ответ не означает проблему, но если endpoint доступен, его уже можно закрывать, если он не нужен.
Быстрая проверка зависимостей
- поиск по установленным плагинам на предмет
xmlrpc,Jetpack, синхронизации публикаций; - проверка внешних сервисов, которые подключались к сайту по старому API;
- тест входа через мобильное приложение WordPress, если им кто-то пользуется;
- проверка cron-скриптов и интеграций, которые могли отправлять записи через XML-RPC.
Пошаговое решение: как отключить XML-RPC безопасно
Есть несколько рабочих вариантов. Если нужен быстрый и прозрачный способ, лучше отключать на уровне WordPress-хука. Если у вас есть доступ к серверу и вы хотите блокировать запросы раньше, можно добавить правило на веб-сервере.
Вариант 1. Отключить через код в functions.php или mu-plugin
Это самый понятный вариант, если вы управляете темой или используете небольшой must-use плагин. Он не требует правок сервера и легко откатывается.
<?php
add_filter('xmlrpc_enabled', '__return_false');Если нужно не просто отключить XML-RPC, а вернуть понятный ответ при обращении к endpoint, можно дополнительно завершать запрос раньше загрузки WordPress.
<?php
add_action('init', function () {
if (defined('XMLRPC_REQUEST') && XMLRPC_REQUEST) {
status_header(403);
exit('XML-RPC is disabled.');
}
});На практике чаще хватает первого варианта. Второй полезен, если вы хотите явно показать запрет в ответе и не тратить ресурсы на дальнейшую обработку.
Вариант 2. Заблокировать xmlrpc.php на уровне Nginx
Если сайт под вашим контролем и вы хотите отсечь запросы до PHP, добавьте отдельное правило. Это снижает нагрузку при массовых попытках обращения к endpoint.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache используют аналогичную блокировку через .htaccess, но на практике лучше делать это в конфигурации виртуального хоста, если есть доступ.
Вариант 3. Использовать плагин безопасности или очистки
Если вы не хотите держать код в теме, можно отключить XML-RPC через плагин, который уже управляет техническими настройками сайта. Важно только проверить, что плагин не делает лишнего и не дублирует функции, которые у вас уже реализованы.
| Подход | Плюсы | Минусы |
|---|---|---|
Хук xmlrpc_enabled | Просто, прозрачно, легко откатить | Запрос всё равно доходит до WordPress |
| Блокировка на сервере | Режет трафик раньше PHP | Нужен доступ к конфигу сервера |
| Плагин | Без правок кода | Зависимость от стороннего решения |
Как проверить, что отключение сработало
После внедрения не ограничивайтесь тем, что «ничего не сломалось». Проверьте endpoint напрямую и посмотрите логи.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что ответ больше не позволяет использовать XML-RPC по назначению.
- Проверьте access log: количество обращений к
/xmlrpc.phpдолжно либо исчезнуть, либо стать незначимым. - Если у вас есть внешние интеграции, выполните тестовую публикацию или синхронизацию.
Полезно также проверить, не остались ли в коде сайта старые вызовы к XML-RPC. Иногда они сидят в кастомных интеграциях, которые давно никто не трогал.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Не все функции Jetpack завязаны на XML-RPC, но часть старых сценариев может зависеть от него. Если после отключения появились ошибки, проверьте, какая именно функция ломается, и решите, можно ли заменить её REST API или штатной админкой.
Добавили код в тему, а потом потеряли изменение после обновления
Если правка лежит в functions.php активной темы, обновление или смена темы может её затереть. Для технических ограничений лучше использовать mu-plugin или отдельный небольшой плагин.
Блокировка на сервере конфликтует с прокси или WAF
Иногда запросы к xmlrpc.php проходят не напрямую, а через CDN, reverse proxy или защиту хостинга. Тогда правило нужно проверять в реальной цепочке обработки, а не только локально.
Отключили endpoint, но в логах всё равно много обращений
Это нормально, если сайт регулярно атакуют брутфорсом. В таком случае имеет смысл дополнительно ограничить частоту запросов на уровне WAF, fail2ban или правил хостинга. Само отключение XML-RPC не останавливает попытки стучаться в него.
Практические советы по безопасности и производительности
Если вы отключаете XML-RPC ради снижения риска, не забывайте про соседние меры. Один закрытый endpoint не делает сайт защищённым сам по себе.
- проверьте, не открыт ли у вас лишний
wp-login.phpдля массовых попыток входа; - ограничьте число неудачных авторизаций, если это поддерживает ваш стек;
- обновите ядро, плагины и тему до актуальных версий;
- не храните технические правки в активной теме, если они должны переживать обновления;
- после отключения XML-RPC проверьте, не остались ли старые интеграции в документации команды.
Если вам нужен более широкий набор технических настроек для чистки сайта, отключения дублей и управления служебными функциями, такие задачи обычно удобнее держать в одном инструменте, чем размазывать по теме и разным сниппетам. Но даже в этом случае важно понимать, что именно отключается и как это влияет на интеграции.
Когда лучше не отключать XML-RPC
Не стоит отключать его вслепую, если сайт ещё живёт на старой инфраструктуре, используется несколькими внешними редакторами или у команды есть автоматизированная публикация через сторонний софт. В таких случаях сначала составьте список зависимостей, а уже потом меняйте конфигурацию.
Если же сайт работает только через стандартную админку, а endpoint нужен лишь «потому что он всегда был», отключение XML-RPC — нормальная техническая уборка, которая уменьшает лишний вход для атак и упрощает поддержку.