XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: бот-атаки на xmlrpc.php, лишняя поверхность атаки, шум в логах, попытки брутфорса через system.multicall. Но у этого файла есть и легитимные сценарии — мобильное приложение WordPress, старые внешние публикации, некоторые интеграции. Поэтому правильный подход здесь не «рубить всё подряд», а сначала понять, нужен ли XML-RPC вообще.
Когда XML-RPC действительно стоит отключать
Если сайт живёт на обычной админке WordPress, а публикации, комментарии и интеграции идут через браузер, XML-RPC чаще всего не нужен. Особенно если в логах регулярно появляются запросы к /xmlrpc.php, а в панели безопасности видно много неудачных попыток авторизации с одного и того же файла.
Отключение имеет смысл, когда:
- вы не используете мобильное приложение WordPress;
- не подключали внешние сервисы, которые работают через XML-RPC;
- на сайте нет старых интеграций с публикацией по XML-RPC;
- нужно снизить количество точек входа для перебора паролей.
Если хотя бы один внешний сервис зависит от XML-RPC, сначала проверьте его документацию. Иногда проблема решается переходом на REST API или на другой способ авторизации, а не полным отключением файла.
Диагностика: нужен ли вам xmlrpc.php
Перед изменениями проверьте, используется ли endpoint на практике. Самый простой способ — посмотреть логи веб-сервера или события в плагине безопасности. Если доступа к логам нет, можно временно открыть https://example.com/xmlrpc.php в браузере: при включённом XML-RPC WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказательство использования, но подтверждает, что endpoint доступен.
Полезно также проверить, нет ли внешних подключений через XML-RPC в коде темы или плагинов. Ищите упоминания xmlrpc.php, IXR_Client, pingback.ping, старые библиотеки публикации в блог. Если таких вызовов нет, вероятность того, что файл нужен, заметно ниже.
Что проверить до отключения
- используете ли вы приложение WordPress на телефоне;
- есть ли сторонние сервисы автопостинга;
- подключён ли Jetpack или аналогичный сервис, который может использовать XML-RPC в отдельных сценариях;
- есть ли в логах регулярные легитимные POST-запросы к
xmlrpc.phpс ваших IP.
Как отключить XML-RPC через код
Если нужен управляемый вариант без установки лишнего плагина, проще всего отключить XML-RPC через фильтр xmlrpc_enabled. Это безопаснее, чем править ядро или удалять файл физически: после обновлений WordPress настройка не слетит.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы, но для постоянной защиты лучше вынести его в небольшой mu-plugin. Так вы не потеряете настройку при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более жёсткий вариант, можно блокировать сам файл на уровне веб-сервера. Это уже не настройка WordPress, а серверное правило, и оно полезно, когда к сайту идёт много мусорного трафика именно на этот endpoint.
Пример для Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный способ имеет смысл, если вы точно уверены, что XML-RPC не нужен вообще. Если есть сомнения, начните с фильтра в WordPress: его проще откатить.
Плагин или код: что выбрать
Если задача точечная, код обычно надёжнее. Плагин удобен, когда нужно выключить XML-RPC без доступа к теме или когда вы ведёте несколько сайтов и хотите одинаковую настройку через админку. Но лишний плагин — это ещё один объект обновления и ещё один потенциальный источник конфликта.
| Подход | Плюсы | Минусы |
|---|---|---|
Фильтр xmlrpc_enabled | Минимум лишнего, легко откатить, работает после обновлений | Нужен доступ к коду |
| Правило на сервере | Режет запросы раньше WordPress, снижает нагрузку | Можно случайно заблокировать нужную интеграцию |
| Плагин безопасности | Удобно для неразработчиков, часто есть журнал событий | Дополнительная зависимость и риск конфликтов |
Если на сайте уже стоит плагин для технической чистки и SEO, например Clearfy Pro, проверьте, не решает ли он эту задачу штатно. Но даже в этом случае полезно понимать, какое именно правило он применяет: фильтр, серверный блок или настройку в админке.
Проверка результата после внедрения
После отключения не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что endpoint действительно перестал принимать запросы и что сайт не потерял нужную функциональность.
- Откройте
/xmlrpc.phpв браузере. При серверной блокировке вы должны увидеть отказ в доступе или 403. - Отправьте POST-запрос тестом через
curlи проверьте код ответа. - Попробуйте выполнить действие, которое раньше зависело от XML-RPC, если такой сценарий у вас был.
Пример проверки через curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли XML-RPC отключён корректно, ответ не должен выглядеть как рабочий XML-RPC endpoint. На уровне WordPress фильтр обычно приводит к отказу в обработке, а серверное правило — к 403 или аналогичному запрету.
Дополнительно посмотрите логи безопасности и веб-сервера через день-два после изменения. Если запросы к xmlrpc.php продолжаются, но уже получают отказ, значит правило работает. Если же вы видите ошибки в стороннем сервисе, который раньше публиковал материалы или синхронизировал данные, придётся вернуть доступ и искать альтернативный способ интеграции.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестало работать приложение WordPress
Это ожидаемо. Мобильное приложение WordPress и некоторые внешние клиенты используют XML-RPC для части операций. Решение простое: либо вернуть доступ, либо перевести рабочий процесс на админку и REST API, если приложение не критично.
Поставили правило в .htaccess, но endpoint всё равно отвечает
Часто причина в том, что сайт работает не на Apache, а на Nginx, или правило добавили не в тот блок конфигурации. Проверьте стек сервера и место, где реально читаются правила. Для Nginx .htaccess не работает вообще.
Сломали интеграцию, хотя «ничего не использовали»
Некоторые сервисы используют XML-RPC неочевидно: старые панели публикации, внешние редакторы, автоматические пинги. Перед отключением лучше сделать поиск по проекту и проверить журналы запросов. Если интеграция нужна, но только для одного сервиса, лучше ограничить доступ по IP на уровне сервера, а не отключать endpoint полностью.
Скрыли проблему плагином, но атаки в логах остались
Если плагин только отключает XML-RPC внутри WordPress, веб-сервер всё равно принимает запросы и пишет их в логи. Это не ошибка, но шум остаётся. В таком случае серверное правило эффективнее: оно отсекает запрос раньше, чем они доходят до PHP.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если у вас слабые пароли, нет ограничений на логин и не включена двухфакторная аутентификация, атакующий найдёт другой путь. XML-RPC — это только один из каналов.
- используйте уникальные пароли и 2FA для администраторов;
- ограничьте число попыток входа, если это уместно для вашего проекта;
- следите за логами 403 и 404, чтобы видеть массовые сканы;
- не отключайте XML-RPC, если на нём завязана рабочая интеграция, без плана замены;
- после изменений очистите кеш, если у вас есть серверный кеш или кеш-плагин.
Если вам нужен не только этот пункт, а более широкая техническая чистка WordPress — удаление дублей, отключение лишних сервисов, настройка индексации и базовая гигиена сайта — такие задачи обычно удобнее решать комплексно, а не набором разрозненных правок.
Главная проверка здесь простая: вы должны понимать, кто именно обращается к xmlrpc.php, и что произойдёт после блокировки. Если это просто мусорный трафик — отключайте. Если это рабочий канал — сначала переносите интеграцию, потом закрывайте endpoint.