XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация или старые интеграции. Проблема в том, что этот интерфейс нужен не всем, но если он задействован, отключение должно быть осознанным. Ниже — практический сценарий: как понять, нужен ли вам XML-RPC, как отключить его без лишнего риска и как проверить результат.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые внешние клиенты, XML-RPC обычно только расширяет поверхность атаки. Через него исторически пытались подбирать пароли, запускать массовые запросы и нагружать сайт. Но отключать его имеет смысл только после проверки зависимостей.
Сначала проверьте, используется ли он
Типичные признаки, что XML-RPC вам всё ещё нужен:
- вы публикуете записи через мобильное приложение WordPress;
- подключены старые сервисы автопостинга;
- используется Jetpack или похожая интеграция, которая может опираться на XML-RPC в части функций;
- есть внешние клиенты для редактирования записей, настроенные давно и без обновления.
Если ничего из этого нет, отключение обычно безопасно. Но лучше не гадать, а проверить запросом к endpoint.
Диагностика проблемы: как понять, что XML-RPC открыт
Откройте в браузере или через curl адрес /xmlrpc.php. Если файл доступен, сервер обычно отвечает не HTML-страницей, а сообщением о том, что XML-RPC принимает только POST-запросы. Это уже означает, что endpoint активен.
curl -I https://example.com/xmlrpc.phpПолезно также проверить, не блокирует ли его уже хостинг или security-плагин. Если ответ приходит с кодом 403 или 404, возможно, отключение уже сделано на другом уровне, и дублировать его в коде не нужно.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных подхода: через плагин безопасности, через код в теме или через серверную конфигурацию. Выбор зависит от того, кто управляет сайтом и нужен ли вам быстрый откат.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Плагин безопасности | Если нужен интерфейс без кода | Проще включать и выключать | Добавляет ещё один слой зависимостей |
| Код в теме или mu-plugin | Если нужен точечный контроль | Прозрачно и предсказуемо | Нужно не забыть про обновления темы |
| Серверная блокировка | Если XML-RPC не нужен вообще | Отсекает запросы раньше WordPress | Требует доступа к конфигу сервера |
Вариант 1: отключение через код
Самый понятный способ — заблокировать фильтр xmlrpc_enabled. Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более аккуратный вариант с возможностью оставить XML-RPC для отдельных сценариев, можно ограничить его только для админов, но на практике это редко оправдано. Обычно либо endpoint нужен, либо нет.
Вариант 2: отключение через mu-plugin
Для продакшена mu-plugin удобнее, чем правка темы: он не исчезнет после обновления шаблона. Создайте файл wp-content/mu-plugins/disable-xmlrpc.php и добавьте туда:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress продолжит работать как обычно, но endpoint перестанет принимать запросы.
Вариант 3: блокировка на уровне сервера
Если XML-RPC не нужен вообще, можно закрыть доступ раньше WordPress. Для Apache это обычно делается через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>На Nginx логика похожая, но синтаксис зависит от конфигурации. Если у вас нет уверенности в настройках сервера, лучше не экспериментировать на боевом сайте без бэкапа.
Пошаговое решение без лишнего риска
- Проверьте, не используются ли мобильное приложение WordPress, внешняя публикация или старые интеграции.
- Сделайте резервную копию файлов и базы.
- Выберите один способ отключения: код, mu-plugin или серверная блокировка.
- Примените изменение только в одном месте, чтобы не получить двойную блокировку и путаницу при отладке.
- Проверьте ответ
/xmlrpc.phpпосле внедрения. - Если что-то сломалось, верните доступ и ищите конкретную зависимость, а не «включайте всё обратно».
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужны два теста: сетевой и функциональный.
Сетевой тест
Откройте https://example.com/xmlrpc.php в браузере или выполните:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали endpoint на уровне WordPress, ответ может быть 403 или 405 в зависимости от реализации. Если закрывали через сервер, чаще увидите 403 или 404.
Функциональный тест
Попробуйте выполнить действие, которое раньше зависело от XML-RPC: публикацию из мобильного приложения или подключение старого клиента. Если всё ещё работает, значит, отключение либо не затронуло нужный сценарий, либо интеграция использует другой механизм.
Если после отключения перестала работать синхронизация с внешним сервисом, не возвращайте XML-RPC сразу. Сначала уточните, можно ли перевести интеграцию на REST API или другой способ авторизации.
Частые ошибки и как их исправить
- Отключили XML-RPC в теме, а потом обновили тему. Решение: перенесите код в mu-plugin.
- Поставили плагин безопасности и добавили ещё и блокировку в .htaccess. Решение: оставьте один источник истины, иначе сложнее искать причину 403.
- Сломалось мобильное приложение WordPress. Решение: проверьте, не использовалось ли оно для публикации или редактирования, и верните доступ, если это критично.
- Блокировка на сервере не сработала. Решение: проверьте, что правило применено к нужному виртуальному хосту и что конфиг действительно перечитан.
- Отключили XML-RPC, но атаки на сайт не прекратились. Решение: проверьте другие точки входа —
wp-login.php, REST API, слабые пароли, устаревшие плагины.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC не заменяет базовую защиту. Если сайт публичный, дополнительно проверьте:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, темы и плагинов;
- наличие бэкапов и понятного плана отката;
- логирование подозрительных запросов на уровне хостинга или WAF.
Если вам нужен не только контроль XML-RPC, но и чистка лишних функций WordPress, иногда удобнее собрать это в один набор настроек через плагин оптимизации вроде Clearfy Pro: он помогает отключать часть ненужных возможностей и уменьшать «шум» в админке. Но даже в этом случае важно понимать, что именно вы выключаете, а не полагаться на пресеты вслепую.
Когда лучше не отключать XML-RPC
Есть сценарии, где отключение принесёт больше вреда, чем пользы. Например, если сайт живёт на старой интеграции, которую нельзя быстро перевести на REST API, или если редакторы реально публикуют материалы через мобильное приложение. В таких случаях лучше ограничить доступ иначе: через WAF, rate limiting, сложные пароли и контроль IP для админки.
Практический ориентир простой: если вы не можете назвать конкретный сервис, который использует XML-RPC, его можно отключать. Если можете — сначала проверьте, есть ли у этого сервиса современная альтернатива.