XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильные приложения, удалённая публикация и часть интеграций. На практике задача не в том, чтобы просто закрыть endpoint, а в том, чтобы понять, кто именно им пользуется, и выбрать способ блокировки без лишних побочных эффектов.
Ниже разберём рабочие варианты: через PHP, через серверную конфигурацию и через плагин. Сразу покажу, как проверить, что отключение реально сработало, и где чаще всего ломают сайт.
Когда XML-RPC действительно стоит отключать
XML-RPC нужен для удалённого доступа к сайту: публикации записей, работы некоторых клиентов и сервисов, старых интеграций. Если вы не используете эти сценарии, endpoint /xmlrpc.php становится лишней поверхностью атаки. Его часто перебирают при попытках брутфорса и DDoS на уровне запросов.
Но отключать его без проверки не стоит, если у вас есть:
- Jetpack и связанные с ним функции;
- мобильное приложение WordPress;
- внешние сервисы публикации или мониторинга;
- старые интеграции, которые до сих пор ходят через XML-RPC, а не REST API.
Диагностика: кто использует XML-RPC сейчас
Перед блокировкой проверьте логи веб-сервера и запросы к xmlrpc.php. Если вы видите регулярные обращения от одного и того же сервиса, сначала выясните, можно ли перевести его на REST API или другой способ интеграции.
Минимальный чек-лист диагностики:
- посмотреть access log за последние 7–14 дней;
- найти обращения к
/xmlrpc.php; - проверить, нет ли ошибок в Jetpack или мобильном приложении после тестовой блокировки;
- убедиться, что сайт не использует внешнюю публикацию через XML-RPC.
Если доступа к логам нет, можно временно проверить endpoint вручную. Ответ на запрос не всегда означает, что функция вам нужна, но это уже повод копать дальше.
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает 200 или 405, endpoint доступен. Это ещё не проблема само по себе, но значит, что блокировку нужно делать осознанно, а не «по ощущениям».
Как отключить XML-RPC в WordPress через PHP
Самый предсказуемый способ — убрать саму возможность обработки XML-RPC на уровне WordPress. Для этого добавляют фильтр xmlrpc_enabled в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это простой и понятный вариант, но он не закрывает сам файл на уровне веб-сервера. Обычно этого достаточно, если вы хотите именно отключить функциональность WordPress, а не просто отдать 403 на запрос.
Когда лучше использовать mu-plugin
Если тема может меняться, не вносите такую настройку в functions.php. Для технических ограничений безопаснее использовать mu-plugin: он не зависит от темы и не исчезнет после обновления шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.
Как отключить XML-RPC через .htaccess
Если сайт работает на Apache или LiteSpeed с поддержкой .htaccess, можно заблокировать прямой доступ к файлу на уровне сервера. Это полезно, когда вы хотите срезать лишние запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache 2.2 иногда встречается синтаксис через Order и Deny, но на современных серверах лучше использовать Require all denied. Если у вас Nginx, этот способ не сработает — там правило нужно писать в конфиге сервера.
Что выбрать: PHP, .htaccess или плагин
| Способ | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| PHP-фильтр | Просто, прозрачно, работает внутри WordPress | Файл остаётся доступным на уровне сервера | Когда нужно отключить функциональность без правок сервера |
| .htaccess | Режет запросы раньше, чем загрузится WordPress | Только Apache/LiteSpeed, нужен доступ к конфигу | Когда надо уменьшить лишнюю нагрузку и закрыть endpoint |
| Плагин | Быстро включить без кода | Лишняя зависимость, иногда больше, чем нужно | Когда нет доступа к коду и серверу |
Если у вас уже стоит плагин для технической чистки и SEO, например Clearfy Pro, проверьте, не дублирует ли он эту настройку. Две одинаковые блокировки обычно не вредят, но усложняют диагностику, когда что-то идёт не так.
Проверка результата после внедрения
После отключения нужно проверить не только код ответа, но и реальные сценарии. Самая частая ошибка — увидеть, что xmlrpc.php больше не отвечает, и на этом остановиться.
Проверяйте по шагам:
- Откройте
https://site.ru/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что сервер возвращает
403или WordPress сообщает, что XML-RPC отключён. - Проверьте вход в мобильное приложение WordPress, если вы им пользуетесь.
- Посмотрите, не появились ли ошибки в Jetpack или внешних сервисах публикации.
- Проверьте логи на повторяющиеся обращения к
xmlrpc.phpпосле блокировки.
Если endpoint закрыт правильно, повторные запросы должны либо получать отказ на уровне сервера, либо не доходить до WordPress. Если же вы видите обычный ответ WordPress, значит правило не применилось или применяется не там, где вы ожидали.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали Jetpack
Это типичная ситуация, когда блокировку включили без проверки зависимостей. Решение простое: либо вернуть XML-RPC, либо перевести нужную функцию Jetpack на другой механизм, если он доступен. Сначала тестируйте на staging, потом на продакшене.
Добавили правило в .htaccess, но оно не работает
Причина обычно одна из трёх: сайт не на Apache/LiteSpeed, правило вставили не в тот файл, либо конфигурация сервера игнорирует .htaccess. В Nginx нужно править server block, а не WordPress-файлы.
Отключили через PHP, но endpoint всё ещё отвечает
Фильтр xmlrpc_enabled отключает обработку внутри WordPress, но сам файл может быть доступен. Если вам нужно именно закрыть доступ, добавьте серверное правило. Иначе сканеры всё равно будут видеть endpoint как существующий.
Сломали интеграцию, о которой забыли
Такое бывает, если сайт давно живёт и к нему подключён старый сервис. Перед блокировкой полезно пройтись по списку интеграций, вебхуков и внешних приложений. Если интеграция критична, лучше сначала перевести её на REST API или другой поддерживаемый способ.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC само по себе не заменяет защиту входа. Если у вас идёт брутфорс на wp-login.php, параллельно стоит проверить:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- обновления ядра, тем и плагинов;
- логи на повторяющиеся 401/403 и подозрительные POST-запросы.
Если цель — сократить технический шум, не перегружайте сайт лишними плагинами. Для точечных задач лучше один понятный mu-plugin или серверное правило, чем набор расширений, которые дублируют друг друга и мешают отладке.
В итоге рабочая схема обычно такая: сначала проверяете зависимости, затем отключаете XML-RPC через PHP или сервер, после чего подтверждаете результат запросом к /xmlrpc.php и тестом всех внешних подключений. Это занимает немного времени, но избавляет от ситуации, когда защита включена ценой сломанного сайта.