XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу и странным обращениям к /xmlrpc.php. Проблема в том, что отключать его вслепую нельзя: у части сайтов через XML-RPC всё ещё работают старые мобильные клиенты, публикация из внешних сервисов и некоторые интеграции. Если задача — убрать лишнюю поверхность атаки и не поломать рабочие сценарии, сначала нужно понять, кто именно стучится в XML-RPC и чем это заменить.
Когда отключение XML-RPC действительно уместно
Если сайт не использует старые приложения для публикации, не принимает входящие соединения от внешних сервисов через XML-RPC и вы не видите в логах легитимных обращений к xmlrpc.php, отключение обычно оправдано. На практике это особенно полезно для сайтов, где уже есть нормальная авторизация через REST API, формы, вебхуки или интеграции через отдельные плагины.
Но если у вас подключены старые клиенты WordPress для iOS/Android, сервисы автопостинга или интеграции, которые явно используют XML-RPC, сначала проверьте их настройки. Иначе можно получить тихую поломку: публикации перестанут уходить, а ошибка проявится только в момент очередной синхронизации.
Диагностика: кто использует XML-RPC сейчас
Перед отключением посмотрите, есть ли реальные обращения к /xmlrpc.php. Самый простой способ — журнал веб-сервера. Если доступа к логам нет, временно включите логирование на уровне хостинга или проверьте статистику в панели.
Что искать в логах
- частые POST-запросы к
/xmlrpc.phpс одинаковых IP; - ошибки авторизации с методами
system.multicallиwp.getUsersBlogs; - запросы от известных сервисов, которые вы реально используете;
- повторяющиеся попытки перебора логина и пароля.
Если видите только мусорный трафик и не находите легитимных клиентов, XML-RPC можно отключать. Если есть сомнения, сначала ограничьте доступ на уровне веб-сервера или WAF, а не удаляйте функциональность полностью.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных подхода: через код, через плагин или через веб-сервер. Выбор зависит от того, где вам удобнее управлять правилом и нужен ли быстрый откат.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль в репозитории, без лишних плагинов | Нужно аккуратно обновлять и не потерять при деплое |
| Плагин безопасности | Быстро включить и отключить из админки | Добавляет ещё один слой логики и зависимость от плагина |
| Правило веб-сервера | Режет запросы раньше WordPress, экономит ресурсы | Требует доступа к конфигу nginx/apache |
Вариант 1: отключить через код
Если нужен предсказуемый и прозрачный способ, добавьте фильтр в mu-plugin или в собственный плагин. Так правило не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC на уровне WordPress. При обращении к /xmlrpc.php сервер всё ещё отдаст файл, но WordPress не будет обслуживать запрос как рабочий API.
Вариант 2: закрыть доступ на уровне nginx
Если сайт под nginx, можно отрезать запросы ещё до загрузки WordPress. Это полезно, когда на сайт идёт много мусорных обращений и вы хотите снизить нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache аналогичное правило обычно делают через mod_rewrite или Files-директивы в .htaccess, но если у вас нет уверенности в конфигурации, лучше ограничиться кодом в WordPress или использовать плагин.
Вариант 3: отключить через плагин
Если нужен быстрый переключатель без правок кода, можно использовать плагин безопасности. Важно только не ставить его ради одной функции, если остальной функционал вам не нужен. Лишний плагин — это ещё одна точка обновления и потенциальный источник конфликтов.
Если у вас уже стоит Clearfy Pro, проверьте, не закрывает ли он XML-RPC и другие лишние системные запросы в рамках общей чистки сайта. Это удобнее, чем держать отдельный плагин только ради одной галочки.
Пошаговое решение без поломки интеграций
- Проверьте логи и список подключённых сервисов.
- Убедитесь, что сайт не использует старые клиенты публикации через XML-RPC.
- Выберите способ отключения: код, сервер или плагин.
- Сделайте правило в staging, если сайт критичный.
- После внедрения проверьте ответ
/xmlrpc.phpи работу REST API.
Если у вас есть внешняя интеграция, которая раньше ходила через XML-RPC, переведите её на REST API или на отдельный webhook. Для WordPress это обычно более прозрачный и управляемый вариант: легче ограничивать права, логировать обращения и отлаживать ошибки.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере или через curl. Полностью корректное поведение зависит от способа блокировки, но главное — запрос не должен проходить как рабочий XML-RPC-метод.
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали доступ на уровне nginx, обычно увидите 403 Forbidden. Если отключали через WordPress-фильтр, ответ может отличаться, но попытка вызвать XML-RPC-методы должна завершаться ошибкой.
Дополнительно проверьте REST API, чтобы не перепутать две разные вещи. Например, откройте:
curl -I https://example.com/wp-json/Если /wp-json/ отвечает нормально, а /xmlrpc.php закрыт, значит вы отключили именно XML-RPC, а не сломали API WordPress целиком.
Частые ошибки и как их исправить
Отключили XML-RPC, а публикации из внешнего сервиса пропали
Значит, сервис реально использовал XML-RPC. Решение — либо вернуть доступ, либо перевести интеграцию на REST API, если сервис это поддерживает. Не пытайтесь «починить» это открытием всего подряд: лучше найти конкретный источник запроса.
Закрыли /xmlrpc.php, но атаки в логах остались
Это нормально, если бот продолжает стучаться в URL. Важен не сам факт запроса, а то, что WordPress больше не обрабатывает его как рабочий канал. Если нагрузка всё ещё заметна, добавьте блокировку на уровне веб-сервера или WAF.
Сломали REST API, перепутав его с XML-RPC
Это частая ошибка при жёсткой фильтрации URL. REST API работает через /wp-json/, а XML-RPC — через /xmlrpc.php. Не ставьте правила, которые режут весь /wp-* трафик без разбора.
Добавили код в тему и потеряли его после обновления
Если правило лежало в functions.php активной темы, при смене темы или обновлении логика может исчезнуть. Для таких задач лучше использовать mu-plugin или отдельный мини-плагин.
Практические советы по безопасности и производительности
Если сайт регулярно получает мусорные запросы к XML-RPC, отключение на уровне сервера полезнее, чем просто фильтр в WordPress: запросы не доходят до загрузки ядра, и это экономит ресурсы. На небольших сайтах разница может быть незаметна, но на проектах с постоянным брутфорсом она ощущается сразу в логах и по CPU.
При этом не стоит превращать отключение XML-RPC в единственную меру защиты. Нужны нормальные пароли, ограничение попыток входа, 2FA для админов и актуальные обновления ядра, темы и плагинов. XML-RPC — это только одна из дверей, а не вся проблема безопасности WordPress.
Если вам нужно не просто убрать XML-RPC, а системно почистить сайт от лишних технических хвостов, удобно делать это в одном месте. В таких сценариях часто смотрят в сторону Clearfy Pro: он закрывает часть типовых задач по чистке и технической оптимизации без россыпи отдельных плагинов.
После внедрения не забудьте зафиксировать изменение в документации проекта: кто отключил, где именно и как вернуть обратно. Это экономит время, когда через полгода кто-то из команды начнёт искать причину сломанной интеграции.