XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack, внешняя публикация или старый клиент для блога. Проблема в том, что сам по себе XML-RPC — не зло и не благо, а интерфейс, который либо нужен, либо нет. Если он не используется, его действительно лучше закрыть. Если используется — сначала надо понять, кто именно к нему ходит.
Когда XML-RPC стоит отключать, а когда нет
Отключение оправдано, если сайт живёт только через админку WordPress и обычный фронтенд, а внешних клиентов нет. В таком случае xmlrpc.php становится лишней точкой входа, которую часто сканируют боты. Но если у вас подключены Jetpack, мобильное приложение WordPress, удалённая публикация через старый клиент или интеграция с внешним сервисом, отключение может сломать рабочий процесс.
Типичные сценарии, где XML-RPC ещё нужен
- Jetpack использует XML-RPC для части функций связи с сайтом.
- Мобильное приложение WordPress может публиковать записи через этот интерфейс.
- Старые инструменты для удалённого постинга и синхронизации до сих пор завязаны на
xmlrpc.php. - Некоторые сервисы мониторинга и автоматизации проверяют доступность сайта через XML-RPC.
Диагностика: кто обращается к xmlrpc.php
Перед блокировкой полезно посмотреть, есть ли реальные запросы к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите строки с этим путём и смотрите User-Agent, IP и частоту запросов.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, можно временно включить мониторинг на уровне сервера или использовать плагин безопасности, который показывает обращения к файлам и точкам входа. Но не делайте вывод только по одному запросу бота: важно понять, есть ли легитимные клиенты.
Что проверить до отключения
- Используется ли Jetpack и какие его модули включены.
- Есть ли мобильное приложение WordPress у редакторов.
- Есть ли внешняя публикация через сторонний софт.
- Нет ли интеграций, которые отправляют посты или комментарии через XML-RPC.
- Не завязаны ли на него старые скрипты или cron-задачи.
Как отключить XML-RPC в WordPress
Есть два нормальных пути: через код или через плагин безопасности. Если нужен контроль и предсказуемость, проще добавить небольшой фрагмент в functions.php дочерней темы или в собственный мини-плагин. Если нужен быстрый вариант без правки кода, подойдёт плагин, который умеет отключать XML-RPC на уровне сайта.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код | Прозрачно, без лишних зависимостей | Нужно аккуратно внедрять и тестировать |
| Плагин безопасности | Быстро включить, часто есть дополнительные защиты | Добавляет ещё один слой логики и настроек |
| Блокировка на сервере | Жёстко и эффективно | Нужен доступ к конфигу Nginx/Apache |
Вариант через код
Самый простой способ — отключить XML-RPC фильтром xmlrpc_enabled. Это не ломает WordPress целиком, а только закрывает сам интерфейс.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить XML-RPC, а ещё и вернуть 403 на прямой запрос к xmlrpc.php, можно добавить правило на уровне WordPress. Это не заменяет серверную блокировку, но помогает, если доступ идёт через PHP.
<?php
add_action( 'init', function () {
if ( isset( $_SERVER['REQUEST_URI'] ) && strpos( $_SERVER['REQUEST_URI'], 'xmlrpc.php' ) !== false ) {
status_header( 403 );
exit;
}
} );Для production лучше использовать первый вариант и дополнительно закрыть файл на сервере, если есть такая возможность.
Вариант через сервер
Если сайт на Nginx, можно заблокировать прямой доступ к файлу в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка надёжнее, потому что запрос даже не доходит до WordPress. Но перед этим убедитесь, что вам действительно не нужен XML-RPC для рабочих процессов.
Как проверить, что отключение сработало
Проверка должна быть не формальной, а практической. Откройте /xmlrpc.php в браузере или выполните запрос через curl. Если вы отключали через WordPress-фильтр, обычно увидите ошибку доступа или пустой ответ в зависимости от конфигурации. Если блокировали на сервере, должен возвращаться 403.
curl -I https://example.com/xmlrpc.phpДальше проверьте то, что реально может сломаться:
- вход в админку и публикация записей вручную;
- работу Jetpack, если он установлен;
- мобильное приложение WordPress;
- внешние сервисы, которые отправляют контент на сайт.
Если после отключения всё работает, а в логах больше нет обращений к xmlrpc.php от легитимных клиентов, решение можно считать успешным.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали Jetpack
Это самый частый сценарий. Причина простая: Jetpack использует связь с WordPress.com, и часть функций завязана на XML-RPC. Решение — либо вернуть доступ, либо отключить только те модули Jetpack, которые вам не нужны, и проверить, можно ли обойтись без XML-RPC.
Поставили плагин, который блокирует всё подряд
Некоторые security-плагины отключают XML-RPC вместе с другими REST- или login-защитами. В результате проблема выглядит как «сайт стал безопаснее», но на деле ломается интеграция или отладка. Проверяйте, что именно делает плагин, и не включайте несколько одинаковых защит одновременно.
Заблокировали файл, но в логах всё равно идут запросы
Если запросы продолжаются, значит, блокировка сделана только на уровне WordPress, а не сервера. Это не ошибка, но важно понимать разницу: PHP всё ещё может получать обращения, даже если ответ уже 403. Для снижения нагрузки лучше закрывать доступ на уровне Nginx или Apache.
Ориентируются только на один тест
Один успешный запрос curl не доказывает, что всё безопасно. После отключения нужно проверить реальные сценарии: публикацию, синхронизацию, уведомления и внешние клиенты. Иначе можно обнаружить проблему уже после того, как редактор не сможет отправить материал.
Безопасность и производительность: что ещё имеет смысл сделать
Если вы закрываете XML-RPC ради защиты, не ограничивайтесь одной точкой. Проверьте, не открыт ли лишний доступ к wp-login.php, нет ли слабых паролей у администраторов, и не создаёт ли сайт лишнюю нагрузку из-за брутфорса. XML-RPC часто атакуют вместе с формой входа, поэтому защита должна быть комплексной.
Для сайтов с высокой нагрузкой полезно дополнительно:
- ограничить частоту запросов на уровне сервера или WAF;
- включить нормальный кэш страниц, если сайт в основном статический;
- проверить логи на повторяющиеся обращения к
xmlrpc.phpиwp-login.php; - не ставить несколько плагинов безопасности с одинаковыми функциями.
Если нужен более широкий набор инструментов для чистки сайта, удаления дублей и технической оптимизации, имеет смысл смотреть в сторону решений вроде Clearfy Pro, но только если вам действительно нужны его функции и вы понимаете, что именно включаете.
Когда лучше не отключать XML-RPC полностью
Если у вас есть рабочая интеграция, которая использует XML-RPC, не ломайте её ради абстрактной безопасности. В таких случаях лучше ограничить доступ по IP, усилить аутентификацию и следить за логами. Полное отключение — это хороший вариант только тогда, когда вы уверены, что интерфейс не нужен.
Практический критерий простой: если после отключения никто из команды не заметил разницы в течение нескольких дней работы, значит, XML-RPC, скорее всего, был лишним. Если же сразу всплыли ошибки публикации или синхронизации, возвращайте доступ и ищите точечную защиту вместо грубой блокировки.