XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильные клиенты, старые интеграции или сервисы публикации. Проблема не в самом файле xmlrpc.php, а в том, что его выключают без проверки зависимостей. Если у сайта есть внешние подключения, отключение нужно делать точечно: сначала понять, кто обращается к XML-RPC, потом убрать только лишнее.
Когда XML-RPC действительно стоит отключать
Если сайт не использует Jetpack для синхронизации, не принимает публикации из внешних приложений и не подключен к старым сервисам, XML-RPC обычно не нужен. Для большинства современных установок WordPress достаточно REST API и обычной авторизации в админке. Но есть важная оговорка: отключать нужно только после проверки, что никто не ходит в xmlrpc.php по делу.
Типичные сценарии, где XML-RPC уже не нужен
- сайт управляется только через админку WordPress;
- нет мобильного приложения WordPress;
- не используется Jetpack или его функции, завязанные на XML-RPC;
- нет внешних сервисов автопостинга, которые работают через XML-RPC;
- нет старых интеграций с публикацией по удаленному API.
Диагностика: кто вообще обращается к xmlrpc.php
Перед отключением посмотрите логи веб-сервера. Это самый практичный способ понять, есть ли реальные обращения. Если в логах видны регулярные запросы к /xmlrpc.php, сначала разберитесь с источником. Иногда это боты, иногда — легитимный сервис.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам может отличаться, но логика та же: ищем обращения к xmlrpc.php, смотрим IP, user-agent и частоту. Если запросы идут только от сканеров, отключение безопаснее. Если видите обращения от Jetpack, мобильного клиента или стороннего сервиса — сначала проверьте настройки интеграции.
Что проверить до изменений
- используется ли Jetpack и какие модули активны;
- есть ли мобильное приложение WordPress у редакторов;
- подключены ли сервисы автопубликации или мониторинга;
- есть ли в логах успешные запросы к
xmlrpc.php, а не только 404/403; - не завязан ли на XML-RPC сторонний плагин, который давно не обновлялся.
Как отключить XML-RPC: сравнение подходов
| Способ | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или плагине | Запрещает доступ на уровне WordPress | Гибко, можно быстро откатить | Не защищает от раннего ответа веб-сервера |
| .htaccess / nginx | Блокирует запросы до загрузки WordPress | Лучше для нагрузки и безопасности | Нужно аккуратно править конфиг |
| Плагин безопасности | Отключает XML-RPC через интерфейс | Просто для админа | Лишняя зависимость, не всегда прозрачно |
Если нужен быстрый и понятный вариант, обычно хватает кода. Если сайт часто атакуют по xmlrpc.php, лучше добавить блокировку на уровне сервера. Плагин имеет смысл только тогда, когда вы уже используете его для других задач и понимаете, что именно он меняет.
Пошаговое решение через код
Самый безопасный для сопровождения вариант — вынести отключение в мини-плагин или в functions.php дочерней темы. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает XML-RPC на уровне WordPress. После сохранения файл xmlrpc.php может по-прежнему отвечать, но сам XML-RPC будет недоступен. Для большинства задач этого достаточно.
Если нужно отдать 403 на уровне WordPress
Иногда полезно не просто выключить XML-RPC, а явно запретить доступ. Тогда можно использовать хук init и завершать запрос, если обращаются к xmlrpc.php.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Этот вариант полезен, если вы хотите видеть явный 403 в логах и не оставлять поведение на усмотрение ядра. Но для защиты от лишней нагрузки серверная блокировка все равно лучше.
Блокировка на уровне nginx или Apache
Если сайт регулярно получает брутфорс по xmlrpc.php, лучше отсечь запросы до WordPress. Это снижает лишнюю нагрузку и убирает шум в логах приложения.
nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если у вас есть исключения для конкретных сервисов, вместо полного deny all настраивайте доступ точечно по IP. Но не делайте это «на глаз»: сначала убедитесь, что сервис действительно использует XML-RPC, а не REST API.
Apache
<Files "xmlrpc.php">
Require all denied
</Files>После правки конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. Для Apache это особенно важно: одна лишняя директива может положить сайт целиком.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужно убедиться, что xmlrpc.php недоступен, а нужные сервисы не сломались.
- откройте
/xmlrpc.phpв браузере или черезcurl; - проверьте, что ответ стал 403, 404 или что XML-RPC больше не принимает методы;
- посмотрите логи веб-сервера после отключения;
- проверьте Jetpack, если он используется;
- проверьте публикацию из внешних инструментов, если они есть;
- убедитесь, что REST API продолжает отвечать нормально.
curl -I https://example.com/xmlrpc.phpЕсли ответ все еще 200, но XML-RPC отключен фильтром, это не ошибка. Важно, чтобы методы не выполнялись. Если же вы блокировали на уровне nginx или Apache, лучше увидеть 403.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Значит, в проекте реально использовалась одна из функций, завязанная на XML-RPC. Решение простое: либо вернуть доступ, либо перенести нужную интеграцию на другой механизм. Не пытайтесь «починить» это отключением только части методов без понимания, что именно использует плагин.
Поставили блокировку в теме и забыли про обновление
Если код лежит в родительской теме, он может исчезнуть при смене темы. Для таких настроек лучше использовать дочернюю тему или небольшой mu-plugin. Это надежнее и проще для сопровождения.
Закрыли xmlrpc.php на сервере, но не проверили мобильные приложения
Старые мобильные клиенты WordPress могут зависеть от XML-RPC. Если редакторы публикуют посты с телефона, сначала протестируйте сценарий на тестовом сайте или в рабочее время, когда можно быстро откатить изменение.
Путали XML-RPC и REST API
Это разные механизмы. Отключение xmlrpc.php не должно ломать REST API. Если после изменений перестали работать другие интеграции, значит, проблема не в XML-RPC, а в более широком ограничении доступа.
Практические советы по безопасности и производительности
Если на сайт идут регулярные атаки по xmlrpc.php, одной только блокировки может быть мало. Проверьте, не открыт ли лишний доступ к админке, включена ли двухфакторная аутентификация и нет ли слабых паролей у пользователей с правами редактора и выше. XML-RPC часто используют как точку входа для массовых попыток авторизации, поэтому отключение полезно, но не заменяет базовую защиту.
Если вам нужен более широкий набор настроек для чистки сайта и отключения лишнего технического мусора, можно посмотреть Clearfy Pro. Но даже в этом случае важно понимать, какие именно функции вы выключаете и зачем.
Для рабочих проектов я бы рекомендовал такой порядок: сначала проверить логи, потом отключить XML-RPC через код, затем при необходимости добавить серверную блокировку. Так вы не ломаете интеграции вслепую и получаете понятный откат, если что-то пошло не так.