XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильное приложение, внешнюю публикацию или старый клиент для удалённой работы с сайтом. Проблема не в самом протоколе, а в том, что его редко проверяют перед изменениями. Ниже — рабочий сценарий: как отключить лишнее, не выстрелив себе в ногу, и как понять, что всё действительно работает так, как задумано.
Когда XML-RPC мешает, а когда его лучше не трогать
Если сайт не использует удалённую публикацию, Jetpack, старые приложения для постинга и интеграции, которые ходят через XML-RPC, то этот интерфейс обычно только расширяет поверхность атаки. Но если у вас есть хотя бы один внешний сервис, который отправляет записи, комментарии или медиа через xmlrpc.php, отключение нужно делать осознанно.
Типичный практический сценарий: сайт обслуживается через обычную админку, а внешних интеграций нет. В этом случае XML-RPC можно закрыть на уровне кода или веб-сервера. Если интеграции есть, лучше сначала проверить, какие именно методы используются, и только потом ограничивать доступ.
Что обычно ломается после полного отключения
- мобильные клиенты WordPress для удалённой публикации;
- Jetpack и связанные с ним функции, если они используют XML-RPC;
- старые внешние редакторы и автопостинг-сервисы;
- инструменты, которые отправляют
pingbackилиtrackbackчерез XML-RPC.
Диагностика: используется ли XML-RPC на вашем сайте
Перед отключением проверьте, есть ли реальные обращения к /xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите запросы к этому файлу за последние дни или недели. Если логов нет, можно хотя бы временно посмотреть ответы сервера на прямой запрос.
Простейшая проверка с консоли:
curl -I https://example.com/xmlrpc.phpНормальный ответ сам по себе ещё не означает, что XML-RPC нужен. Важнее понять, кто и как его вызывает. Если в логах есть регулярные POST-запросы, не отключайте интерфейс вслепую.
Что смотреть в логах
- частоту обращений к
xmlrpc.php; - IP-адреса и User-Agent;
- ошибки авторизации и повторяющиеся попытки;
- запросы от известных сервисов, которые вы реально используете.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три практических подхода: плагин, код и ограничение на уровне сервера. Для большинства сайтов удобнее код или плагин, потому что результат легко проверить и откатить.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро включить и выключить, не нужен доступ к теме | Ещё один активный плагин, зависит от его качества |
| Код | Минимум лишнего, контроль в теме или mu-plugin | Нужно аккуратно вставить и не потерять при обновлении темы |
| Сервер | Жёстко закрывает доступ до WordPress | Можно случайно заблокировать нужные интеграции |
Вариант 1: отключить XML-RPC через код
Если вы хотите полностью закрыть доступ к XML-RPC, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключит сам механизм XML-RPC на уровне WordPress. Если позже понадобится вернуть доступ, достаточно убрать фильтр.
Вариант 2: заблокировать файл xmlrpc.php на уровне сервера
Если нужно отсечь запросы раньше, чем они дойдут до WordPress, используйте правила веб-сервера. Для Apache это может выглядеть так:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx обычно блокируют отдельный location. Конкретная конфигурация зависит от схемы сайта, но смысл один: не отдавать xmlrpc.php наружу. Этот вариант полезен, если на сайт идёт много мусорных запросов и вы хотите снизить нагрузку ещё до загрузки WordPress.
Вариант 3: не отключать всё, а ограничить доступ
Иногда полный запрет не подходит. Тогда лучше оставить XML-RPC только для тех сценариев, которые вам нужны, и проверить, можно ли заменить их REST API или обычной авторизацией через админку. На практике это часто более безопасный путь, чем держать открытым весь протокол ради одного старого клиента.
Проверка результата после внедрения
После изменения не ограничивайтесь визуальной проверкой в админке. Нужно проверить именно тот путь, который вы закрывали.
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт или ответ изменился ожидаемым образом. - Проверьте, не работает ли внешняя публикация из сервисов, которые вы используете.
- Посмотрите логи веб-сервера: обращения к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Если у вас есть мониторинг, убедитесь, что не выросло число ошибок авторизации в связанных интеграциях.
Для быстрой проверки можно отправить тестовый запрос:
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/xmlrpc.phpЕсли вы блокировали файл на сервере, ожидайте код отказа. Если отключали через фильтр WordPress, поведение может отличаться в зависимости от конфигурации сервера, но главное — запрос не должен использоваться как рабочий канал.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это означает, что Jetpack или связанный сервис действительно использовал XML-RPC. Решение простое: верните доступ и сначала проверьте, можно ли перевести нужную функцию на другой механизм. Не стоит держать блокировку, если она ломает рабочий сценарий.
Поставили плагин, но xmlrpc.php всё равно отвечает
Некоторые плагины отключают только часть функций или работают на уровне WordPress, а не веб-сервера. Если вам нужен жёсткий запрет, добавьте правило в конфигурацию Apache или Nginx. Иначе файл останется доступным для прямых запросов.
Сломали мобильную публикацию, но не поняли почему
Проверьте, какой именно клиент использовался. Старые приложения WordPress и сторонние редакторы часто завязаны на XML-RPC. Если вам нужна публикация с телефона, сначала протестируйте альтернативный сценарий через REST API или штатную админку.
Сделали блокировку в родительской теме
Если код добавлен в functions.php активной темы, при обновлении или смене темы он может потеряться. Для технических ограничений лучше использовать дочернюю тему или mu-plugin. Это особенно важно для настроек безопасности, которые не должны зависеть от дизайна.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если на сайте слабые пароли, нет ограничения попыток входа и не настроена двухфакторная аутентификация, один закрытый файл проблему не решит. Но как часть общей гигиены это полезный шаг: меньше лишних точек входа, меньше шума в логах, меньше бесполезных запросов.
Если вы используете набор технических оптимизаций и чистки сайта, имеет смысл проверять такие настройки в одном месте, а не разносить по разным плагинам. Например, в Clearfy Pro есть инструменты для отключения части лишнего функционала WordPress, но перед применением всё равно стоит понимать, что именно вы выключаете и зачем: https://wpshop.ru/plugins/clearfy?utm_source=wpstart.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-v-wordpress-i-ostavit-nuzhnye-zaprosy.
Если сайт под нагрузкой, блокировка XML-RPC на уровне сервера обычно предпочтительнее: запросы отсекаются раньше, чем WordPress начинает загружать ядро, плагины и тему. Для небольших сайтов разница может быть незаметна, но на шумных инсталляциях это полезно.
Главный критерий здесь простой: после изменений у вас не должно быть ни лишнего открытого интерфейса, ни сломанной интеграции. Если есть сомнения, сначала найдите реальные обращения к XML-RPC, потом ограничьте доступ и только после этого убирайте старые обходные решения.