XML-RPC в WordPress часто отключают не «на всякий случай», а после конкретной проблемы: бот-атаки на xmlrpc.php, лишняя нагрузка на сервер, подозрительные запросы в логах или необходимость закрыть старый интерфейс удалённой публикации. Но у этого файла есть и легитимные сценарии — мобильное приложение WordPress, удалённые клиенты, некоторые интеграции с внешними сервисами. Поэтому задача здесь не просто «вырубить всё», а сделать это так, чтобы не сломать то, что реально используется.
Ниже — рабочие способы отключения XML-RPC, как понять, нужен ли он вам вообще, и как проверить результат после внедрения.
Когда XML-RPC действительно стоит отключить
Если в логах сервера регулярно появляются запросы к /xmlrpc.php, а вы не используете удалённую публикацию, это почти всегда кандидат на отключение. На практике этот файл чаще всего трогают брутфорс-боты и сканеры. Сам по себе XML-RPC не является уязвимостью, но он расширяет поверхность атаки и может создавать лишнюю нагрузку.
Отключать его имеет смысл, если:
- вы не публикуете записи через внешние клиенты и мобильное приложение WordPress;
- не используете сервисы, которым нужен XML-RPC для связи с сайтом;
- на сервере заметны частые обращения к
xmlrpc.php; - нужно убрать лишний входной вектор на сайте с минимальным набором внешних интеграций.
Что может сломаться после отключения
Если у вас есть сторонний сервис, который отправляет записи, комментарии или пинги через XML-RPC, он перестанет работать. Это касается и некоторых старых приложений, которые не перешли на REST API. Поэтому перед изменениями стоит проверить, используется ли этот механизм вообще.
Диагностика: используется ли XML-RPC на сайте
Самый простой способ — посмотреть, есть ли обращения к xmlrpc.php в access-логах веб-сервера. Если вы работаете через панель хостинга, ищите строки с этим путём. Если доступен SSH, можно быстро отфильтровать запросы:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Если логов нет под рукой, проверьте вручную ответ на файл. В норме он существует и отвечает сервером WordPress, а после блокировки должен отдавать ошибку доступа или 404/403 в зависимости от способа отключения:
curl -I https://example.com/xmlrpc.phpЕщё один практический тест — вспомнить, используете ли вы:
- мобильное приложение WordPress для публикации;
- клиенты вроде старых десктопных редакторов;
- внешние сервисы автопостинга, которые не умеют REST API;
- интеграции, где в настройках прямо указан XML-RPC endpoint.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Через плагин безопасности | Нужен быстрый способ без правки кода | Просто включить/выключить, часто есть доп. защита | Зависимость от плагина, лишняя нагрузка, не всегда прозрачная логика |
Через functions.php или mu-plugin | Есть доступ к теме или серверу, нужен точный контроль | Минимум лишнего, легко версионировать | Нужно аккуратно обновлять и тестировать |
| На уровне веб-сервера | Нужно жёстко закрыть доступ до WordPress | Режет запросы раньше PHP, экономит ресурсы | Зависит от конфигурации Nginx/Apache, можно ошибиться в правилах |
Пошаговое решение через код
Если нужен предсказуемый вариант без лишних плагинов, проще всего отключить XML-RPC через фильтр xmlrpc_enabled. Это штатный механизм WordPress, он не требует выдуманных хуков и работает стабильно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Куда вставить код:
- в
functions.phpдочерней темы; - или лучше в небольшой mu-plugin, если не хотите зависеть от темы.
Пример mu-plugin:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант удобен тем, что он не исчезнет после обновления темы. Если у вас несколько сайтов, mu-plugin проще поддерживать централизованно.
Если нужно закрыть доступ ещё раньше
На Nginx можно отдать 403 на уровне конфигурации. Это полезно, если вы хотите не запускать WordPress вообще для этого запроса:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Но здесь важно не перепутать синтаксис под вашу версию Apache. Если сервер старый и использует другую схему прав доступа, сначала проверьте конфигурацию на тестовом стенде.
Проверка результата после внедрения
После отключения не ограничивайтесь открытием главной страницы. Проверьте именно endpoint XML-RPC:
- Откройте
https://ваш-домен/xmlrpc.phpв браузере. - Убедитесь, что ответ не содержит стандартный экран WordPress XML-RPC.
- Проверьте заголовки через
curl -Iили любой HTTP-клиент. - Посмотрите access-логи: запросы должны либо исчезнуть, либо получать отказ.
Если вы отключали через фильтр, а файл всё ещё отвечает как раньше, значит код не загружается. Обычно причина в том, что его добавили не в активную тему, не в дочернюю тему или в файл, который не подключается.
Если закрывали на уровне сервера, но WordPress всё равно обрабатывает запрос, значит правило не сработало или применяется не в том контексте виртуального хоста.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестало работать мобильное приложение
Это ожидаемо. Если приложение или внешний сервис использует XML-RPC, нужно либо вернуть доступ, либо перевести интеграцию на другой способ. Для WordPress это чаще REST API, но не все сторонние сервисы умеют на него переходить без доработки.
Поставили плагин, но нагрузка не снизилась
Некоторые плагины только блокируют функциональность на уровне WordPress, но не режут сам HTTP-запрос на сервере. В результате PHP всё равно стартует, а вы экономите меньше, чем могли бы. Если цель — именно снижение нагрузки, лучше закрывать endpoint на уровне Nginx/Apache.
Добавили код в тему, а после обновления он пропал
Это типичная ошибка. Для технических ограничений лучше использовать дочернюю тему или mu-plugin. Тогда отключение не потеряется после обновления.
Сломали доступ к XML-RPC, но не проверили интеграции
Перед отключением обязательно составьте список внешних сервисов, которые ходят на сайт. Если список неполный, проблема проявится уже после релиза — например, в неотправленных публикациях или ошибках синхронизации.
Практика безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту админки. Если у вас идут атаки на вход, отдельно проверьте:
- ограничение попыток входа;
- двухфакторную аутентификацию для администраторов;
- актуальность ядра, темы и плагинов;
- наличие лишних плагинов, которые тоже расширяют поверхность атаки.
Если вам нужен более широкий набор технических чисток и SEO-оптимизаций, иногда удобнее закрывать несколько проблем одним инструментом. Например, Clearfy Pro закрывает часть типовых задач по чистке WordPress и удалению лишнего технического мусора, но использовать его стоит только там, где вы понимаете, что именно отключаете: Clearfy Pro.
Что проверить после обновлений сайта
Даже если XML-RPC уже отключён, после обновления темы, смены хостинга или переноса сайта стоит повторить короткую проверку:
/xmlrpc.phpпо-прежнему закрыт;- в логах нет всплеска обращений к этому файлу;
- не появились новые интеграции, которым нужен старый endpoint;
- код отключения не был случайно удалён при деплое.
Если у вас есть CI/CD или ручной регламент обновлений, добавьте этот пункт в чек-лист. Это мелкая настройка, но именно такие вещи часто «откатываются» первыми после очередного релиза.