XML-RPC в WordPress часто отключают не «на всякий случай», а когда на сайте начинают регулярно появляться лишние запросы к /xmlrpc.php, брутфорс-атаки или шум в логах. Если внешние сервисы не используют этот интерфейс, его проще закрыть на уровне сервера или через код темы/плагина, чем держать открытым без необходимости.
Ниже — рабочие варианты без установки отдельного плагина: через .htaccess для Apache и через PHP для WordPress. Разберём, когда какой способ уместен, как проверить результат и где чаще всего ошибаются.
Когда XML-RPC действительно стоит отключать
Сначала проверьте, нужен ли он вообще. XML-RPC может использоваться старыми приложениями, некоторыми мобильными клиентами, внешними публикациями и отдельными интеграциями. Если вы не уверены, откройте список подключённых сервисов и посмотрите, есть ли среди них что-то, что работает именно через XML-RPC. Для большинства современных сайтов ответ будет отрицательным.
Отключение имеет смысл, если:
- в логах много запросов к
/xmlrpc.php; - на сайт идут попытки подбора пароля через XML-RPC;
- вы не используете Jetpack, старые мобильные клиенты и внешние публикации через XML-RPC;
- нужно уменьшить поверхность атаки без изменения логики сайта.
Если у вас уже есть рабочий сервис, который зависит от XML-RPC, не закрывайте его вслепую. В таком случае лучше ограничить доступ по IP или закрывать только часть методов, но это уже отдельная задача.
Диагностика: как понять, что XML-RPC у вас открыт и используется
Самый простой способ — проверить ответ на прямой запрос к файлу xmlrpc.php. Если он доступен, сервер обычно отвечает не 404, а сообщением WordPress или кодом, связанным с XML-RPC. Это не доказывает, что интерфейс активно используется, но показывает, что точка входа открыта.
Проверьте также логи веб-сервера. Ищите повторяющиеся обращения к /xmlrpc.php, особенно с разных IP и с короткими интервалами. Если таких запросов много, отключение даст не только безопасность, но и немного разгрузит сервер от мусорного трафика.
grep -R "xmlrpc.php" /var/log/nginx /var/log/apache2 2>/dev/nullЕсли доступа к логам нет, можно временно открыть сайт в браузере и вручную проверить https://example.com/xmlrpc.php. Для закрытого файла вы должны увидеть отказ в доступе или 404, а не стандартный ответ WordPress.
Способ 1: отключить XML-RPC через .htaccess
Этот вариант подходит для Apache или совместимых конфигураций, где .htaccess реально обрабатывается. Он не зависит от темы и не требует загрузки WordPress, поэтому срабатывает рано и отсекает запрос до выполнения PHP-кода.
Добавьте правило в корень сайта, рядом с другими правилами WordPress. Если файл уже содержит блок # BEGIN WordPress, вставляйте правило выше него, чтобы оно не потерялось при автоматической перезаписи.
<Files "xmlrpc.php">
Require all denied
</Files>Если сервер старый и использует Apache 2.2, может встретиться другая форма записи:
<Files "xmlrpc.php">
Order Deny,Allow
Deny from all
</Files>После сохранения проверьте, что запрос к /xmlrpc.php возвращает 403. Это самый надёжный признак, что правило применилось.
Когда .htaccess не подходит
Если сайт работает на Nginx, .htaccess не используется вообще. В этом случае правило нужно писать в конфиг Nginx, а не в WordPress. Если у вас общий хостинг и доступа к конфигу нет, переходите к PHP-варианту ниже или просите поддержку хостинга закрыть файл на уровне веб-сервера.
Способ 2: отключить XML-RPC через PHP
Если вы не хотите трогать конфиг сервера, можно отключить XML-RPC через WordPress-хук. Это удобно, когда доступен только код темы или mu-plugin. Но важно понимать: этот способ срабатывает уже после запуска WordPress, поэтому он менее ранний, чем правило веб-сервера.
Добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Для продакшена mu-plugin обычно надёжнее: он не зависит от темы и не исчезнет при обновлении.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress должен перестать отвечать на XML-RPC-запросы. Если у вас есть сторонний код, который всё ещё пытается обращаться к этому интерфейсу, он начнёт получать ошибку доступа.
Если нужно оставить WordPress, но закрыть только часть рисков
Иногда XML-RPC нужен не целиком, а только для отдельных сценариев. Тогда полное отключение может быть слишком грубым решением. В таком случае лучше сначала проверить, действительно ли сервис можно перевести на REST API или другой способ интеграции. Для большинства новых интеграций это правильнее и безопаснее.
Сравнение подходов: сервер, PHP или плагин
| Способ | Где срабатывает | Плюсы | Минусы |
|---|---|---|---|
.htaccess | На уровне веб-сервера | Ранний отказ, меньше нагрузки, не зависит от WordPress | Только Apache, нужен доступ к конфигу сайта |
| PHP-фильтр | После запуска WordPress | Просто внедрить, не нужен доступ к серверу | Позднее срабатывание, зависит от темы или mu-plugin |
| Плагин безопасности | Внутри WordPress | Удобно для админов без доступа к коду | Лишний плагин, лишняя точка отказа |
Если у вас есть доступ к серверу, лучше закрывать XML-RPC на уровне веб-сервера. Если доступа нет — используйте PHP-фильтр. Плагин имеет смысл только тогда, когда вы сознательно выбираете административный интерфейс вместо кода.
Проверка результата после внедрения
После изменения не ограничивайтесь открытием главной страницы. Проверьте именно точку входа /xmlrpc.php и убедитесь, что сервер отвечает ожидаемо.
- Откройте
https://ваш-домен.ru/xmlrpc.phpв браузере. - Проверьте HTTP-код ответа: для
.htaccessэто обычно 403, для PHP-фильтра — ошибка доступа WordPress. - Посмотрите логи веб-сервера и убедитесь, что новые обращения не проходят дальше.
- Если используете внешние сервисы, протестируйте их отдельно до и после изменения.
Для быстрой проверки из консоли можно использовать curl:
curl -I https://example.com/xmlrpc.phpЕсли вы видите 403 Forbidden, правило на уровне сервера работает. Если ответ идёт от WordPress, значит закрытие сделано только на уровне PHP или не сработало вовсе.
Частые ошибки и как их исправить
Правило добавили не туда
Частая ошибка — вставить блок в конец .htaccess после правил, которые уже переписывают запросы. В результате доступ может не закрыться. Правило для xmlrpc.php лучше ставить выше блока WordPress.
Используют functions.php активной темы
Если отключение сделано в functions.php родительской темы, при обновлении или смене темы код легко потеряется. Для постоянных технических правок лучше использовать дочернюю тему или mu-plugin.
Путают отключение XML-RPC с отключением REST API
Это разные механизмы. Если закрыть XML-RPC, REST API продолжит работать. И наоборот. Не стоит переносить проблемы одного интерфейса на другой без проверки, что именно используется вашим сайтом.
Ломают нужную интеграцию
Если после отключения перестал работать внешний клиент или публикация из стороннего сервиса, значит XML-RPC всё-таки использовался. В этом случае не возвращайте всё как было без анализа: сначала найдите конкретный сервис, затем решите, можно ли заменить его на REST API или другой способ авторизации.
Практические советы по безопасности и производительности
Если вы уже закрываете лишние точки входа, имеет смысл посмотреть и на соседние риски: лишние публичные эндпоинты, старые интеграции, открытые файлы в корне сайта. XML-RPC редко бывает единственной проблемой, но часто является самой заметной.
Для сайтов с высокой нагрузкой лучше закрывать такие вещи на уровне сервера: это уменьшает число PHP-запусков и делает отказ дешевле для хоста. Если сервером управляет хостинг, попросите именно серверное ограничение, а не только WordPress-хук.
Если вам нужен более широкий набор технических настроек без ручного редактирования каждого файла, можно посмотреть в сторону инструментов для чистки и оптимизации WordPress, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но саму задачу отключения XML-RPC всё равно стоит понимать на уровне кода и сервера.
Если после внедрения вы хотите убедиться, что ничего лишнего больше не светится наружу, проверьте логи, заголовки ответа и список публичных эндпоинтов сайта. Это быстрее, чем ловить проблему уже после очередной волны брутфорса.