XML-RPC в WordPress часто отключают из соображений безопасности и снижения шума от брутфорса, но делать это «в лоб» опасно: можно сломать мобильные клиенты, Jetpack, старые интеграции и часть внешних сервисов. Ниже — рабочие способы отключения, как проверить, что именно используется на сайте, и как не задеть REST API.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удалённую публикацию, старые приложения WordPress, Jetpack-связку через XML-RPC или внешние сервисы, которые до сих пор ходят в xmlrpc.php, этот файл становится лишней точкой входа. На практике его отключают, когда:
- в логах много запросов к
/xmlrpc.php; - сайт получает перебор паролей через XML-RPC;
- нужен более жёсткий контроль над поверхностью атаки;
- интеграции уже переведены на REST API или прямые вебхуки.
Важно не путать XML-RPC и REST API. Отключение XML-RPC не должно ломать /wp-json/, если вы не добавили слишком агрессивные правила на уровне сервера.
Диагностика: используется ли XML-RPC сейчас
Перед изменениями проверьте, кто обращается к xmlrpc.php. Самый простой способ — посмотреть access log веб-сервера. Если доступа к логам нет, можно временно добавить лёгкий логирующий фильтр в mu-plugin или в functions.php темы, чтобы увидеть обращения.
<?php
add_action( 'xmlrpc_call', function( $method ) {
error_log( 'XML-RPC call: ' . $method );
} );Этот код не отключает XML-RPC, а только помогает понять, какие методы реально вызываются. Если в логах есть обращения от Jetpack, мобильного приложения или стороннего сервиса, сначала переведите их на другой способ подключения.
Что проверить до отключения
- используется ли Jetpack и какие модули завязаны на XML-RPC;
- есть ли мобильное приложение WordPress у редакторов;
- настроены ли внешние сервисы публикации или синхронизации;
- есть ли старые интеграции, где указан endpoint
/xmlrpc.php.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три нормальных подхода: через PHP-фильтр, через правила сервера и через плагин безопасности. Для большинства проектов удобнее начать с PHP-способа: его проще откатить и он не затрагивает остальную конфигурацию веб-сервера.
Вариант 1. Отключение через PHP
Добавьте код в mu-plugin или в отдельный мини-плагин. Так вы не потеряете настройку при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый прямой способ. WordPress перестанет принимать XML-RPC-запросы, но REST API останется доступным.
Вариант 2. Блокировка на уровне .htaccess
Если сайт работает на Apache, можно закрыть доступ к файлу ещё до загрузки WordPress. Это полезно, когда нужно снизить нагрузку от массовых запросов.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache иногда встречается синтаксис Deny from all, но на современных серверах лучше использовать Require all denied. Не вставляйте это правило в случайное место файла: держите его рядом с другими правилами безопасности и после проверки бэкапа.
Вариант 3. Ограничение через Nginx
На Nginx правило выглядит иначе. Если у вас есть доступ к конфигу сайта, можно закрыть только XML-RPC:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот вариант особенно полезен, если атаки идут массово и вы хотите отсечь их до PHP-уровня.
Сравнение подходов: плагин, код или сервер
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| PHP-фильтр | Легко откатить, не трогает сервер | Запрос всё равно доходит до WordPress | Если нужен быстрый и безопасный старт |
| .htaccess / Nginx | Отсекает запросы раньше, снижает нагрузку | Нужен доступ к конфигу сервера | Если идёт активный перебор или много мусорных запросов |
| Плагин безопасности | Удобно для админов без кода | Лишняя зависимость от плагина | Если уже используете security-плагин и не хотите править конфиги |
Как проверить, что решение сработало
После внедрения проверьте не только факт блокировки, но и побочные эффекты. Это можно сделать вручную и через браузер.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что ответ не содержит рабочий XML-RPC endpoint.
- Проверьте
/wp-json/— REST API должен открываться, если вы его не ограничивали отдельно. - Проверьте Jetpack, мобильное приложение и внешние интеграции, если они были подключены.
curl -i https://example.com/xmlrpc.php
curl -i https://example.com/wp-json/Нормальный результат для XML-RPC — отказ в доступе, 403 или отключённый endpoint. Для REST API ожидается обычный ответ JSON.
Частые ошибки и как их исправить
Отключили XML-RPC, а сломался Jetpack
Это типичный сценарий. Jetpack на некоторых конфигурациях использует XML-RPC для части функций. Решение простое: либо перенастроить Jetpack на другой сценарий работы, либо не отключать XML-RPC полностью, а ограничить только подозрительные методы и усилить защиту входа.
Заблокировали не только XML-RPC, но и REST API
Так бывает, если в .htaccess или Nginx добавили слишком широкое правило по пути /wp- или по всем PHP-файлам. Проверяйте, что блокируется только /xmlrpc.php, а не весь API.
Сделали правку в теме, а потом потеряли её после обновления
Не вносите такие изменения в functions.php активной темы, если это не временный тест. Для постоянного решения используйте mu-plugin или отдельный мини-плагин.
Поставили security-плагин и забыли, что он уже блокирует XML-RPC
Дублирующие правила иногда создают путаницу в диагностике. Если endpoint уже закрыт плагином, дополнительная блокировка на сервере не нужна, но она не должна ломать сайт. Сначала посмотрите, где именно срабатывает запрет.
Практика безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа. Если на сайте слабые пароли, отключение одного endpoint не решит проблему целиком. Имеет смысл дополнить настройку:
- ограничением попыток входа;
- двухфакторной аутентификацией для админов;
- обновлением ядра, тем и плагинов;
- проверкой логов на повторяющиеся запросы;
- отдельной защитой
wp-login.php.
Если вам нужен более широкий набор мер без ручной сборки из нескольких плагинов, можно посмотреть в сторону Clearfy Pro: у него есть функции для технической чистки и части SEO-настроек, но перед установкой всё равно стоит проверить, не дублирует ли он уже существующие правила на сервере. Ссылка для проверки: Clearfy Pro.
Когда лучше не отключать XML-RPC полностью
Если у вас есть рабочие интеграции, которые невозможно быстро перевести на REST API, полное отключение может создать больше проблем, чем пользы. В таком случае разумнее:
- оставить endpoint включённым, но ограничить доступ на уровне WAF или сервера;
- закрыть только конкретные методы, если вы точно знаете, какие не нужны;
- усилить защиту логина и мониторинг запросов.
Такой подход даёт больше контроля и меньше шансов сломать редакционные процессы или внешнюю синхронизацию.