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