XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через сторонний сервис или интеграция с десктопным клиентом. Проблема не в самом отключении, а в том, что сначала не проверяют, кто именно использует этот endpoint.
Если задача — убрать лишнюю точку входа и снизить поверхность атаки, делать это нужно не вслепую, а после короткой диагностики. Ниже — рабочий порядок: как понять, нужен ли XML-RPC, как отключить его без побочных эффектов и как проверить, что сайт не сломался.
Когда XML-RPC действительно можно отключить
XML-RPC нужен не всем. На современных сайтах его часто заменяют REST API, прямой вход в админку или интеграции через официальные плагины. Но есть сценарии, где он всё ещё используется:
- старые мобильные приложения WordPress;
- классические десктопные клиенты для публикации;
- внешние сервисы автопостинга и синхронизации;
- некоторые инструменты удалённого управления сайтом;
- устаревшие интеграции, которые не переведены на REST API.
Если хотя бы один из этих сценариев у вас есть, отключать XML-RPC без проверки не стоит. Лучше сначала выяснить, кто обращается к /xmlrpc.php.
Диагностика: кто использует xmlrpc.php
Самый практичный способ — посмотреть логи веб-сервера. Если у вас есть доступ к access log, ищите запросы к xmlrpc.php за последние дни или недели. Это даст реальную картину, а не предположение.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов много, полезно посмотреть IP-адреса и user-agent. Иногда это боты, иногда — ваш собственный сервис. Важно не только наличие запросов, но и их тип: успешные вызовы, ошибки авторизации, повторяющиеся попытки.
Ещё один простой тест — временно переименовать endpoint на уровне блокировки и проверить, что именно перестанет работать. Но делать это лучше на staging-копии, а не на боевом сайте.
Что проверить до отключения
- используется ли мобильное приложение WordPress;
- есть ли внешняя публикация через сторонний сервис;
- настроены ли старые интеграции с Jetpack или похожими инструментами;
- есть ли в логах обращения к
xmlrpc.phpне только от ботов, но и от ваших IP; - не завязаны ли на XML-RPC резервные сценарии администрирования.
Как отключить XML-RPC безопасно
Есть три реалистичных подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, нужен ли вам быстрый откат и есть ли доступ к конфигурации сервера.
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Если нужен быстрый и обратимый вариант | Добавляет ещё один слой логики в админке |
| Код в теме или mu-plugin | Если нужен контролируемый вариант без лишних зависимостей | Нужно не забыть про обновления и перенос |
| Блокировка на сервере | Если хотите отрезать доступ раньше PHP | Требует доступа к Nginx/Apache |
Вариант 1: отключить через код
Если нужен точечный и понятный способ, добавьте фильтр в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так решение не потеряется при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Но если вы хотите ещё и не отдавать сам файл наружу, лучше добавить серверную блокировку.
Вариант 2: заблокировать доступ на уровне Nginx
Если сайт работает на Nginx, можно сразу возвращать 403 для /xmlrpc.php. Это снижает лишнюю нагрузку и не отдаёт запрос в PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 403;
}Для Apache логика будет другой, но смысл тот же: не обрабатывать endpoint, если он вам не нужен. Если вы не уверены в конфигурации, сначала проверьте это на staging и только потом переносите на прод.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин для базовой защиты, проверьте, есть ли в нём опция отключения XML-RPC. Это удобно, когда вы не хотите править код и конфиги вручную. Но не стоит ставить отдельный плагин только ради одной галочки, если задача решается кодом.
Для сайтов, где одновременно нужно убрать дубли, почистить технический мусор и закрыть лишние точки входа, иногда удобнее использовать набор инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и здесь важно не включать всё подряд — только те функции, которые реально нужны.
Пошаговая схема внедрения
- Проверьте access log и список интеграций.
- Сделайте резервную копию или хотя бы снимок staging-сайта.
- Выберите способ отключения: код, сервер или плагин.
- Внесите изменение и очистите кеш, если он есть.
- Проверьте, что
/xmlrpc.phpбольше не отвечает как раньше. - Протестируйте все внешние сценарии публикации и входа.
Как проверить, что отключение сработало
Проверка должна быть не формальной, а прикладной. Откройте в браузере https://ваш-домен.ru/xmlrpc.php. В зависимости от способа блокировки вы увидите либо 403, либо ответ WordPress о том, что XML-RPC отключён, либо другой контролируемый отказ.
Дальше проверьте реальные сценарии:
- открывается ли мобильное приложение WordPress;
- работает ли публикация из внешнего сервиса;
- не появились ли ошибки в логах после отключения;
- не растёт ли количество 404/403 на
xmlrpc.phpот ваших собственных сервисов.
Если у вас есть мониторинг, полезно посмотреть не только доступность страницы, но и ошибки авторизации или всплески запросов к endpoint. Иногда отключение XML-RPC просто переводит старую интеграцию в бесконечные повторы запросов, и это тоже нужно заметить.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали публикацию из мобильного приложения
Значит, не проверили зависимости. Решение простое: либо вернуть XML-RPC, либо перевести этот сценарий на другой способ публикации. Если приложение критично, не блокируйте endpoint без согласования с пользователями.
Поставили плагин, но endpoint всё равно отвечает
Некоторые плагины отключают только функциональность внутри WordPress, но не блокируют сам файл на уровне сервера. В таком случае запрос доходит до PHP. Если нужна жёсткая блокировка, добавьте правило в Nginx или Apache.
После изменения остался старый кеш
Иногда браузерный или серверный кеш показывает старый ответ. Очистите кеш плагина, CDN и, если нужно, объектный кеш. Иначе можно решить, что отключение не сработало, хотя на самом деле вы смотрите на устаревшую копию.
Сломали доступ для внешнего сервиса, но не знаете какого
Смотрите access log по времени ошибки. Обычно источник видно по IP, частоте запросов или user-agent. Если сервис корпоративный, проверьте его настройки и документацию: возможно, он умеет работать через REST API.
Практические советы по безопасности и производительности
Отключение XML-RPC не делает сайт «защищённым полностью», но убирает один лишний вектор атак. Это особенно полезно, если у вас уже есть другие меры: ограничение попыток входа, двухфакторная авторизация, актуальные обновления ядра и плагинов.
С точки зрения производительности выигрыш обычно не драматический, но он есть: меньше бессмысленных обращений к PHP и меньше шума в логах. На сайтах с постоянными брутфорс-атаками это заметно по нагрузке и по объёму мусорных запросов.
Если вам нужно не только закрыть XML-RPC, но и убрать другие технические дубли и лишние точки доступа, имеет смысл смотреть на сайт как на систему целиком: индексация, кеш, архивы, служебные endpoints, старые интеграции. Тогда отключение одной функции не создаст новую проблему в другом месте.
В итоге рабочая схема простая: сначала диагностика, потом отключение, затем проверка реальных сценариев. Именно так XML-RPC убирается без сюрпризов, а не «по совету из интернета».