XML-RPC в WordPress часто отключают по одной причине: через этот интерфейс идут лишние запросы, а иногда и попытки перебора паролей. Но у отключения есть побочный эффект — можно сломать удалённую публикацию, мобильные клиенты и интеграции вроде Jetpack. Поэтому здесь важен не сам факт блокировки, а аккуратная проверка того, что именно использует ваш сайт.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешние приложения для публикации и не завязан на старые интеграции, XML-RPC обычно не нужен. На практике его отключают, когда в логах видно много запросов к /xmlrpc.php, а в панели безопасности появляются однотипные попытки авторизации. Это не панацея, но лишний входной канал лучше убрать, если он не нужен.
Сначала проверьте, есть ли у вас зависимости:
- Jetpack с включённой синхронизацией или удалённым управлением;
- мобильное приложение WordPress;
- старые сервисы автопостинга и кросспостинга;
- внешние клиенты для публикации по XML-RPC;
- интеграции, которые используют pingback/trackback, если они ещё где-то задействованы.
Диагностика: что именно использует XML-RPC
Перед блокировкой полезно посмотреть, есть ли реальные обращения к файлу xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите частые POST-запросы к этому пути и сравните их с обычным трафиком.
Проверка через логи сервера
Примерно так выглядит запрос, который стоит искать в access log:
POST /xmlrpc.php HTTP/1.1Если таких строк много, а в админке нет ни одной нужной интеграции, XML-RPC можно отключать. Если же запросы идут от Jetpack или мобильного приложения, сначала разберитесь, можно ли заменить сценарий на REST API или штатные функции плагина.
Быстрая проверка из браузера и по HTTP
Откройте /xmlrpc.php в браузере. В норме вы увидите короткий текст вроде XML-RPC server accepts POST requests only. Это не означает, что сервис нужен, но подтверждает, что файл доступен извне. Для более точной проверки можно выполнить запрос:
curl -I https://example.com/xmlrpc.phpЕсли после отключения вы видите 403 или 404, блокировка работает. Если ответ остаётся 200, значит правило не сработало или его перебивает другой уровень защиты.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в теме или mu-plugin | Нужен контроль без лишних плагинов | Можно забыть после смены темы, если не вынести в mu-plugin |
| Плагин безопасности | Нужно закрыть несколько векторов сразу | Дополнительная зависимость и риск конфликтов |
| Правило на уровне сервера | Нужна жёсткая блокировка до WordPress | Нужно аккуратно не задеть легитимные интеграции |
Пошаговое решение через код
Если вам нужен предсказуемый вариант, проще всего отключить XML-RPC через фильтр xmlrpc_enabled. Лучше не вставлять это в functions.php активной темы, а положить в маленький mu-plugin, чтобы правило не исчезло после обновления темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. После этого WordPress перестанет принимать XML-RPC-запросы на уровне ядра.
Если нужен более жёсткий вариант
Когда важно отрезать запросы ещё до загрузки WordPress, можно закрыть xmlrpc.php на уровне веб-сервера. Для Apache это обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика другая, и правило пишется в конфигурации сервера. Там обычно достаточно отдельного location-блока, который возвращает 403. Такой вариант полезен, если сайт регулярно получает мусорный трафик именно на этот файл.
Что делать с Jetpack и внешними сервисами
Самая частая ошибка — отключить XML-RPC, а потом удивляться, что Jetpack перестал синхронизировать данные или мобильное приложение больше не публикует записи. Поэтому сначала проверьте, какие функции реально используются. Если Jetpack нужен только для статистики или отдельных модулей, посмотрите, можно ли отключить зависимые функции и оставить только то, что работает через REST API или обычный вход в админку.
Если у вас есть внешняя интеграция, которая не умеет работать без XML-RPC, не ломайте её вслепую. Сначала зафиксируйте, какие именно методы используются, и только потом решайте, можно ли заменить их на другой канал. Для некоторых старых сервисов это уже невозможно без переработки сценария.
Проверка результата после внедрения
После отключения проверьте не только код ответа, но и реальные сценарии. Это важнее, чем просто увидеть 403.
- откройте
/xmlrpc.phpи убедитесь, что доступ закрыт; - проверьте вход в админку обычным способом;
- если используется Jetpack, протестируйте его ключевые функции;
- посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо стабильно получать отказ; - проверьте, не появились ли ошибки в консоли или в журнале плагина безопасности.
Если у вас есть доступ к WP-CLI, можно дополнительно проверить, что сайт живёт нормально после изменения. Само отключение XML-RPC не требует отдельной команды, но полезно убедиться, что ядро и плагины работают без ошибок после правки конфигурации.
Частые ошибки и как их исправить
Отключили XML-RPC в теме
Если правило лежит в functions.php, оно исчезнет при смене темы. Для технической настройки это плохое место. Перенесите код в mu-plugin или в собственный плагин, если хотите сохранить поведение независимо от темы.
Закрыли файл на сервере, но забыли про интеграции
Если после блокировки перестал работать Jetpack или мобильное приложение, значит вы отключили не только мусорные запросы, но и нужный канал. В этом случае либо возвращайте доступ, либо отказывайтесь от конкретной интеграции и переходите на альтернативу.
Поставили плагин безопасности и не проверили конфликт
Некоторые плагины не просто отключают XML-RPC, а ещё добавляют свои правила в .htaccess или на уровне фаервола. В результате можно получить дублирующиеся блокировки и странные ошибки. Если используете такой плагин, проверьте, не дублирует ли он уже существующее серверное правило.
Ожидали, что это решит все проблемы с безопасностью
Отключение XML-RPC убирает один вектор атаки, но не заменяет обновления, сложные пароли, ограничение попыток входа и контроль прав пользователей. Если сайт уже скомпрометирован, блокировка этого файла не исправит ситуацию.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, лучше закрыть его на уровне сервера и дополнительно оставить фильтр в WordPress. Это не дублирование ради дублирования, а страховка на случай, если одно из правил будет удалено при обновлении конфигурации.
Для сайтов с высоким уровнем мусорного трафика полезно ещё и смотреть access log: иногда проблема не в самом XML-RPC, а в том, что ботам слишком легко достучаться до сайта. В таком случае имеет смысл вместе с блокировкой проверить rate limiting, WAF и общую конфигурацию кэша.
Если вам нужно регулярно чистить сайт от технического мусора, дубликатов и лишних служебных элементов, часть задач можно закрывать через Clearfy Pro, но только если вы понимаете, какие опции реально включаете. Автоматическая чистка без проверки иногда ломает полезные интеграции не хуже ручной ошибки.
В итоге рабочая схема простая: сначала выясняете, нужен ли XML-RPC вообще, потом отключаете его через код или сервер, после этого проверяете Jetpack и внешние клиенты, и только затем оставляете правило в постоянной конфигурации.
