XML-RPC в WordPress часто оставляют включённым по умолчанию, а потом удивляются лишним запросам к /xmlrpc.php, попыткам подбора паролей и шуму в логах. Если сайт не использует внешние клиенты, старые мобильные сценарии или интеграции, этот интерфейс обычно только расширяет поверхность атаки.
Ниже — рабочие способы закрыть XML-RPC, не ломая сайт, и проверить, что ограничение действительно сработало. Разберём варианты для Apache, nginx и самого WordPress, а также типичные ошибки, из-за которых защита выглядит включённой, но фактически не работает.
Когда XML-RPC действительно стоит отключать
Сначала проверьте, есть ли у вас реальная зависимость от XML-RPC. Если сайт редактируется только через админку, а внешние сервисы не подключены, отключение обычно безопасно. Если же вы используете старые приложения, Jetpack или сторонние публикации через XML-RPC, сначала протестируйте на staging-копии.
Типичные признаки, что XML-RPC не нужен
- в логах много запросов к
/xmlrpc.phpс разных IP; - сайт не использует внешние клиенты для публикации;
- нет интеграций, завязанных именно на XML-RPC;
- в админке не замечали легитимных обращений к этому endpoint.
Диагностика: как понять, что проблема именно в XML-RPC
Если на сайт идут попытки bruteforce, в access-логах часто видно повторяющиеся POST-запросы к /xmlrpc.php. В отличие от обычной формы входа, XML-RPC позволяет атакующему делать массовые попытки в одном запросе через метод system.multicall. Это не единственный вектор атаки, но довольно частый.
Проверить наличие endpoint можно и без логов. Откройте https://ваш-домен/xmlrpc.php. В ответе WordPress обычно возвращает сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это значит, что файл доступен извне.
Если у вас включён WAF или CDN, полезно посмотреть, не блокируется ли уже этот путь на уровне инфраструктуры. Иногда админ думает, что XML-RPC закрыт, хотя на деле его режет только внешний фильтр, а сам WordPress остаётся доступным напрямую.
Как отключить XML-RPC: рабочие варианты
Выбор зависит от того, где проще и надёжнее закрыть endpoint. Если есть доступ к серверной конфигурации, лучше ограничить запросы на уровне веб-сервера. Если нужен быстрый вариант без правок nginx или Apache, можно добавить фильтр в WordPress. Для большинства сайтов я бы начинал именно с серверного уровня.
Вариант 1: блокировка через .htaccess на Apache
Этот способ подходит, если сайт работает на Apache и у вас есть доступ к .htaccess. Блокировка отдаёт 403 ещё до загрузки WordPress, что экономит ресурсы.
<Files xmlrpc.php>
Require all denied
</Files>Если сервер старый и использует Apache 2.2, вместо Require all denied может понадобиться:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Вариант 2: блокировка через nginx
Для nginx лучше закрыть путь в конфигурации сайта. Это надёжнее, чем пытаться ловить запросы уже в PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После правки конфигурации не забудьте проверить синтаксис и перезагрузить nginx. Иначе правило останется только в файле, но не начнёт работать.
Вариант 3: отключение через код WordPress
Если серверную конфигурацию менять неудобно, можно отключить XML-RPC через хук xmlrpc_enabled. Это не самый ранний уровень защиты, но для многих проектов его достаточно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код лучше добавлять в дочернюю тему или в собственный мини-плагин, а не прямо в файлы родительской темы. Тогда правка не потеряется после обновления.
Вариант 4: точечная блокировка методов XML-RPC
Иногда нужно не отключать XML-RPC полностью, а убрать только опасные методы. Например, если у вас есть зависимость от части функциональности, но вы хотите ограничить массовый подбор через system.multicall.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['system.multicall'] );
return $methods;
} );Этот вариант компромиссный: он уменьшает риск, но не убирает endpoint целиком. Если интеграций нет, лучше закрыть доступ полностью.
Сравнение подходов: что выбрать на практике
| Способ | Где работает | Плюсы | Минусы |
|---|---|---|---|
| .htaccess / nginx | На уровне веб-сервера | Ранний отказ, меньше нагрузки | Нужен доступ к конфигу |
Хук xmlrpc_enabled | В WordPress | Быстро внедрить, не нужен доступ к серверу | Запрос уже доходит до PHP |
| Отключение отдельных методов | В WordPress | Можно сохранить часть совместимости | Не закрывает endpoint полностью |
Пошаговое решение для большинства сайтов
- Проверьте, не завязан ли сайт на XML-RPC через внешние клиенты или интеграции.
- Если зависимостей нет, закройте
/xmlrpc.phpна уровне nginx или Apache. - Если серверные правки недоступны, добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );. - Очистите кэш, если используется page cache или CDN.
- Проверьте ответ сервера на запрос к
/xmlrpc.php.
Если сайт под нагрузкой или часто сканируется ботами, разумно сочетать блокировку на сервере с ограничением попыток входа в админку. XML-RPC — не единственный путь атаки, а только один из самых шумных.
Как проверить, что защита сработала
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и через curl. Если блокировка сделана правильно, вы должны увидеть 403 или другой отказ на уровне сервера, а не стандартный ответ WordPress.
curl -I https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки:
- при блокировке на сервере —
403 Forbidden; - при отключении через WordPress — запрос может доходить до PHP, но XML-RPC должен быть недоступен;
- в логах после правки не должно быть успешных обращений к endpoint.
Дополнительно проверьте, не кэшируется ли старый ответ CDN. Иногда после правки конфигурации браузер показывает уже неактуальную страницу, и кажется, что защита не сработала.
Частые ошибки и как их исправить
Блокируют не тот файл
Иногда закрывают xmlrpc.php в неправильной директории или правят конфиг не того виртуального хоста. В результате правило есть, но запросы всё равно проходят. Проверьте, что путь относится именно к активному сайту.
Ставят правило в тему вместо мини-плагина
Если отключение сделано в functions.php активной темы, оно исчезнет при смене темы. Для технических ограничений лучше использовать mu-plugin или собственный маленький плагин.
Не очищают кэш
После изменения правил CDN, reverse proxy или плагин кэширования могут отдавать старый ответ. Очистка кэша обязательна, иначе проверка будет ложной.
Отключают XML-RPC, не проверив интеграции
Если сайт использует старые внешние клиенты, автоматизацию публикаций или отдельные сервисы, они перестанут работать. Перед отключением проверьте реальные сценарии, а не только список установленных плагинов.
Безопасность и производительность: что ещё стоит сделать рядом
Если вы уже закрываете XML-RPC, имеет смысл посмотреть и на соседние точки входа. Слабый пароль администратора, открытая страница входа без ограничений и устаревшие плагины часто дают атакующему больше, чем сам XML-RPC.
- включите ограничение попыток входа;
- проверьте актуальность ядра, тем и плагинов;
- уберите неиспользуемые плагины, а не просто деактивируйте их;
- следите за логами 403 и 404, чтобы видеть повторяющиеся атаки;
- если нужен быстрый технический аудит дублей, индексации и мусорных страниц, можно использовать Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Главная идея простая: XML-RPC лучше закрывать там, где это дешевле для сервера и понятнее для поддержки. Если есть доступ к nginx или Apache — используйте его. Если нет, отключайте через WordPress, но обязательно проверяйте результат запросом и логами, а не только по ощущениям.