XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, публикация через внешние клиенты, интеграции с некоторыми сервисами и старые сценарии удалённого управления сайтом. Поэтому задача здесь не в том, чтобы просто закрыть endpoint, а в том, чтобы сначала понять, нужен ли он вообще, и только потом выключать его точечно.
Если сайт не использует внешнюю публикацию, удалённые клиенты и старые интеграции, XML-RPC обычно можно отключить без последствий. Но если у вас есть подключение через Jetpack, мобильное приложение WordPress, сторонний редактор или сервис синхронизации контента, сначала проверьте зависимость. Иначе получите не «усиление безопасности», а сломанный рабочий процесс.
Когда XML-RPC реально нужен, а когда его можно убрать
XML-RPC — это не просто «лишний файл». Через него WordPress исторически принимал удалённые запросы на публикацию, обновление записей, управление комментариями и часть интеграций. На современных сайтах он часто не нужен, но это надо подтвердить по факту, а не по привычке.
Сценарии, где отключение обычно безопасно
- контент редактируется только из админки WordPress;
- нет мобильного приложения WordPress;
- нет внешних клиентов для публикации постов;
- нет старых интеграций, которые используют
xmlrpc.php; - Jetpack и похожие сервисы не завязаны на XML-RPC в вашей конфигурации.
Сценарии, где сначала нужна проверка
- редакторы публикуют материалы из мобильного приложения;
- используется удалённая публикация через сторонний софт;
- есть интеграции с CRM или контент-сервисами, которые работают через XML-RPC;
- на сайте уже были жалобы, что «не отправляются посты» или «не синхронизируются черновики».
Диагностика: как понять, используется ли xmlrpc.php
Самый надёжный путь — посмотреть реальные обращения к /xmlrpc.php в логах веб-сервера или в аналитике безопасности. Если доступа к логам нет, можно проверить endpoint вручную и оценить, есть ли внешние клиенты в вашей инфраструктуре.
Проверка доступности endpoint
Откройте в браузере или через curl адрес https://example.com/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает использование, но подтверждает, что endpoint открыт.
curl -I https://example.com/xmlrpc.phpЕсли вы видите ответ с кодом 405 или похожее поведение, это нормально для живого endpoint. Если там уже стоит блокировка на уровне сервера или WAF, проверьте, не ломает ли это нужные интеграции.
Что искать в логах
В access-логах ищите запросы к /xmlrpc.php. Важны не только частота, но и источник. Если запросы идут от известных сервисов, мобильных устройств редакторов или интеграций, отключение надо согласовать с владельцами процесса.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам может отличаться. Смысл один: сначала фиксируем, кто и как обращается к endpoint, потом принимаем решение.
Как отключить XML-RPC без плагина
Если зависимостей нет, лучше закрыть XML-RPC кодом в теме или, что правильнее, в небольшом mu-plugin. Так решение не потеряется после обновления темы и не будет зависеть от активной темы оформления.
Вариант через фильтр xmlrpc_enabled
Это самый аккуратный способ: WordPress перестаёт принимать XML-RPC-запросы на уровне логики, а не только через веб-сервер.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код можно положить в файл плагина или mu-plugin. Для mu-plugin создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php, и вставьте туда этот код.
Дополнительная блокировка на уровне сервера
Если нужен более жёсткий барьер, можно закрыть xmlrpc.php на уровне Nginx или Apache. Это полезно, когда endpoint активно сканируют боты, а WordPress-уровня недостаточно.
Для Nginx типовой вариант выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правила в .htaccess, но здесь важно не сломать другие правила безопасности и не дублировать блокировки без необходимости. Если сервером управляет хостинг, сначала проверьте, разрешены ли такие изменения.
Что делать, если XML-RPC нужен только для одного сервиса
Иногда полностью отключать XML-RPC нельзя, но и держать его открытым для всех не хочется. В таком случае лучше не искать «магический» плагин, а ограничить сценарий использования на уровне сервиса или заменить интеграцию на REST API, если это поддерживается.
Практичный вариант: миграция на REST API
Если внешний сервис умеет работать через REST API WordPress, это обычно предпочтительнее. REST API проще контролировать, его легче ограничивать по правам доступа, и он лучше вписывается в современные интеграции. Но миграция зависит от конкретного сервиса: универсального переключателя не существует.
| Подход | Когда подходит | Минус |
|---|---|---|
Фильтр xmlrpc_enabled | Нужно быстро отключить XML-RPC без изменений сервера | Endpoint остаётся доступным на уровне веб-сервера |
| Блокировка в Nginx/Apache | Нужна жёсткая защита от сканирования и ботов | Можно случайно сломать нужную интеграцию |
| Переход на REST API | Есть внешний сервис с поддержкой REST | Требует настройки и проверки прав доступа |
Проверка результата после внедрения
После отключения важно убедиться, что вы не просто «спрятали» проблему, а действительно закрыли ненужный канал и не сломали рабочие сценарии.
- откройте
/xmlrpc.phpв браузере — он не должен принимать рабочие запросы; - проверьте публикацию из админки WordPress;
- если есть мобильное приложение или внешний клиент, попробуйте выполнить тестовое подключение;
- посмотрите логи сервера: запросы к
xmlrpc.phpмогут продолжать приходить, но должны получать отказ; - если использовали WAF или правила сервера, убедитесь, что они не блокируют другие POST-запросы сайта.
Отдельно проверьте уведомления и интеграции, которые могли использовать XML-RPC косвенно. На практике именно они чаще всего «всплывают» после отключения.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про мобильное приложение
Если редакторы публикуют из мобильного приложения WordPress, оно может перестать подключаться. Решение простое: либо вернуть XML-RPC, либо перевести команду на другой способ работы с сайтом.
Закрыли endpoint на сервере, но не проверили логи
Иногда после блокировки администратор видит «всё работает», но интеграция уже молча падает. Проверяйте логи и тестируйте реальные сценарии, а не только главную страницу сайта.
Использовали плагин, который отключает слишком много
Некоторые плагины безопасности умеют отключать XML-RPC вместе с другими функциями, и потом сложно понять, что именно сломалось. Если задача точечная, лучше использовать короткий код или серверное правило, а не большой набор «защиты от всего».
Положили код в тему
Если код отключения XML-RPC находится в теме, при смене темы защита исчезнет. Для таких вещей используйте mu-plugin или обычный плагин, который не зависит от дизайна.
Безопасность и производительность: что имеет смысл учесть
Отключение XML-RPC само по себе не делает сайт «неуязвимым», но убирает один из популярных векторов перебора и лишний публичный endpoint. Это полезно, если сайт не использует удалённую публикацию. При этом не стоит считать XML-RPC единственной точкой риска: обновления ядра, слабые пароли и открытая админка важнее.
Если вы хотите дополнительно усилить сайт, проверьте ещё несколько вещей:
- ограничение попыток входа в админку;
- двухфакторную аутентификацию для администраторов;
- актуальность ядра, тем и плагинов;
- наличие WAF или правил на уровне хостинга;
- отсутствие лишних публичных endpoint, которые сайт не использует.
Если вам нужен более широкий набор технической чистки и отключения лишних функций, можно посмотреть в сторону решений класса Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, что именно отключается, и не полагайтесь на галочки без теста.
Главная проверка здесь простая: если после отключения XML-RPC у вас продолжают работать публикация из админки, интеграции и редакторские сценарии, значит решение внедрено правильно. Если что-то отвалилось — не «дожимайте» блокировку, а возвращайтесь к диагностике и ищите, кто реально использовал этот канал.