XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack, внешние публикации и некоторые интеграции с сайтами и сервисами. Проблема не в самом XML-RPC как таковом, а в том, что его либо оставляют открытым без необходимости, либо закрывают слишком грубо.
Ниже — рабочая схема: как понять, нужен ли вам XML-RPC, как отключить его безопасно и как проверить, что после изменений сайт продолжает работать там, где это действительно важно.
Когда XML-RPC лучше отключить, а когда оставить
XML-RPC — это старый интерфейс WordPress для удалённого доступа. Сейчас его используют реже, чем REST API, но он всё ещё встречается в реальных сценариях: старые клиенты публикации, Jetpack, некоторые мобильные приложения, внешние сервисы автопостинга и мониторинга.
Если у вас нет ни одного сценария, который зависит от XML-RPC, держать его открытым смысла мало. Он часто попадает в зону брутфорса и лишней нагрузки. Но если вы отключите его без проверки, можно сломать рабочий процесс редакции или интеграцию с сервисом, который давно настроен и «тихо» использует этот канал.
Быстрая диагностика: нужен ли XML-RPC именно вам
Проверьте, есть ли у сайта хотя бы один из таких признаков:
- используется Jetpack и в нём задействованы функции, завязанные на соединение с сайтом;
- редакторы публикуют материалы через старое мобильное приложение WordPress;
- настроен внешний сервис автопостинга или кросспостинга;
- есть интеграция, которая обращается к
/xmlrpc.phpнапрямую; - в логах сервера видны регулярные запросы к
xmlrpc.php, но вы не понимаете, откуда они.
Если ничего из этого нет, XML-RPC можно отключать. Если есть хотя бы один пункт, сначала проверьте, можно ли перевести интеграцию на REST API или другой способ авторизации.
Как отключить XML-RPC в WordPress: три рабочих подхода
Есть несколько способов закрыть XML-RPC. Выбор зависит от того, хотите ли вы отключить его полностью, оставить доступ только для отдельных сценариев или просто снизить риск без правки ядра.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Фильтр в теме или плагине | Нужен контролируемый кодовый вариант | Прозрачно, можно быстро откатить | Нужно не забыть про обновления и место размещения кода |
| Правило на уровне сервера | Нужно жёстко закрыть доступ | Отсекает запросы раньше WordPress | Требует доступа к конфигу сервера |
| Плагин безопасности | Нужна настройка без кода | Быстро и удобно для админов | Лишняя зависимость от плагина |
Вариант 1. Отключить XML-RPC кодом
Если вы ведёте проект как разработчик и хотите контролируемое решение, добавьте фильтр в небольшой mu-plugin или в собственный плагин. Так вы не завяжетесь на тему и не потеряете настройку при смене оформления.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой способ полностью отключить XML-RPC на уровне WordPress. После его применения запросы к /xmlrpc.php должны перестать работать как рабочий канал.
Вариант 2. Закрыть xmlrpc.php на уровне сервера
Если задача — не просто отключить функциональность, а ещё и уменьшить лишний трафик, можно блокировать сам файл на уровне веб-сервера. Это полезно, когда боты активно стучатся в xmlrpc.php и создают шум в логах.
Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика обычно выносится в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант хорош тем, что запросы режутся до загрузки WordPress. Но если у вас есть легитимный клиент, он тоже перестанет работать — это надо проверить заранее.
Вариант 3. Использовать плагин безопасности
Если на проекте нет желания поддерживать свой код, можно закрыть XML-RPC через плагин безопасности. Это уместно, когда администраторы хотят управлять настройкой из интерфейса, а не через конфиг сервера.
Но здесь важно не путать удобство с надёжностью: плагин должен быть живым, поддерживаемым и не конфликтовать с другими защитными правилами. Если у вас уже есть централизованный security-стек, дублировать одну и ту же блокировку в нескольких местах не стоит.
Пошаговая схема внедрения без сюрпризов
Чтобы не сломать интеграции, лучше идти по короткому и проверяемому плану.
- Составьте список сервисов, которые могут использовать XML-RPC: Jetpack, мобильные клиенты, автопостинг, внешние редакторы.
- Проверьте, есть ли обращения к
/xmlrpc.phpв логах сервера за последние дни. - Если есть сомнения, сначала отключите XML-RPC на тестовой копии сайта.
- Примените кодовый вариант или серверное правило.
- Сразу проверьте доступность нужных сценариев: вход в админку, публикацию, интеграции, REST API.
- Если что-то сломалось, откатите изменение и ищите конкретный клиент, который использует XML-RPC.
Что проверить в логах
Полезно посмотреть не только факт обращений, но и их частоту. Если к xmlrpc.php идут массовые запросы с одинаковых IP или с разными user-agent, это уже не рабочая интеграция, а фоновой шум или атака на подбор паролей.
Для быстрой диагностики можно искать такие строки в access log:
grep "xmlrpc.php" access.logЕсли у вас есть доступ к панели хостинга, смотрите не только количество запросов, но и коды ответа. Много 200 или 401 по xmlrpc.php — повод закрывать доступ, если он не нужен.
Как проверить, что отключение сработало
После внедрения важно не ограничиваться тем, что «страница открывается». Нужна проверка именно по XML-RPC и по связанным сценариям.
- Откройте
/xmlrpc.phpв браузере или черезcurl: при серверной блокировке должен быть отказ в доступе, при отключении через WordPress — не должно быть рабочего ответа для удалённого клиента. - Проверьте Jetpack, если он используется: соединение с сайтом должно остаться в рабочем состоянии только если ваш сценарий это допускает.
- Попробуйте публикацию из внешнего клиента, если он есть в рабочем процессе.
- Посмотрите логи сервера после изменения: запросы к
xmlrpc.phpмогут продолжаться, но должны получать отказ, а не обрабатываться WordPress.
Если у вас есть staging-копия, сравните поведение до и после. Это особенно полезно, когда на сайте несколько администраторов и не все знают, какие сервисы подключены.
Частые ошибки и как их исправить
Отключили XML-RPC в теме
Это плохая практика. При смене темы настройка пропадёт, а логика безопасности не должна зависеть от оформления. Перенесите код в mu-plugin или отдельный плагин.
Закрыли xmlrpc.php, но не проверили интеграции
Так часто ломают Jetpack или внешний редактор. Перед блокировкой обязательно проверьте, какие сервисы реально используют этот endpoint.
Поставили несколько способов блокировки сразу
Например, код в WordPress, правило в .htaccess и ещё плагин безопасности. В результате потом сложно понять, что именно мешает работе. Начинайте с одного способа и фиксируйте его в документации проекта.
Отключили XML-RPC, но оставили старые учётные записи и слабые пароли
Это не замена базовой гигиене безопасности. XML-RPC — лишь один из каналов атаки. Если сайт слабо защищён по паролям и правам доступа, проблема останется.
Практические советы по безопасности и производительности
Если вы закрываете XML-RPC ради безопасности, имеет смысл посмотреть на соседние точки риска:
- уберите неиспользуемые плагины и темы;
- проверьте, не открыт ли REST API для лишних публичных данных;
- ограничьте число попыток входа и включите нормальную политику паролей;
- следите за логами, чтобы не пропустить повторяющиеся атаки на
xmlrpc.php; - если нужна комплексная чистка технического мусора и дублей, удобно держать под рукой инструменты вроде Clearfy Pro, но использовать их точечно, а не как замену ручной проверке.
Для производительности смысл тоже есть: если на сайт постоянно летят запросы к xmlrpc.php, сервер тратит ресурсы на обработку мусора. Серверная блокировка снимает эту нагрузку раньше, чем WordPress начнёт грузить ядро и плагины.
Когда лучше не отключать XML-RPC полностью
Полное отключение — не универсальный ответ. Если у вас есть рабочий клиент публикации, старый, но критичный сервис интеграции или часть редакции завязана на удалённый доступ, сначала переведите процесс на другой канал. Иногда разумнее оставить XML-RPC закрытым только для внешнего мира на уровне сервера, но сохранить доступ в рамках конкретной инфраструктуры. Это уже зависит от схемы деплоя и сетевой архитектуры.
Главный критерий простой: если вы не можете назвать ни одного реального потребителя XML-RPC, его лучше закрыть. Если потребитель есть, отключайте только после проверки и с понятным планом отката.