XML-RPC в WordPress часто остаётся включённым по умолчанию, хотя на большинстве сайтов он давно не нужен. Проблема не в самом файле xmlrpc.php, а в том, что открытый endpoint используют для перебора паролей, массовых запросов и лишней нагрузки. Если у вас нет старых мобильных клиентов, внешних сервисов публикации или специфической интеграции, этот канал обычно лучше закрыть.
Когда XML-RPC действительно мешает
Симптомы обычно заметны в логах и по поведению сайта. На хостинге могут расти запросы к /xmlrpc.php, а в панели безопасности появляться предупреждения о brute force. Иногда админка работает нормально, но сайт получает лишние обращения, из-за которых растёт нагрузка на PHP и базу.
Что проверить перед отключением
- Используете ли вы приложение WordPress для iOS/Android старого типа.
- Подключён ли внешний сервис, который публикует записи через XML-RPC.
- Есть ли интеграции с Jetpack, если они завязаны на удалённое подключение.
- Появляются ли в логах частые POST-запросы к
xmlrpc.php.
Если ничего из этого не нужно, отключение обычно безопасно. Если сомневаетесь, сначала ограничьте доступ на уровне сервера и посмотрите на ошибки интеграций, а уже потом убирайте endpoint полностью.
Диагностика проблемы: как понять, что XML-RPC открыт
Самый простой признак — ответ сервера на запрос к /xmlrpc.php. Даже если сайт защищён плагином безопасности, сам файл может быть доступен и отвечать кодом 405 или 200. Это уже означает, что endpoint не закрыт полностью.
curl -I https://example.com/xmlrpc.phpЕсли вы видите ответ с заголовками сервера и без явного запрета, значит доступ не заблокирован на уровне веб-сервера. Для более точной проверки можно отправить тестовый POST-запрос, но для обычной диагностики достаточно посмотреть, не отдаёт ли файл живой ответ.
Как отключить XML-RPC в WordPress: рабочие варианты
Есть три нормальных подхода: отключить через код, закрыть на сервере или использовать плагин безопасности. Выбор зависит от того, кто управляет сайтом и насколько критично сохранить возможность быстрого отката.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в теме или mu-plugin | Нужен контролируемый вариант без лишних плагинов | Нужно не забыть про обновления и место подключения |
| Правило на сервере | Есть доступ к Nginx/Apache и нужен жёсткий запрет | Можно случайно задеть другие правила, если править без теста |
| Плагин безопасности | Нужен быстрый способ без правки кода | Добавляет ещё одну зависимость и не всегда закрывает endpoint на уровне сервера |
Вариант 1: отключить XML-RPC через код
Если нужен понятный и обратимый способ, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC внутри WordPress. Для большинства сайтов этого достаточно, но если endpoint активно атакуют, лучше дополнительно закрыть его на сервере.
Вариант 2: заблокировать xmlrpc.php на уровне Nginx
Если у вас Nginx, можно отдать 403 на прямой доступ к файлу. Это полезно, когда нужно остановить обращения ещё до загрузки WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить Nginx. На shared-хостинге этот способ может быть недоступен, тогда остаётся код или плагин.
Вариант 3: закрыть доступ в Apache
Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста. Если сайт работает через Apache и .htaccess разрешён, можно добавить запрет на прямой доступ.
<Files xmlrpc.php>
Require all denied
</Files>Это не самый изящный вариант для всех окружений, но он рабочий и понятный. Главное — не смешивать его с чужими правилами без резервной копии файла.
Пошаговое решение без лишнего риска
- Проверьте, есть ли у сайта реальные зависимости от XML-RPC.
- Сделайте резервную копию файла конфигурации или подготовьте отдельный mu-plugin.
- Отключите XML-RPC кодом или на сервере.
- Прогоните тесты входа, публикации и внешних интеграций.
- Посмотрите логи веб-сервера и безопасности в течение нескольких часов или суток.
Если сайт большой или с несколькими редакторами, лучше сначала отключить через фильтр xmlrpc_enabled, а потом уже при необходимости добавить серверный запрет. Так проще понять, что именно сломалось, если какая-то интеграция всё же была завязана на XML-RPC.
Как проверить, что решение сработало
Проверка должна быть не только технической, но и прикладной. Недостаточно увидеть 403 в браузере — важно убедиться, что админка, REST API и публикация записей работают как раньше.
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт. - Попробуйте войти в админку и создать тестовую запись.
- Если есть мобильное приложение WordPress или внешняя интеграция, проверьте её отдельно.
- Посмотрите логи на предмет повторяющихся запросов к
xmlrpc.phpпосле блокировки.
Если endpoint закрыт, а в логах больше нет обращений к нему, значит решение работает. Если при этом какая-то интеграция перестала публиковать записи, значит она действительно использовала XML-RPC, и её нужно перевести на другой способ подключения.
Частые ошибки и как их исправить
Отключили XML-RPC, но оставили доступ к файлу
Фильтр xmlrpc_enabled может вернуть ошибку внутри WordPress, но сам файл всё ещё будет доступен по URL. При активных атаках это не лучший вариант. Если есть возможность, закройте endpoint ещё и на уровне веб-сервера.
Сломали интеграцию с внешним сервисом
Некоторые старые сервисы публикации и мобильные клиенты до сих пор используют XML-RPC. Если после отключения перестала работать синхронизация, проверьте документацию сервиса и ищите современный способ подключения через REST API или нативный API самого сервиса.
Добавили правило не туда
Частая ошибка — править .htaccess на сервере с Nginx или вставлять код в родительскую тему, которая обновляется. В результате правило либо не работает, либо исчезает после обновления. Для кода лучше использовать дочернюю тему или mu-plugin.
Перепутали XML-RPC и REST API
Отключение XML-RPC не должно ломать REST API WordPress. Если после изменений перестали работать блоки редактора, мобильные приложения или интеграции, значит проблема, скорее всего, в другом правиле безопасности или в плагине, который режет /wp-json/.
Практические советы по безопасности и производительности
Если цель — не просто убрать один endpoint, а снизить поверхность атаки, смотрите шире. Закрытие XML-RPC полезно, но не заменяет нормальную защиту входа, актуальные обновления и ограничение лишних публичных точек.
- Используйте двухфакторную аутентификацию для админов, если это поддерживает ваш стек.
- Проверьте, не создаёт ли плагин безопасности лишнюю нагрузку сам по себе.
- Уберите неиспользуемые плагины и темы, чтобы сократить число потенциальных уязвимостей.
- Следите за логами 404 и POST-запросов к системным файлам.
Если вам нужен более широкий набор мер по чистке сайта и удалению лишних технических дублей, иногда удобнее собрать это в одном наборе настроек, чем держать десяток разрозненных плагинов. Но сам XML-RPC лучше закрывать точечно и проверяемо, а не «на всякий случай» через агрессивные правила, которые потом трудно отлаживать.