XML-RPC в WordPress до сих пор часто остаётся включённым по умолчанию, хотя многим сайтам он уже не нужен. На практике это лишняя точка входа для брутфорса, часть старых интеграций и источник ложных срабатываний в логах безопасности. Но отключать его вслепую нельзя: если сайт использует Jetpack, мобильное приложение WordPress или внешнюю публикацию через XML-RPC, часть функций перестанет работать.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его безопасно и как проверить, что ничего лишнего не сломалось.
Когда XML-RPC действительно можно отключить
Сначала проверьте, используется ли этот интерфейс вообще. Для обычного корпоративного сайта, блога или лендинга ответ часто отрицательный. XML-RPC нужен только если вы осознанно подключали старые интеграции или публикуете контент из внешних клиентов.
Типичные признаки, что XML-RPC не нужен
- вы не используете мобильное приложение WordPress для публикации;
- Jetpack не подключён или не использует удалённые функции публикации;
- нет сторонних сервисов, которые отправляют записи через XML-RPC;
- в логах безопасности часто видны запросы к
/xmlrpc.php, но реальных сценариев использования нет.
Когда отключать нельзя или нужно сначала проверить интеграции
- сайт синхронизируется со сторонним редактором или CRM через XML-RPC;
- используется Jetpack для удалённой публикации или некоторых функций связи с WordPress.com;
- есть старые мобильные клиенты, которые не переведены на REST API;
- вы не уверены, кто именно обращается к
xmlrpc.php— сначала смотрите логи.
Диагностика: как понять, есть ли обращения к xmlrpc.php
Самый надёжный способ — посмотреть логи веб-сервера и логи безопасности. Если у вас есть доступ к Nginx/Apache access log, найдите запросы к /xmlrpc.php. В панели хостинга это обычно делается через поиск по файлу логов.
grep "xmlrpc.php" access.log | tail -n 50Если запросов много и они идут с разных IP, это не обязательно атака, но повод проверить, не используется ли интерфейс легитимно. Если запросы повторяются с одинаковым шаблоном и без успешной авторизации, XML-RPC часто просто сканируют.
Ещё один практический тест — временно ограничить доступ и посмотреть, не начнут ли жаловаться реальные пользователи или сервисы. Но делать это лучше не на боевом сайте без понимания зависимостей.
Как отключить XML-RPC в WordPress: рабочие способы
Есть три нормальных варианта: через код, через сервер и через плагин. Если нужен предсказуемый контроль, я бы начинал с кода или конфигурации веб-сервера. Плагин удобен, но добавляет ещё одну сущность в стек.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Просто, прозрачно, легко откатить | Нужно не забыть при смене темы | Если нужен быстрый и понятный контроль |
| Правило на сервере | Запросы режутся раньше WordPress | Нужен доступ к Nginx/Apache | Если есть доступ к конфигу сервера |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость, не всегда точечная настройка | Если уже используете security-плагин |
Вариант 1. Отключить XML-RPC через код
Самый простой способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так правило не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить функциональность, а ещё и отдать корректный статус на прямой запрос к файлу, можно добавить блокировку на уровне init:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Первый вариант обычно достаточно. Второй полезен, если вы хотите явно прерывать запросы, но он не заменяет серверную блокировку.
Вариант 2. Закрыть xmlrpc.php на уровне Nginx
Если сайт работает на Nginx, можно сразу отдавать 403 на запросы к файлу xmlrpc.php. Это снижает нагрузку и не даёт запросу доходить до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Для Nginx это стандартная процедура, но на shared-хостинге она может быть недоступна.
Вариант 3. Ограничить доступ через Apache
Если сайт работает на Apache, можно закрыть файл через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Это рабочий вариант, если у вас действительно Apache и хостинг разрешает правила в .htaccess. На Nginx этот фрагмент не сработает.
Вариант 4. Использовать плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, есть ли в нём отдельная опция отключения XML-RPC. Это удобно, когда не хочется править код. Но важно понимать, что не все плагины блокируют запросы одинаково: одни отключают функциональность WordPress, другие просто ограничивают отдельные методы.
Если вы уже используете набор для технической чистки сайта, имеет смысл смотреть в сторону решений, которые закрывают сразу несколько типовых проблем: дубли, мусорные мета-теги, лишние эмодзи, REST-эндпоинты и XML-RPC. Например, в Clearfy Pro есть набор настроек для технической оптимизации и чистки WordPress, что удобно, когда нужно централизованно управлять такими вещами. Ссылка без слеша: Clearfy Pro.
Пошаговое решение без лишнего риска
Если нужен безопасный порядок действий, не начинайте сразу с жёсткой блокировки на сервере. Сначала убедитесь, что XML-RPC не используется, потом отключите его на уровне WordPress, и только затем при необходимости закройте доступ на веб-сервере.
- Проверьте логи на обращения к
/xmlrpc.php. - Сверьте список подключённых интеграций: Jetpack, мобильные клиенты, внешние публикации.
- Добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );в mu-plugin или дочернюю тему. - Проверьте, не сломалась ли авторизация в сторонних сервисах.
- Если всё в порядке, закройте
xmlrpc.phpна уровне Nginx или Apache.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере или через curl. Если доступ закрыт на сервере, вы увидите 403. Если отключение сделано только на уровне WordPress, ответ может отличаться, но запрос не должен выполнять XML-RPC методы.
curl -I https://example.com/xmlrpc.phpДальше проверьте реальные сценарии:
- если используется Jetpack — убедитесь, что он не потерял связь с сайтом;
- если публикация идёт из внешнего клиента — попробуйте создать тестовую запись;
- посмотрите логи безопасности: число запросов к
xmlrpc.phpдолжно либо упасть до нуля, либо перестать доходить до PHP; - проверьте, нет ли ошибок в журнале PHP после изменения.
Если вы закрывали файл на сервере, полезно проверить заголовки ответа и код статуса. Если отключали через WordPress-фильтр, убедитесь, что сайт не отдаёт неожиданные ошибки в админке и не ломает REST API — это разные механизмы.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли Jetpack
Причина обычно в том, что Jetpack использовал удалённое соединение через XML-RPC или зависел от связанных функций. Решение — сначала проверить, какие именно функции нужны, и не закрывать интерфейс без теста. Если Jetpack критичен, блокировать XML-RPC полностью не стоит.
Добавили правило в .htaccess, но ничего не изменилось
Чаще всего сайт работает не на Apache, а на Nginx, или правила в .htaccess не читаются из-за конфигурации хостинга. В этом случае нужно править конфиг сервера, а не WordPress.
Поставили плагин, но запросы всё равно идут
Некоторые плагины отключают только часть методов или только интерфейс в админке. Если цель — именно блокировка атак и лишней нагрузки, лучше закрывать доступ на уровне веб-сервера.
Сломали внешнюю интеграцию и не поняли какую
Так бывает, если до отключения не посмотрели логи. Перед изменениями фиксируйте список сервисов, которые могут обращаться к сайту: мобильное приложение, автопостинг, старые интеграции, мониторинг. Иначе искать причину придётся уже после инцидента.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт безопасным, но убирает одну лишнюю поверхность атаки. Если у вас уже есть проблемы с брутфорсом, имеет смысл смотреть шире: ограничение попыток входа, двухфакторная аутентификация, защита /wp-login.php, актуальные обновления ядра и плагинов.
С точки зрения производительности серверная блокировка лучше, чем отключение только через PHP. Запросы к xmlrpc.php тогда не доходят до WordPress, а значит не тратят ресурсы на загрузку ядра, плагинов и темы.
Если вы ведёте сайт как технический проект, удобно держать такие настройки в одном месте: отдельный mu-plugin для точечных ограничений, конфиг сервера для жёстких блокировок и список интеграций в документации проекта. Это экономит время, когда через полгода кто-то спросит, почему XML-RPC выключен и кто это сделал.