XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации, старые интеграции или удалённые инструменты управления сайтом. Проблема в том, что это не просто «лишний файл», а интерфейс для удалённого вызова функций WordPress. Если он вам не нужен, его действительно лучше закрыть. Но делать это стоит после проверки, а не вслепую.
Когда XML-RPC реально мешает, а когда его лучше оставить
На практике XML-RPC отключают в трёх сценариях: сайт не использует внешние клиенты для публикации, нет старых интеграций с Jetpack или похожими сервисами, а в логах видны попытки перебора через xmlrpc.php. Если хотя бы один внешний сервис зависит от этого интерфейса, сначала проверьте, можно ли перевести его на REST API или другой способ подключения.
Если вы администрируете обычный корпоративный сайт или магазин на WooCommerce, XML-RPC чаще всего не нужен. Но для сайтов с мобильной публикацией, удалённым редактором или некоторыми плагинами синхронизации его отключение может сломать рабочий процесс. Поэтому сначала диагностика, потом блокировка.
Диагностика: как понять, используется ли XML-RPC
Самый простой способ — проверить, есть ли обращения к /xmlrpc.php в логах веб-сервера или в логах безопасности. Если запросы идут только от ботов и переборщиков, это хороший кандидат на отключение. Если видите обращения от ваших сервисов, не спешите закрывать доступ.
Что проверить перед отключением
- используете ли вы мобильное приложение WordPress;
- есть ли внешние сервисы автопостинга или синхронизации;
- подключён ли Jetpack и какие его функции реально задействованы;
- есть ли в логах легитимные POST-запросы к
xmlrpc.php; - не завязан ли на XML-RPC сторонний плагин резервного копирования или публикации.
Если доступа к логам нет, можно временно открыть страницу https://example.com/xmlrpc.php. Сам по себе ответ «XML-RPC server accepts POST requests only.» ещё не говорит, что интерфейс нужен, но показывает, что файл доступен извне.
Пошаговое решение: как отключить XML-RPC безопасно
Есть несколько рабочих вариантов. Самый надёжный — блокировать доступ на уровне сервера. Если нужен более мягкий сценарий, можно отключить XML-RPC через код. Для большинства проектов я бы начинал именно с кода: так проще откатить изменение и проверить побочные эффекты.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Быстро откатить, не зависит от панели хостинга | Нужно следить за обновлениями и местом размещения |
| .htaccess / nginx | Режет запросы раньше WordPress, меньше нагрузка | Нужно аккуратно править конфиг сервера |
| Плагин безопасности | Удобно для неразработчика | Лишняя зависимость, иногда избыточные функции |
Вариант 1: отключить XML-RPC через код
Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот фильтр отключает сам механизм XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Если вам нужно не отключать полностью, а только ограничить отдельные методы, можно использовать фильтр xmlrpc_methods, но это уже более точечная настройка и требует понимания, какие именно вызовы вам нужны.
Вариант 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. Но перед применением убедитесь, что у вас нет сервисов, которым этот файл нужен.
Вариант 3: использовать плагин безопасности
Если вы не хотите править конфиги вручную, можно отключить XML-RPC через плагин, который уже отвечает за hardening. Но не ставьте отдельный плагин только ради одной галочки, если тот же эффект можно получить кодом или серверным правилом. Чем меньше лишних расширений, тем проще сопровождение.
Как проверить, что отключение сработало
После внесения изменений проверьте не только страницу в браузере, но и реальные ответы сервера. Это важнее, чем просто отсутствие ошибок в админке.
- Откройте
/xmlrpc.phpв браузере. - Убедитесь, что сервер возвращает
403 Forbiddenили другой запретительный ответ, если вы блокировали доступ на уровне сервера. - Если использовали фильтр
xmlrpc_enabled, проверьте, что внешние клиенты не могут подключиться. - Посмотрите логи ошибок и access log: обращений к
xmlrpc.phpдолжно стать меньше или они должны получать отказ. - Проверьте мобильное приложение WordPress, Jetpack и другие интеграции, если они у вас есть.
Если у вас есть доступ к командной строке, можно быстро проверить ответ так:
curl -I https://example.com/xmlrpc.php
Для отключённого файла вы должны увидеть отказ в доступе или иной запретительный статус в зависимости от способа блокировки.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо, если вы используете функции, завязанные на XML-RPC. Решение простое: либо вернуть доступ, либо перевести нужный сценарий на другой способ подключения. Не пытайтесь «починить» это случайными исключениями, пока не поймёте, какой именно модуль Jetpack вам нужен.
Добавили правило в .htaccess, но доступ всё равно есть
Частая причина — сайт работает не на Apache, а на nginx, либо правило стоит не в том месте. Проверьте стек хостинга и убедитесь, что конфиг действительно применяется. На nginx блокировка в .htaccess не сработает вообще.
Сломали мобильную публикацию
Если вы публикуете посты из мобильного приложения WordPress, XML-RPC может быть частью этого сценария. В таком случае лучше не отключать его полностью, а ограничить только ненужные методы или закрыть доступ по IP, если это оправдано инфраструктурой.
Поставили несколько плагинов безопасности с одинаковой функцией
Это не усиливает защиту, а часто создаёт конфликты. Один плагин может блокировать XML-RPC, другой — пытаться его «проверять», третий — писать ложные срабатывания в лог. Для такой задачи лучше выбрать один способ: код, серверное правило или один security-плагин.
Практика безопасности и производительности
Отключение XML-RPC не делает сайт «неуязвимым», но убирает один из популярных векторов атак и снижает шум в логах. Если на сайте уже есть защита от bruteforce, ограничение доступа к xmlrpc.php хорошо дополняет её, а не заменяет.
Для производительности эффект обычно небольшой, но на сайтах с постоянным мусорным трафиком он заметен косвенно: меньше бесполезных запросов, меньше нагрузки на PHP и базу, меньше записей в логах. Если у вас ещё и есть лишние сервисы, которые ходят в XML-RPC по старой схеме, лучше заранее перевести их на более современный способ интеграции.
Если вы ведёте сайт как проект, а не как набор случайных плагинов, полезно держать такие настройки в одном месте: mu-plugin для точечных ограничений, серверные правила для жёсткой блокировки и отдельный чек-лист для проверок после обновлений. Это проще, чем потом искать, кто именно снова открыл доступ к xmlrpc.php.
Чек-лист перед выкладкой на продакшн
- проверили, нужен ли XML-RPC хотя бы одному сервису;
- выбрали способ отключения: код или серверное правило;
- сделали резервную копию перед изменениями;
- проверили ответ
/xmlrpc.phpпосле правки; - протестировали Jetpack, мобильное приложение и внешние интеграции;
- посмотрели логи на предмет ошибок и неожиданных отказов.
Если после отключения ничего не сломалось, значит, вы убрали лишний вход без побочных эффектов. Если что-то перестало работать, не возвращайте всё назад автоматически — сначала найдите конкретную зависимость и решите, нужна ли она вообще.