Файл xmlrpc.php до сих пор часто остается открытым на сайтах WordPress, хотя для большинства проектов он не нужен. Проблема в том, что его нельзя просто «выключить» вслепую: через XML-RPC могут работать Jetpack, мобильное приложение WordPress, внешние сервисы публикации и некоторые старые интеграции. Если закрыть доступ без проверки, можно получить неочевидные сбои в редакционном процессе.
Ниже — рабочий сценарий: сначала быстро выясняем, используется ли XML-RPC на сайте, затем отключаем его безопасным способом и проверяем, что ничего лишнего не сломали.
Когда xmlrpc.php действительно стоит отключать
Если сайт не использует удаленную публикацию, мобильное приложение WordPress и старые интеграции, открытый xmlrpc.php чаще всего только увеличивает поверхность атаки. Через него обычно пытаются подбирать пароли, запускать массовые запросы и проверять доступность сайта. Это не значит, что XML-RPC сам по себе «плохой», но на обычном корпоративном или контентном сайте он часто не нужен.
Есть и обратная ситуация: если у вас подключен Jetpack, настроена публикация через внешнюю систему или редакторы работают из мобильного приложения WordPress, отключение нужно делать аккуратно. В таких проектах лучше сначала собрать список зависимостей, а уже потом менять правила доступа.
Диагностика: используется ли XML-RPC на вашем сайте
Самый простой способ — проверить, отвечает ли endpoint и есть ли признаки реального использования. Откройте /xmlrpc.php в браузере: нормальный ответ обычно выглядит как сообщение о том, что сервер принимает только POST-запросы. Это не доказывает, что функция нужна, но подтверждает, что файл доступен извне.
Дальше проверьте логи плагинов и интеграций. Если у вас установлен Jetpack, посмотрите, не завязаны ли на него статистика, публикации или синхронизация. Если есть внешняя CMS, CRM или сервис автопостинга, уточните, не использует ли он XML-RPC вместо REST API.
Что проверить перед отключением
- подключен ли Jetpack и какие модули реально используются;
- работает ли мобильное приложение WordPress у редакторов;
- есть ли внешние сервисы публикации или синхронизации;
- используются ли старые клиенты, которые не умеют работать через REST API;
- есть ли в логах запросы к
xmlrpc.phpот легитимных IP.
Как отключить xmlrpc.php безопасно
Есть несколько способов, и выбор зависит от того, нужен ли вам полный запрет или только защита от типовых атак. Для большинства сайтов достаточно блокировки на уровне веб-сервера. Если нужна более мягкая схема, можно отключить XML-RPC на уровне WordPress и при этом оставить возможность быстро вернуть доступ.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
Правило в .htaccess или конфиге Nginx | Нужен жесткий запрет | Блокирует запросы до загрузки WordPress | Нужно аккуратно редактировать серверную конфигурацию |
| Фильтр в WordPress | Нужен управляемый вариант | Проще откатить | Запрос все равно доходит до WordPress |
| Плагин безопасности | Нужна настройка без кода | Удобно для админов | Добавляет зависимость от плагина |
Вариант 1: отключить через WordPress-код
Если вы хотите оставить контроль внутри темы или небольшого mu-plugin, используйте фильтр xmlrpc_enabled. Это стандартный способ, который не требует выдуманных хуков и работает на обычном WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Лучше не вставлять такой код в активную тему, если сайт часто обновляется или тема может смениться. Практичнее положить его в небольшой mu-plugin, чтобы правило не потерялось при обновлении темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Вариант 2: заблокировать доступ на уровне сервера
Если нужен более жесткий вариант, блокируйте 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. Но если у вас есть легитимная интеграция, сначала убедитесь, что она не использует XML-RPC.
Пошаговое решение без сюрпризов
- Проверьте, используется ли Jetpack, мобильное приложение WordPress или внешняя публикация.
- Посмотрите логи доступа и найдите реальные запросы к
/xmlrpc.php. - Выберите способ блокировки: код в WordPress или правило на сервере.
- Внесите изменение сначала на staging-копии, если она есть.
- Проверьте, не сломались ли публикация, синхронизация и авторизация в сторонних сервисах.
- После проверки перенесите правило на боевой сайт.
Как проверить, что решение сработало
После внедрения откройте /xmlrpc.php в браузере или отправьте тестовый POST-запрос. Если блокировка на уровне сервера настроена правильно, вы должны получить отказ в доступе еще до ответа WordPress. Если использован фильтр xmlrpc_enabled, endpoint обычно перестает принимать запросы и возвращает ошибку доступа.
Дополнительно проверьте логи веб-сервера. После блокировки в них не должно быть успешных обращений к XML-RPC от неизвестных источников. Если у вас был всплеск брутфорса, количество таких запросов обычно заметно падает, но это уже зависит от конкретной атаки и настроек логирования.
Мини-чек-лист проверки
- страница
/xmlrpc.phpнедоступна или возвращает отказ; - Jetpack не потерял связь, если он используется;
- мобильное приложение WordPress не нужно или продолжает работать по плану;
- внешние сервисы публикации не зависят от XML-RPC;
- в логах нет неожиданных ошибок после изменения.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий. Jetpack в некоторых конфигурациях использует XML-RPC для связи с сайтом. Если модуль нужен, не блокируйте endpoint полностью, а сначала проверьте, можно ли перевести нужную интеграцию на другой способ связи. Если нет — оставьте XML-RPC открытым только для доверенных сценариев, но это уже требует отдельной схемы ограничения доступа.
Добавили правило в .htaccess, но сайт на Nginx
.htaccess работает только на Apache и совместимых конфигурациях. На Nginx правило нужно добавлять в конфиг сайта, иначе блокировка просто не сработает. Это одна из причин, почему проверка после внедрения обязательна.
Сломали мобильное приложение редакторов
Если команда публикует материалы через приложение WordPress, отключение XML-RPC может остановить вход и отправку записей. В этом случае лучше заранее перевести редакторов на веб-админку или убедиться, что их рабочий процесс не завязан на старый протокол.
Отключили не там, где нужно
Иногда фильтр добавляют в тему, а потом меняют тему или обновляют ее с потерей правки. Для таких задач надежнее использовать mu-plugin или серверное правило. Так вы не потеряете настройку после очередного обновления.
Безопасность и производительность: что еще имеет смысл сделать
Отключение xmlrpc.php — не замена нормальной защите входа. Если на сайте слабые пароли или нет ограничения попыток входа, брутфорс пойдет через wp-login.php. Поэтому вместе с блокировкой XML-RPC стоит проверить базовые вещи: сложность паролей, двухфакторную авторизацию, актуальность плагинов и тему без лишнего кода.
Если вы регулярно чистите сайт от технического мусора, имеет смысл смотреть и на соседние задачи: отключение неиспользуемых endpoint'ов, удаление старых интеграций, проверка логов и лишних cron-задач. Для сайтов, где много дублей, служебных блоков и лишних настроек, иногда помогает комплексная чистка через Clearfy Pro, но только если вы понимаете, что именно отключаете и зачем.
Главная идея простая: сначала выясняем, нужен ли XML-RPC вообще, потом закрываем его самым подходящим способом и обязательно проверяем реальные сценарии сайта, а не только факт ответа endpoint'а.