XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack или внешняя публикация через сторонний сервис. Проблема в том, что XML-RPC — это не только лишняя поверхность атаки, но и реальный транспорт для некоторых интеграций. Поэтому правильный подход здесь не «вырубить всё», а сначала понять, кто именно его использует, и только потом закрывать доступ.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые внешние клиенты, публикацию через сторонние сервисы и Jetpack-функции, завязанные на XML-RPC, то этот интерфейс обычно можно закрыть без потерь. Особенно это актуально для сайтов, где в логах видны массовые запросы к /xmlrpc.php, попытки брутфорса или pingback-атаки.
Но если у вас есть хотя бы один из этих сценариев, отключение нужно делать аккуратно:
- мобильное приложение WordPress для публикации и редактирования;
- Jetpack, если он использует XML-RPC для части функций;
- внешние CMS, скрипты или сервисы автопостинга;
- старые интеграции, которые не умеют работать через REST API.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями проверьте, есть ли реальные обращения к файлу. Самый простой способ — посмотреть access-логи веб-сервера или логи в панели хостинга. Ищите запросы к /xmlrpc.php и оцените, это единичные обращения или постоянный поток.
Что искать в логах
Если в логах много POST-запросов к xmlrpc.php с одинаковых IP или с разными IP, это уже повод ограничить доступ. Если же запросы идут с адресов ваших сервисов или от авторизованных пользователей, сначала проверьте, чем именно они вызваны.
Полезно также временно включить аудит на уровне веб-сервера или WAF, если он у вас есть. Это поможет понять, не ломается ли публикация из внешнего клиента после отключения.
Как отключить XML-RPC безопасно
Есть три рабочих подхода: через плагин безопасности, через код и через веб-сервер. Для большинства сайтов самый предсказуемый вариант — код в functions.php дочерней темы или в небольшом mu-plugin. Плагин удобен, но добавляет зависимость. На уровне веб-сервера можно закрыть доступ раньше, чем WordPress начнёт обрабатывать запрос.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро включить, не нужен код | Дополнительная зависимость, иногда лишняя нагрузка |
| Код | Прозрачно, легко контролировать | Нужно аккуратно внедрить и не сломать интеграции |
| Веб-сервер | Режет запросы раньше WordPress | Требует доступа к конфигу и понимания окружения |
Вариант 1: отключить XML-RPC через код
Если вы уверены, что XML-RPC не нужен, добавьте фильтр в functions.php дочерней темы или в отдельный mu-plugin:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой способ отключить сам механизм. После этого WordPress перестанет принимать XML-RPC-запросы, но файл xmlrpc.php физически останется доступен. Для большинства задач этого достаточно.
Вариант 2: заблокировать доступ на уровне сервера
Если нужен более жесткий вариант, можно закрыть сам файл. Для Apache это обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика зависит от конфигурации, но смысл тот же: вернуть 403 на запросы к /xmlrpc.php. Такой способ полезен, если сайт регулярно получает мусорный трафик именно на этот endpoint.
Вариант 3: ограничить, а не отключать полностью
Если XML-RPC нужен только для одного сервиса, лучше не отключать его глобально. В этом случае можно ограничить доступ по IP на уровне сервера или закрыть его через WAF, оставив только доверенные адреса. Это рабочий компромисс, когда полностью перейти на REST API пока нельзя.
Проверка результата после внедрения
После изменения конфигурации проверьте не только факт блокировки, но и побочные эффекты. Откройте https://ваш-домен/xmlrpc.php в браузере: если доступ закрыт корректно, вы должны увидеть отказ в доступе или пустой ответ, а не рабочую страницу WordPress.
Дальше проверьте реальные сценарии:
- вход в админку и публикация записей работают как обычно;
- мобильное приложение WordPress не теряет связь с сайтом;
- Jetpack не показывает ошибок подключения, если он используется;
- внешние сервисы автопостинга не начали сыпать ошибками.
Если у вас есть мониторинг логов, убедитесь, что запросы к xmlrpc.php больше не доходят до PHP-обработки или получают стабильный отказ.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали публикацию из приложения
Это типичная ситуация, когда перед внедрением не проверили зависимости. Решение простое: временно вернуть XML-RPC, найти конкретный сервис, который его использует, и либо перевести его на REST API, либо ограничить доступ точечно.
Поставили плагин, но запросы всё равно идут
Некоторые плагины только отключают функциональность на уровне WordPress, но не блокируют сам HTTP-запрос. В результате endpoint всё ещё отвечает, а нагрузка и мусорные обращения остаются. Если цель — именно закрыть поверхность атаки, лучше дополнить решение правилом на веб-сервере.
Закрыли xmlrpc.php, но забыли про логику интеграций
Старые интеграции могут не падать сразу, а начинать повторять запросы и создавать лишнюю нагрузку. После блокировки обязательно посмотрите ошибки в логах и очереди задач, если они есть.
Чек-лист перед отключением XML-RPC
- Проверить, используется ли мобильное приложение WordPress.
- Проверить Jetpack и другие подключенные сервисы.
- Посмотреть логи на обращения к
/xmlrpc.php. - Выбрать способ блокировки: код, сервер или ограничение по IP.
- После внедрения протестировать публикацию, авторизацию и внешние интеграции.
- Проверить, что endpoint действительно недоступен извне.
Что делать, если XML-RPC нужен, но его атакуют
Если полностью отключить XML-RPC нельзя, не оставляйте его без защиты. Минимум — ограничьте доступ по IP, включите rate limiting на уровне хостинга или CDN и проверьте, не помогает ли WAF отсекать массовые запросы. В таких сценариях полезнее не «ломать» рабочую интеграцию, а сузить окно доступа до доверенных клиентов.
Если вы регулярно чистите сайт от лишних технических хвостов и дубликатов, имеет смысл держать под рукой инструменты для SEO- и техаудита. Например, в Clearfy Pro есть набор функций для технической чистки WordPress, но даже с плагином всё равно важно понимать, что именно вы отключаете и зачем: автоматическая кнопка не заменяет проверку зависимостей.