XML-RPC в WordPress до сих пор часто включён по умолчанию, хотя на многих сайтах он не нужен. Проблема не в самом файле xmlrpc.php, а в том, что через него удобно запускать массовые попытки входа и дергать сайт удалённо там, где это уже давно не требуется. Если у вас нет Jetpack, мобильного приложения WordPress и внешних сервисов, которые завязаны именно на XML-RPC, отключение этого интерфейса — нормальная техническая мера.
Но делать это вслепую нельзя: на части сайтов XML-RPC всё ещё нужен для публикации через сторонние клиенты, синхронизации или старых интеграций. Ниже — как понять, нужен ли он вам, как отключить его без лишних побочных эффектов и как проверить результат.
Когда XML-RPC действительно стоит отключать
Сначала проверьте сценарий использования. Если сайт обычный: публикация идёт через админку, внешних мобильных клиентов нет, Jetpack не используется, а интеграции работают через REST API или вебхуки, XML-RPC чаще всего не нужен. В таком случае его отключение уменьшает поверхность атаки и убирает один из популярных векторов брутфорса.
Если же у вас есть хотя бы один из пунктов ниже, сначала проверьте зависимость:
- Jetpack или сервисы, которые используют его подключение к сайту;
- мобильное приложение WordPress, если оно настроено на старый способ подключения;
- публикация через внешние редакторы и клиенты, которые работают именно через XML-RPC;
- старые интеграции с удалённой публикацией или пингбэками.
Быстрая диагностика
Самый простой тест — открыть /xmlrpc.php в браузере. Если файл доступен, это ещё не значит, что он нужен, но вы хотя бы убедитесь, что он не закрыт на уровне сервера. Для более практичной проверки посмотрите логи доступа веб-сервера: если запросы к xmlrpc.php идут часто и в основном с подозрительных IP, это типичный признак автоматизированных попыток входа.
Ещё один полезный шаг — проверить активные плагины и интеграции. Если в списке есть Jetpack, сервисы автопостинга или удалённой публикации, отключать XML-RPC нужно только после теста на staging-копии.
Как отключить XML-RPC: сравнение подходов
Есть несколько рабочих вариантов. Выбор зависит от того, нужен ли вам полный запрет на уровне сервера или достаточно отключить обработку в WordPress.
| Способ | Что делает | Плюс | Минус |
|---|---|---|---|
| Плагин безопасности | Блокирует доступ или отключает XML-RPC | Быстро и без кода | Добавляет зависимость от плагина |
| Код в теме или mu-plugin | Отключает XML-RPC на уровне WordPress | Контролируемо и прозрачно | Нужно аккуратно внедрять |
| .htaccess / nginx | Режет запросы до загрузки WordPress | Лучше для нагрузки и безопасности | Зависит от сервера и доступа к конфигу |
Если у вас обычный shared-хостинг и нет доступа к конфигу nginx, чаще всего удобнее код или плагин. Если есть доступ к серверу, блокировка на уровне веб-сервера обычно предпочтительнее.
Пошаговое решение через код
Самый предсказуемый способ — отключить XML-RPC через фильтр WordPress. Лучше не вставлять это в 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 нет, её можно создать вручную. WordPress подхватывает такие плагины автоматически, и они не требуют активации в админке.
Если нужно не просто отключить XML-RPC, а явно запретить доступ к файлу на уровне WordPress, можно добавить более жёсткую обработку:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Первый вариант обычно достаточно. Второй полезен, если на сайте есть нестандартные сценарии, где одного фильтра мало, но в большинстве случаев он избыточен.
Отключение через .htaccess или nginx
Если задача — не дать запросу даже дойти до WordPress, блокируйте xmlrpc.php на уровне сервера. Для Apache это можно сделать через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache иногда встречается вариант с Deny from all, но на современных версиях корректнее использовать Require all denied.
Для nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После правки конфигурации не забудьте перечитать настройки веб-сервера и проверить, что блокировка не зацепила соседние правила. На nginx особенно важно не вставить этот блок внутрь уже существующего location с конфликтующим приоритетом.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php и посмотрите ответ сервера. При корректной блокировке вы должны получить отказ в доступе на уровне сервера или сообщение WordPress о недоступности XML-RPC, а не обычную рабочую страницу с системным ответом.
Дальше проверьте три вещи:
- Jetpack и другие интеграции, если они есть, продолжают работать;
- в логах стало меньше запросов к
xmlrpc.php; - на сайте не появилось ошибок при публикации записей, обновлении профиля или синхронизации контента.
Если вы отключали XML-RPC через код, полезно временно включить логирование ошибок и проверить журнал PHP и веб-сервера после деплоя. Это поможет поймать редкие зависимости, которые не видны сразу.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Это самая частая история. Jetpack в некоторых сценариях использует XML-RPC для связи с сайтом. Если после блокировки пропало подключение, сначала проверьте, действительно ли этот сайт должен работать через Jetpack. Если да — либо не отключайте XML-RPC, либо переведите интеграцию на другой доступный способ, если он поддерживается конкретным сервисом.
Вставили код в тему и забыли про него
Если код лежит в functions.php, он исчезнет при смене темы или обновлении кастомной сборки. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин. Это проще сопровождать и легче откатывать.
Заблокировали файл, но брутфорс всё равно идёт
Иногда запросы продолжают долбить сайт, даже если XML-RPC уже закрыт. Это нормально: атакующий скрипт не знает, что вы поменяли конфигурацию. В таком случае дополнительно смотрят на WAF, rate limiting, fail2ban или правила на уровне CDN. Одна блокировка файла не заменяет общую защиту входа в админку.
Сломали правила .htaccess
Если после правки Apache начал отдавать 500, значит синтаксис правила не подходит вашей версии сервера или директива размещена не там. Верните файл из бэкапа и проверьте конфигурацию поэтапно. На shared-хостинге лучше сначала тестировать через плагин или mu-plugin, а не лезть в серверные правила без необходимости.
Что ещё сделать для защиты от брутфорса
Отключение XML-RPC — это только один слой. Для реальной защиты входа в WordPress полезно дополнительно ограничить попытки входа, включить двухфакторную аутентификацию для админов, убрать лишние учётные записи с правами администратора и следить за обновлениями ядра, тем и плагинов.
Если нужен более широкий набор технических чисток и SEO-ограничений, иногда удобнее закрывать часть задач одним инструментом, чем собирать всё вручную. Например, для удаления дублей, чистки служебного мусора и части технических настроек на WordPress часто используют Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае важно понимать, что именно отключается и как это влияет на интеграции.
Практический чек-лист после внедрения:
- проверить доступ к
/xmlrpc.php; - убедиться, что Jetpack и внешние клиенты не сломались;
- посмотреть логи на повторяющиеся запросы;
- проверить, что блокировка не вызвала 500 или 403 на других URL;
- сохранить рабочую конфигурацию в репозиторий или заметки по серверу.
Если сайт живёт долго и его администрируют несколько человек, такие изменения лучше фиксировать как часть технической документации. Иначе через полгода кто-то снова включит XML-RPC плагином безопасности, не понимая, зачем его отключали раньше.