XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, мобильное приложение WordPress или внешние сервисы публикации. Проблема не в самом XML-RPC, а в том, что его режут без проверки зависимостей. Ниже — рабочий сценарий: как понять, нужен ли вам этот интерфейс, как отключить его безопасно и как проверить результат.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые внешние клиенты, удалённую публикацию и интеграции, которые ходят через xmlrpc.php, этот файл становится лишней точкой атаки. На практике его отключают ради уменьшения поверхности атаки и снижения шума от брутфорса. Но перед этим важно проверить, не завязаны ли на него сервисы, которые вы реально используете.
Что обычно ломается после отключения
- Jetpack, если он использует XML-RPC для части функций на конкретной конфигурации.
- Мобильное приложение WordPress на старых сценариях подключения.
- Сторонние сервисы автопостинга и синхронизации контента.
- Некоторые плагины резервного копирования и мониторинга, если они настроены через XML-RPC.
Диагностика: используется ли XML-RPC на вашем сайте
Самый простой способ — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в логах безопасности. Если запросы идут регулярно и не от ботов, сначала выясните источник. Для сайта с доступом к серверу полезно проверить логи Nginx или Apache за последние дни.
# Nginx: поиск обращений к xmlrpc.php в access.log
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20
# Apache: аналогично
grep "xmlrpc.php" /var/log/apache2/access.log | tail -n 20Если доступа к серверу нет, можно временно включить логирование в плагине безопасности или посмотреть статистику по заблокированным запросам. Но не делайте вывод только по одному плагину: иногда он видит только часть трафика.
Ещё один практичный тест — открыть https://ваш-домен/xmlrpc.php в браузере. Если интерфейс доступен, это не значит, что он активно используется, но файл точно отвечает. Для проверки интеграций этого недостаточно: нужно отдельно протестировать те сервисы, которые могут зависеть от XML-RPC.
Как отключить XML-RPC: три рабочих подхода
Выбор зависит от того, есть ли у вас доступ к коду и нужен ли более мягкий вариант, чем полная блокировка на уровне сервера.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин безопасности | Быстро, без правок кода | Зависимость от плагина, не всегда прозрачно | Если нужен быстрый результат без разработки |
| Код в теме или MU-плагине | Контроль, минимум лишнего | Нужно аккуратно внедрить | Если есть доступ к файлам и нужен предсказуемый результат |
| Блокировка на сервере | Жёстко и эффективно | Можно случайно сломать нужные запросы | Если XML-RPC точно не нужен и вы контролируете сервер |
Вариант 1: отключить через код WordPress
Это самый понятный путь, если вы ведёте сайт как разработчик и хотите оставить решение в репозитории. Добавьте код в functions.php дочерней темы или, лучше, в небольшой MU-плагин.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает сам XML-RPC на уровне WordPress. Если какой-то плагин или сервис продолжит стучаться в xmlrpc.php, он получит отказ.
Вариант 2: заблокировать файл на сервере
Если вы уверены, что XML-RPC не нужен вообще, можно закрыть доступ на уровне веб-сервера. Это полезно, когда сайт регулярно получает мусорные запросы и вы хотите отсечь их до загрузки WordPress.
# Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>У этого варианта есть важный нюанс: если позже понадобится вернуть интеграцию, нужно будет менять конфигурацию сервера. Поэтому сначала проверьте зависимости, а уже потом закрывайте файл жёстко.
Вариант 3: использовать плагин безопасности
Если у вас уже стоит плагин, который умеет отключать XML-RPC, это допустимый вариант для админов без доступа к коду. Но не стоит ставить отдельный плагин только ради одной галочки, если задача решается одной строкой кода. Лишний плагин — это ещё одна точка обновления и потенциальных конфликтов.
Пошаговое решение без сюрпризов
- Проверьте, используются ли Jetpack, мобильное приложение WordPress или внешние сервисы публикации.
- Посмотрите логи на обращения к
xmlrpc.php. - Сначала отключите XML-RPC через фильтр
xmlrpc_enabled, а не через серверную блокировку. - Протестируйте админку, публикацию записей и все интеграции.
- Если всё стабильно, при необходимости добавьте блокировку на уровне Nginx или Apache.
Такой порядок снижает риск: сначала мягкое отключение, потом жёсткое. Если что-то ломается, вы быстро откатываете одну строку кода, а не правите серверную конфигурацию под давлением.
Как проверить, что решение сработало
После внедрения важно проверить не только сам файл, но и побочные эффекты. Откройте /xmlrpc.php в браузере: при отключении через фильтр WordPress обычно не должен отдавать рабочий ответ для удалённых вызовов. Затем проверьте реальные сценарии.
- Попробуйте опубликовать запись из админки.
- Проверьте вход в мобильное приложение WordPress, если вы им пользуетесь.
- Убедитесь, что Jetpack не потерял связь с сайтом.
- Посмотрите логи сервера: запросы к
xmlrpc.phpмогут продолжаться, но должны получать отказ.
Если у вас есть мониторинг, полезно посмотреть, не выросло ли число ошибок 403/404 после блокировки. Резкий рост может означать, что какой-то внешний сервис всё ещё пытается использовать XML-RPC.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив Jetpack
Это самая частая история. Симптомы появляются не сразу: часть функций продолжает работать, а часть — нет. Решение простое: временно верните фильтр, проверьте настройки Jetpack и только потом принимайте решение о полной блокировке.
Заблокировали файл на сервере и забыли про мобильное приложение
Если редакторы публикуют материалы с телефона, они могут потерять привычный сценарий работы. Перед жёсткой блокировкой обязательно согласуйте это с командой контента.
Смешали несколько способов сразу
Когда XML-RPC отключают и кодом, и через плагин, и через сервер, потом сложно понять, что именно сломало интеграцию. Меняйте только один слой за раз и фиксируйте результат.
Поставили тяжёлый security-плагин только ради XML-RPC
Это лишняя нагрузка и ещё один потенциальный конфликт. Если задача точечная, лучше использовать фильтр в коде или серверное правило.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа и обновления. Если сайт регулярно атакуют, проверьте ещё и лимиты на авторизацию, двухфакторную аутентификацию для админов и актуальность плагинов. На уровне производительности выгода обычно не в ускорении сайта как таковом, а в снижении лишнего мусорного трафика и нагрузки от брутфорса.
Если вы ведёте несколько сайтов, удобнее держать такие правки в MU-плагине, а не в теме. Тогда отключение не исчезнет после смены дизайна. Для типовых задач по чистке дублирующихся сущностей, SEO-микронастройкам и технической гигиене иногда проще использовать специализированные инструменты вроде Clearfy Pro, но для XML-RPC отдельная строка кода обычно надёжнее и прозрачнее.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой MU-плагин можно положить в wp-content/mu-plugins/. Это удобнее, чем править тему: решение не потеряется при обновлении шаблона и не зависит от активной темы.
Что делать, если XML-RPC нужен частично
Иногда отключать его полностью нельзя: например, сайт использует конкретный внешний сервис, который пока не умеет работать иначе. В этом случае не блокируйте всё подряд. Сначала выясните, можно ли заменить интеграцию на REST API или прямую авторизацию через плагин. Если замена невозможна, оставьте XML-RPC включённым, но ограничьте доступ на уровне безопасности и мониторинга.
Главный принцип простой: не отключайте то, что реально используется. Но если зависимостей нет, XML-RPC лучше убрать из публичной поверхности сайта и оставить только те интерфейсы, которые вам действительно нужны.