XML-RPC в WordPress часто отключают «на всякий случай», а потом неожиданно ломают мобильное приложение, внешнюю публикацию или старую интеграцию с сервисом мониторинга. На практике задача не в том, чтобы просто убрать доступ к xmlrpc.php, а в том, чтобы понять, используется ли он вообще, и закрыть только лишнее.
Если сайт не подключён к Jetpack, не принимает публикации из сторонних клиентов и не использует legacy-интеграции, XML-RPC обычно можно отключить. Но делать это лучше после короткой диагностики: иначе можно получить ложное ощущение безопасности и одновременно сломать рабочий сценарий.
Когда XML-RPC реально мешает
Чаще всего его отключают из-за двух причин: лишняя поверхность атаки и шум в логах. Файл xmlrpc.php часто сканируют боты, а при слабой защите он становится целью перебора логинов через метод system.multicall. Но сам по себе факт запросов к XML-RPC ещё не означает проблему — важно, есть ли у вас рабочие зависимости.
Что обычно использует XML-RPC
- Jetpack и некоторые его функции;
- мобильное приложение WordPress в старых сценариях;
- внешние клиенты для публикации;
- сервисы, которые отправляют пингбеки или трекают публикации через XML-RPC;
- устаревшие интеграции, написанные до массового перехода на REST API.
Диагностика перед отключением
Сначала проверьте, есть ли реальные обращения к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный путь. Ищите запросы к файлу и смотрите, кто их делает: бот, внешний сервис или ваш собственный IP.
# Пример для nginx access.log
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20
# Пример для Apache access.log
grep "xmlrpc.php" /var/log/apache2/access.log | tail -n 20Если логов нет, можно временно поставить правило на уровне сервера или использовать плагин безопасности с журналированием. Но не делайте вывод только по отсутствию ошибок в админке: XML-RPC может использоваться тихо, без заметных симптомов.
Быстрый чек-лист перед изменениями
- проверить, используется ли Jetpack;
- проверить мобильное приложение WordPress, если им кто-то реально пользуется;
- посмотреть логи на обращения к
xmlrpc.php; - сверить внешние сервисы публикации и мониторинга;
- убедиться, что REST API уже закрывает нужные сценарии.
Как отключить XML-RPC безопасно
Есть три рабочих подхода: через плагин, через код и на уровне сервера. Выбор зависит от того, насколько вам нужен контроль и есть ли доступ к конфигурации хостинга.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правок темы | Лишняя зависимость, иногда скрывает проблему, а не решает её | Если нужен временный или управляемый через админку вариант |
| Код | Прозрачно, без лишних плагинов | Нужно аккуратно разместить в mu-plugin или дочерней теме | Если вы ведёте сайт как проект и хотите предсказуемое поведение |
| Сервер | Самый жёсткий и быстрый блок | Нужно понимать конфиг nginx/Apache | Если XML-RPC точно не нужен и нужен минимальный оверхед |
Вариант 1: отключить через код
Самый практичный способ — добавить фильтр в functions.php дочерней темы или в mu-plugin. Так вы не зависите от настроек стороннего плагина и можете быстро вернуть всё назад.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC на уровне WordPress. Если кто-то обратится к xmlrpc.php, WordPress вернёт отказ, а не выполнит методы.
Вариант 2: закрыть файл на уровне сервера
Если вы уверены, что XML-RPC не нужен вообще, можно заблокировать доступ ещё до запуска WordPress. Это полезно, когда сайт получает много мусорных запросов и вы хотите снизить нагрузку.
# nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache подход будет другим, но логика та же: запретить прямой доступ к файлу. Здесь важно не перепутать блокировку XML-RPC с блокировкой REST API — это разные механизмы, и отключать их вместе без причины не стоит.
Вариант 3: использовать плагин безопасности
Если у вас уже стоит плагин, который умеет отключать XML-RPC, это допустимо. Но проверьте, что он делает именно блокировку, а не только маскирует часть методов. Для сайтов, где важна минимизация дублей и техническая чистка, иногда удобнее держать такие вещи в одном инструменте. Например, в Clearfy Pro есть набор настроек для технической оптимизации и отключения лишнего, но использовать его стоит только если вам действительно нужен такой централизованный контроль: Clearfy Pro.
Что может сломаться после отключения
Самая частая ошибка — отключить XML-RPC и не проверить внешние сценарии. Визуально сайт может работать нормально, но интеграция перестанет публиковать записи или отправлять уведомления. Особенно это заметно на проектах, где WordPress давно живёт с «наследием» из старых сервисов.
- Jetpack может потерять часть функций;
- внешний клиент публикации перестанет авторизоваться;
- старые сервисы мониторинга могут перестать отправлять pingback;
- автоматизация через legacy-скрипты может вернуть ошибки 403 или 405.
Как проверить, что решение сработало
Проверка должна быть не только технической, но и функциональной. Сначала убедитесь, что файл больше не отвечает успешно, затем проверьте, не пострадали ли нужные интеграции.
Проверка через браузер или curl
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, ожидайте 403 Forbidden или другой отказ в доступе. Если отключали через фильтр WordPress, ответ тоже не должен быть успешным для методов XML-RPC.
Проверка в админке и внешних сервисах
- выполнить вход в WordPress обычным способом;
- проверить публикацию записи через нужный внешний инструмент, если он у вас есть;
- посмотреть логи на повторные обращения к
xmlrpc.php; - убедиться, что нет новых ошибок в журнале PHP.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Если Jetpack нужен, не рубите XML-RPC вслепую. Сначала проверьте, какие функции реально используются. Иногда достаточно отключить только ненужные методы или заменить сценарий на REST API.
Заблокировали не тот файл
Иногда путают xmlrpc.php с wp-login.php или с REST-эндпоинтами. Это разные точки входа. Если после правок сломался вход в админку или API, откатите изменения и проверьте конфиг ещё раз.
Использовали плагин, который отключает слишком много
Некоторые плагины безопасности одним переключателем закрывают XML-RPC, REST API и даже части админки. Это удобно до первого конфликта. Если вам нужен только один механизм защиты, лучше использовать точечное правило, а не «комбайн» без понимания последствий.
Не проверили логи после внедрения
Если запросы к xmlrpc.php продолжают идти, это не всегда проблема. Но если вы видите ошибки от реального сервиса, значит блокировка задела рабочий сценарий. В таком случае возвращайте доступ только для нужной интеграции или переводите её на REST API.
Практика по безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа. Если у вас слабый пароль, нет ограничений по попыткам входа и не настроен WAF, атаки пойдут через другие точки. Поэтому лучше рассматривать XML-RPC как один из слоёв, а не как единственную меру.
- используйте двухфакторную аутентификацию, если она доступна;
- ограничьте попытки входа;
- держите WordPress, тему и плагины в актуальном состоянии;
- проверяйте логи после любых изменений в безопасности;
- не отключайте REST API без отдельной причины.
Если задача — не только закрыть XML-RPC, но и убрать лишние технические хвосты на сайте, имеет смысл смотреть на более широкий аудит: дубли, автозагрузку, мусорные скрипты, неиспользуемые функции. Но каждое такое изменение нужно проверять отдельно, а не включать «оптимизацию» пакетом без тестов.