XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, публикация из мобильного приложения или внешние сервисы, которые отправляют записи через API старого типа. Поэтому правильный подход здесь не в том, чтобы просто закрыть файл xmlrpc.php, а сначала понять, используется ли он вообще.
Если у вас обычный сайт без удалённой публикации и без старых интеграций, XML-RPC действительно можно отключить. Но делать это лучше осознанно: сначала диагностика, потом блокировка, потом проверка, что ничего не отвалилось.
Когда XML-RPC реально нужно отключать
XML-RPC — это старый механизм удалённого доступа к WordPress. Сегодня для большинства задач есть REST API, но XML-RPC всё ещё может использоваться сторонними клиентами и плагинами. На практике его отключают в трёх случаях:
- сайт не использует удалённую публикацию вообще;
- в логах видно много запросов к
/xmlrpc.phpс перебором паролей; - нужно сократить поверхность атаки без изменения функциональности сайта.
Если у вас включён Jetpack, публикация из мобильного приложения WordPress, старые внешние редакторы или интеграции с сервисами, которые не перешли на REST API, отключение может сломать часть сценариев. Это и есть главный риск.
Диагностика: используется ли xmlrpc.php сейчас
Перед изменениями проверьте, есть ли обращения к xmlrpc.php. Самый простой способ — посмотреть access log веб-сервера или логи в панели хостинга. Ищите строки с запросами к /xmlrpc.php. Если запросы идут регулярно и не выглядят как атака, сначала выясните источник.
Что проверить в админке и плагинах
- Jetpack: подключён ли сайт и используются ли функции удалённой публикации.
- Мобильное приложение WordPress: публикуете ли вы записи со смартфона.
- Сторонние сервисы: автопостинг, мониторинг, синхронизация контента.
- Плагины кэширования и безопасности: не блокируют ли они XML-RPC уже сейчас.
Если вы не уверены, временно не отключайте файл полностью. Сначала можно ограничить доступ по IP или закрыть только самые опасные методы, но это уже отдельная настройка и не всегда оправдана. Для большинства сайтов достаточно либо оставить всё как есть, либо отключить полностью.
Как отключить XML-RPC: три рабочих варианта
Есть три практических подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, кто поддерживает сайт и где вам удобнее управлять изменением.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правок темы | Лишняя зависимость | Если нужен простой откат |
Код в functions.php или mu-plugin | Контроль, без лишних плагинов | Нужно аккуратно обновлять | Если вы ведёте проект как разработчик |
| Веб-сервер | Режет запрос раньше WordPress | Зависит от хостинга и конфигурации | Если есть доступ к nginx/apache |
Вариант 1: отключение через код
Самый предсказуемый способ — добавить фильтр в functions.php дочерней темы или в отдельный mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Запросы к xmlrpc.php будут получать отказ уже после загрузки ядра, поэтому для массовых атак это не самый ранний, но вполне рабочий способ.
Вариант 2: mu-plugin
Если не хотите привязывать настройку к теме, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Mu-plugin загружается автоматически и не зависит от активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это удобно для проектов, где безопасность и технические ограничения должны жить отдельно от дизайна и шаблонов.
Вариант 3: блокировка на уровне сервера
Если у вас Apache, можно закрыть доступ к файлу через .htaccess. Для nginx правило добавляют в конфигурацию сайта. Это полезно, когда вы хотите отсечь запросы до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика будет другой, но суть та же: вернуть 403 на запрос к /xmlrpc.php. Если вы не управляете сервером напрямую, этот вариант может быть недоступен.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что XML-RPC не используется нужными сервисами.
- Сделайте резервную копию файлов и базы, если меняете серверную конфигурацию.
- Выберите способ отключения: код, mu-plugin или веб-сервер.
- Внесите изменение только в одном месте, чтобы было понятно, где откатывать.
- Проверьте доступ к
/xmlrpc.phpи работу интеграций.
Если сайт обслуживается командой, зафиксируйте изменение в документации проекта. Иначе через месяц кто-то снова подключит Jetpack или мобильный клиент и будет искать причину поломки не там.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте в браузере https://ваш-домен.ru/xmlrpc.php. В зависимости от способа блокировки вы увидите либо 403, либо стандартный ответ WordPress о том, что XML-RPC сервер принимает только POST-запросы. Если вы отключали через фильтр, при корректной настройке XML-RPC должен быть недоступен для вызовов.
Дополнительно проверьте:
- не работает ли публикация из мобильного приложения WordPress;
- не ругается ли Jetpack на потерю соединения;
- не появились ли ошибки в логах сайта после изменения;
- не изменилось ли поведение внешних интеграций, которые отправляют записи.
Если вы закрывали доступ на уровне сервера, убедитесь, что ответ действительно 403, а не редирект на страницу ошибки, который всё равно оставляет файл доступным.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Jetpack может использовать XML-RPC для части функций подключения. Если после отключения модуль перестал синхронизироваться, проверьте, действительно ли вам нужен именно этот сценарий. Иногда проще оставить XML-RPC включённым и ограничить доступ другими средствами.
Добавили код в активную тему
После обновления темы настройка исчезает. Для технических изменений лучше использовать mu-plugin или дочернюю тему. Это особенно важно на сайтах, где тему обновляют регулярно.
Закрыли файл в .htaccess, но сайт на nginx
Правило для Apache в этом случае не сработает. Если хостинг использует nginx, нужно править его конфигурацию или использовать отключение через WordPress-код.
Сломали внешнюю публикацию и не поняли почему
Проблема часто проявляется не сразу. Если у вас есть интеграции с автопостингом, проверьте их вручную после внедрения. Не ориентируйтесь только на отсутствие ошибок в админке.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но уменьшает лишний входной канал. Это полезно в связке с другими мерами: ограничением попыток входа, двухфакторной аутентификацией, актуальными обновлениями и нормальной политикой паролей.
Если цель — именно снизить нагрузку от атак, серверная блокировка предпочтительнее, чем отключение только через фильтр WordPress. Но если вам важна простота отката, mu-plugin обычно удобнее. Для большинства проектов это самый практичный компромисс.
Когда на сайте уже есть плагин для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не дублирует ли он вашу настройку. Лишние пересекающиеся функции — частая причина того, что потом никто не понимает, где именно включено или выключено правило.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать его нельзя: например, сайт использует старую интеграцию, которую пока не успели перевести на REST API. В таком случае не стоит рубить всё сразу. Сначала определите, какой именно клиент обращается к XML-RPC, и можно ли заменить его на современный способ авторизации и публикации.
Если замена невозможна быстро, оставьте XML-RPC включённым, но закройте другие слабые места: обновите пароли, ограничьте доступ к админке, проверьте логи и убедитесь, что на сайте нет лишних пользователей с правами редактора или администратора.
Такой подход обычно безопаснее, чем формальное «отключить всё», после которого ломается рабочий процесс команды.