XML-RPC в WordPress до сих пор встречается на живых сайтах, даже если админка давно открывается только через браузер. Проблема в том, что этот интерфейс часто не нужен, но остается включенным по умолчанию и становится лишней точкой входа для брутфорса, пинга и старых интеграций. Отключать его можно не всегда и не вслепую: сначала нужно понять, кто именно его использует.
Когда XML-RPC действительно можно отключить
Если вы не пользуетесь мобильным приложением WordPress, внешними сервисами публикации, Jetpack в старом режиме синхронизации или сторонними клиентами для удаленной публикации, XML-RPC обычно можно убрать без последствий. На большинстве современных проектов эти сценарии давно заменены REST API, прямой работой через админку или интеграциями по API конкретного сервиса.
Но есть нюанс: некоторые плагины и старые интеграции продолжают дергать xmlrpc.php для проверки связи или отправки контента. Поэтому сначала стоит посмотреть логи и понять, есть ли реальные запросы, а не просто отключать все наугад.
Диагностика: кто обращается к xmlrpc.php
Самый простой способ — посмотреть access log веб-сервера. Если у вас Nginx или Apache, ищите запросы к /xmlrpc.php. Часто там видно либо массовые попытки подбора пароля, либо редкие обращения от конкретного сервиса.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если доступа к логам нет, можно временно поставить плагин для просмотра активности или включить логирование на уровне хостинга. Важно не путать единичный запрос от легитимного сервиса с постоянным фоном из сотен обращений в сутки.
Что считать нормальным сценарием
- нет обращений к
xmlrpc.phpв логах за последние дни; - вы не используете удаленную публикацию из внешних клиентов;
- Jetpack, если он установлен, не завязан на старый XML-RPC-сценарий;
- мобильное приложение WordPress не используется для публикации и редактирования.
Как отключить XML-RPC: код, сервер, плагин
Есть три рабочих подхода. Выбор зависит от того, хотите ли вы убрать доступ полностью или только закрыть его для части запросов.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или mu-plugin | Нужен точечный контроль | Не зависит от плагинов безопасности | Нужно следить за обновлениями и местом подключения |
| Правило на сервере | Есть доступ к Nginx/Apache | Блокирует запросы раньше WordPress | Требует доступа к конфигу |
| Плагин безопасности | Нужна быстрая настройка без кода | Просто включить | Лишняя зависимость, не всегда прозрачное поведение |
Вариант 1: отключить через код
Если нужен аккуратный способ без правок сервера, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так решение не потеряется при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC на уровне WordPress. Если кто-то обратится к xmlrpc.php, WordPress вернет отказ в обслуживании запроса.
Вариант 2: закрыть файл на сервере
Если у вас Nginx, можно заблокировать прямой доступ к файлу еще до загрузки WordPress:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный блок полезен тем, что не дает лишней нагрузки на PHP и не оставляет WordPress обрабатывать заведомо ненужные запросы.
Вариант 3: ограничить вместо полного отключения
Иногда полный запрет не подходит. Например, если один внешний сервис еще использует XML-RPC, но вы хотите убрать только опасные методы. Тогда лучше не отключать интерфейс целиком, а пересмотреть сам сценарий интеграции и по возможности перевести его на REST API или другой официальный механизм. Это не всегда быстро, зато безопаснее, чем оставлять старую схему без контроля.
Проверка результата после внедрения
После изменения не ограничивайтесь тем, что страница /xmlrpc.php открывается с ошибкой. Проверьте несколько уровней.
- Откройте
/xmlrpc.phpв браузере — должен быть отказ в доступе или пустой ответ без нормальной обработки WordPress. - Проверьте логи сервера: запросы должны либо не доходить до PHP, либо завершаться кодом отказа.
- Если у вас есть внешние интеграции, протестируйте их вручную: публикацию, синхронизацию, отправку черновиков.
- Проверьте, не выросло ли число 403/401 ошибок в логах после блокировки.
Если вы отключали через код, полезно временно включить мониторинг ошибок и убедиться, что ни один плагин не пытается вызвать XML-RPC как обязательную зависимость.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали интеграцию
Такое бывает, если на сайте остался старый клиент публикации или сервис, который не перевели на REST API. Решение простое: сначала найти источник обращений, потом либо заменить интеграцию, либо оставить доступ только для нужного сценария и закрыть остальное на уровне сервера и безопасности.
Добавили код в активную тему
После обновления темы правило исчезает, и XML-RPC снова включается. Для постоянного решения используйте дочернюю тему или mu-plugin. Это особенно важно на сайтах, где тема обновляется регулярно.
Поставили плагин безопасности и забыли проверить логи
Некоторые плагины отключают XML-RPC вместе с другими функциями, и потом сложно понять, что именно изменилось. Если сайт завязан на интеграции, лучше сначала протестировать на staging-копии, а уже потом переносить на продакшн.
Закрыли файл, но оставили лишнюю обработку в WordPress
Если блокировать только на уровне WordPress, запрос все равно доходит до PHP. На слабом хостинге это лишняя нагрузка. Если есть доступ к конфигу веб-сервера, серверный блок обычно предпочтительнее.
Что еще стоит проверить рядом с XML-RPC
Если вы занимаетесь технической чисткой сайта, не ограничивайтесь одним файлом. На практике рядом часто всплывают и другие точки, которые стоит проверить:
- неиспользуемые REST-эндпоинты сторонних плагинов;
- открытые формы авторизации без защиты от брутфорса;
- лишние пользовательские роли с доступом к редактору;
- старые плагины, которые продолжают обращаться к удаленным API без необходимости;
- публичные endpoints, которые отдают метаданные сайта без пользы для посетителя.
Если нужен более широкий аудит дублей, мусорных функций и технических хвостов, имеет смысл смотреть не только на код, но и на SEO-обвязку. В таких задачах иногда помогает Clearfy Pro, если вам нужен набор точечных настроек для чистки WordPress и удаления лишнего технического шума: https://wpshop.ru/plugins/clearfy.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — это не только про безопасность, но и про снижение лишнего трафика. На сайтах с брутфорсом по xmlrpc.php это может заметно разгрузить логи и уменьшить количество бессмысленных PHP-запросов.
Но не стоит считать это полноценной защитой. Если у вас слабый пароль администратора, отключение XML-RPC не спасет от входа через обычную форму логина. Нужны базовые меры: сложный пароль, ограничение попыток входа, двухфакторная аутентификация и актуальные обновления ядра, темы и плагинов.
Если сайт работает на высоком трафике, лучше тестировать блокировку сначала на staging-копии и только потом переносить на продакшн. Это особенно важно, если у вас есть внешние сервисы публикации, которые не документируют свои зависимости достаточно прозрачно.
