XML-RPC в WordPress часто отключают «на всякий случай», а потом получают нерабочий Jetpack, проблемы с публикацией из мобильного приложения или странные ошибки в интеграциях. Если задача именно в защите от bruteforce и лишних запросов, отключать всё подряд не нужно: сначала проверьте, кто реально использует этот интерфейс.
Когда XML-RPC мешает, а когда его лучше оставить
XML-RPC — это не только старый удалённый доступ к сайту. Через него до сих пор работают некоторые внешние сервисы, мобильное приложение WordPress и часть функций Jetpack. Поэтому решение зависит от сценария:
- если сайт не использует Jetpack, мобильное приложение и внешнюю публикацию — XML-RPC можно закрывать;
- если Jetpack нужен для статистики, уведомлений или удалённого управления — сначала проверьте, какие именно функции завязаны на XML-RPC;
- если у вас есть интеграции старого типа, отключение может сломать публикацию и синхронизацию.
Быстрая диагностика проблемы
Перед изменениями посмотрите, есть ли вообще обращения к /xmlrpc.php. Это можно сделать по логам веб-сервера или через инструменты хостинга. Если логов нет, проверьте вручную:
curl -I https://example.com/xmlrpc.phpНормальный ответ не всегда означает, что функция нужна. Но если вы видите регулярные POST-запросы к этому файлу, значит кто-то или что-то его использует. Для Jetpack и мобильного приложения важен не сам факт наличия файла, а успешная авторизация и обмен данными.
Как отключить XML-RPC без лишнего риска
Самый безопасный подход — не удалять файл, а блокировать доступ на уровне WordPress или веб-сервера. Тогда вы сможете быстро вернуть доступ, если обнаружите зависимость.
Вариант 1: отключить через код
Добавьте в functions.php дочерней темы или в собственный мини-плагин:
add_filter( 'xmlrpc_enabled', '__return_false' );Это простой и понятный способ. WordPress перестанет отвечать на XML-RPC-запросы, но сам файл останется на месте. Для большинства сайтов этого достаточно.
Вариант 2: заблокировать на уровне сервера
Если у вас Apache, можно закрыть доступ к xmlrpc.php через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный вариант жёстче и снижает нагрузку от мусорных запросов. Но если вы используете Jetpack или мобильный клиент, сначала убедитесь, что они не завязаны на этот endpoint.
Вариант 3: точечная блокировка по IP или по запросам
Это уже более узкий сценарий. Если XML-RPC нужен только для одного внешнего сервиса, иногда проще ограничить доступ по IP на уровне firewall или reverse proxy. Такой способ сложнее в сопровождении, зато не ломает весь сайт для всех подряд.
| Способ | Плюсы | Минусы |
|---|---|---|
Фильтр xmlrpc_enabled | Быстро, просто откатить | Не режет запросы до WordPress |
| Блокировка в сервере | Меньше мусорной нагрузки | Нужно аккуратно проверить зависимости |
| Ограничение по IP | Подходит для точечных интеграций | Сложнее поддерживать |
Как не сломать Jetpack и мобильное приложение
Если Jetpack уже подключён, сначала проверьте, какие модули вам нужны. Не все функции завязаны на XML-RPC одинаково, но отключение может затронуть синхронизацию и удалённое управление. Практически это выглядит так:
- временно отключите XML-RPC только на тестовой копии сайта;
- проверьте вход в мобильное приложение WordPress;
- проверьте функции Jetpack, которые используете на практике;
- посмотрите, нет ли ошибок в журнале сервера и в админке WordPress;
- только потом переносите изменение на боевой сайт.
Если после отключения приложение перестало публиковать записи, а Jetpack начал ругаться на соединение, значит этот канал вам всё ещё нужен. В таком случае лучше не закрывать его полностью, а ограничить доступ другими средствами: сложные пароли, двухфакторная аутентификация, ограничение попыток входа, защита панели администратора.
Проверка результата после внедрения
После изменения важно не просто «посмотреть, что сайт открывается», а проверить конкретные точки отказа.
- Откройте
/xmlrpc.phpв браузере — доступ должен быть закрыт или не давать полезного ответа для удалённого вызова. - Проверьте, что обычная авторизация в админке работает.
- Если Jetpack используется, убедитесь, что он не потерял соединение.
- Попробуйте опубликовать черновик из мобильного приложения WordPress, если это ваш рабочий сценарий.
- Посмотрите логи сервера: количество обращений к
xmlrpc.phpдолжно снизиться или исчезнуть.
Для быстрой проверки можно использовать и команду:
curl -i -X POST https://example.com/xmlrpc.phpЕсли всё закрыто корректно, вы не должны получать рабочий ответ на XML-RPC-вызов. Но помните: сам по себе HTTP-статус ещё не гарантирует, что интеграции не сломаны. Проверяйте именно те функции, которые нужны вашему сайту.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив Jetpack
Это самая частая ошибка. Симптомы: пропадает связь с WordPress.com, перестают работать удалённые функции или мобильная публикация. Решение простое: верните доступ и сначала протестируйте нужные модули на копии сайта.
Заблокировали файл, но забыли про кэш и CDN
Иногда старые ответы продолжают отдаваться из кэша, и кажется, что всё работает. На деле доступ уже закрыт, а диагностика идёт по устаревшим данным. После изменения очистите кэш страницы, серверный кэш и CDN.
Использовали слишком жёсткое правило в .htaccess
Если правило написано с ошибкой, можно случайно задеть другие файлы или сломать доступ к сайту на уровне Apache. Перед правкой сохраните резервную копию конфигурации и проверяйте синтаксис после изменений.
Оставили XML-RPC открытым, но надеялись на защиту плагином
Плагин безопасности может помочь, но если endpoint доступен, он всё равно остаётся точкой входа для лишних запросов. Для сайтов без зависимости от XML-RPC лучше закрыть его на уровне сервера или через фильтр WordPress.
Что ещё стоит сделать для безопасности и производительности
Отключение XML-RPC — это только один слой защиты. Чтобы не получить ложное чувство безопасности, проверьте соседние настройки:
- ограничьте попытки входа в админку;
- включите двухфакторную аутентификацию для администраторов;
- убедитесь, что REST API не открыт без необходимости для публичных сценариев;
- проверьте, нет ли лишних внешних интеграций, которые ходят на сайт по старым протоколам;
- следите за логами 404 и POST-запросов к системным файлам.
Если вам нужен более широкий набор настроек для чистки сайта, удаления дублей и технической оптимизации, иногда удобнее собрать это в одном инструменте, чем держать несколько разрозненных плагинов. Но даже в этом случае сначала определяйте, что именно вы закрываете и зачем.
Практический ориентир простой: если XML-RPC не нужен — отключайте его и проверяйте интеграции. Если нужен хотя бы частично — ограничивайте доступ точечно, а не рубите всё без теста.