XML-RPC в WordPress часто отключают по двум причинам: лишняя поверхность атаки и ненужные запросы к xmlrpc.php. Но у этого файла есть и легитимные сценарии — например, старые мобильные клиенты, Jetpack и некоторые внешние сервисы публикации. Поэтому правильный подход здесь не «вырубить всё сразу», а сначала понять, используется ли endpoint вообще, а потом отключать его без побочных эффектов.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешнюю публикацию через XML-RPC, а в логах регулярно появляются обращения к /xmlrpc.php, отключение обычно оправдано. Особенно это полезно, когда на сайте нет Jetpack, нет старых приложений для публикации и нет интеграций, которые завязаны именно на XML-RPC, а не на REST API.
С точки зрения безопасности это не панацея, но полезное сокращение лишнего входа. С точки зрения производительности эффект зависит от нагрузки: на спокойном сайте разница может быть незаметной, а на сайте с постоянными попытками брутфорса — вполне ощутимой.
Диагностика: используется ли xmlrpc.php сейчас
Перед отключением проверьте, есть ли реальные обращения к файлу и кто их делает. Самый простой способ — посмотреть access log веб-сервера. Если доступа к логам нет, можно временно отследить запросы через плагины безопасности или мониторинг на уровне хостинга.
Что искать в логах
- запросы
POST /xmlrpc.php; - повторяющиеся обращения с одинаковых IP;
- ошибки 401/403/200 на этот endpoint;
- следы Jetpack или внешних клиентов, если они у вас реально используются.
Если вы видите только шум от ботов, отключение обычно безопасно. Если же в логах есть нормальные запросы от сервисов, сначала перенесите их на другой способ интеграции.
Пошаговое решение: как отключить XML-RPC
Есть три рабочих варианта: через плагин, через код и через веб-сервер. На практике чаще всего удобнее код или плагин, потому что они проще в сопровождении и не зависят от конкретной конфигурации хостинга.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро, без правки темы | Добавляет зависимость, иногда отключает больше, чем нужно |
Код в functions.php или mu-plugin | Точно контролируете поведение | Нужно следить за обновлениями темы |
| Правило на уровне сервера | Режет запросы раньше WordPress | Зависит от nginx/Apache и доступа к конфигу |
Вариант 1: отключение через код
Если нужен прозрачный и обратимый способ, добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Для большинства сайтов достаточно просто запретить сам endpoint:
<?php
add_filter('xmlrpc_enabled', '__return_false');
Этот фильтр отключает XML-RPC на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, WordPress не будет обслуживать такие запросы как обычно.
Если нужно не только отключить функциональность, но и отдать 403 для прямого обращения, можно добавить более жесткую обработку:
<?php
add_action('init', function () {
if (defined('XMLRPC_REQUEST') && XMLRPC_REQUEST) {
status_header(403);
exit;
}
});
Этот вариант полезен, если вы хотите явно блокировать запросы и не полагаться только на фильтр. Но в большинстве случаев первого варианта достаточно.
Вариант 2: блокировка через nginx или Apache
Если у вас есть доступ к конфигурации сервера, блокировка на уровне веб-сервера снимает лишнюю нагрузку раньше, чем запрос дойдет до PHP.
Для nginx можно использовать такое правило:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache подойдет правило в .htaccess или конфигурации виртуального хоста:
<Files "xmlrpc.php">
Require all denied
</Files>
Если сайт работает за CDN или прокси, проверьте, что правило действительно применяется на том уровне, где проходит запрос.
Вариант 3: плагин безопасности
Если вы уже используете плагин, который умеет отключать XML-RPC, можно включить опцию там. Это удобно, когда не хочется держать отдельный код. Но важно понимать, что некоторые плагины безопасности отключают не только XML-RPC, а еще и REST API, pingbacks или другие функции. Перед включением проверьте, что именно меняется.
Если нужен более широкий набор технической чистки и контроля дублей, иногда удобнее собрать это в одном инструменте, например в Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала сверяйте, не затрагивает ли настройка нужные интеграции.
Как проверить, что отключение сработало
Проверка должна быть не формальной, а практической. Откройте /xmlrpc.php в браузере или выполните запрос через curl. В норме вы должны увидеть отказ в доступе или сообщение об отключении, а не рабочий ответ сервиса.
curl -I https://example.com/xmlrpc.php
Ожидаемый результат зависит от способа блокировки: это может быть 403 Forbidden, 405 Method Not Allowed или другой отказ. Главное — чтобы endpoint больше не принимал обычные запросы.
Дополнительно проверьте:
- нет ли ошибок в журнале PHP после отключения;
- не сломалась ли публикация из внешнего клиента, если он у вас был;
- не изменилось ли поведение Jetpack или другого подключенного сервиса;
- не появились ли новые ошибки в мониторинге безопасности.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий. Jetpack может использовать XML-RPC для части функций. Если он вам нужен, не отключайте endpoint вслепую. Сначала проверьте, какие модули Jetpack реально используются, и только потом принимайте решение.
Добавили код в родительскую тему и потеряли его после обновления
Код в functions.php родительской темы — плохое место для таких правок. Используйте дочернюю тему или mu-plugin. Тогда обновление темы не сотрет настройку.
Поставили плагин и получили лишние ограничения
Некоторые плагины безопасности отключают сразу несколько механизмов, а потом сложно понять, что именно сломалось. Если задача точечная, лучше использовать узкий кодовый вариант или правило сервера.
Блокировка есть, но в логах всё равно идут запросы
Это значит, что правило срабатывает не на том уровне. Проверьте, не обходит ли запрос CDN, reverse proxy или кэширующий слой. Иногда нужно блокировать endpoint и на сервере, и на уровне WordPress.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать endpoint нельзя. Например, если у вас есть старый внешний клиент или рабочая интеграция. В таком случае лучше не оставлять всё как есть, а ограничить поверхность риска: закрыть доступ по IP на уровне сервера, включить строгую авторизацию там, где это возможно, и убрать ненужные методы, если вы контролируете интеграцию на своей стороне.
Если задача стоит шире — уменьшить количество технического мусора, дублирующих механизмов и лишних точек входа, имеет смысл смотреть на сайт как на систему: что реально используется, а что осталось «на всякий случай». Именно такие вещи обычно и создают проблемы с безопасностью и сопровождением.
Практические советы по безопасности и производительности
- не отключайте XML-RPC, не проверив зависимости в логах;
- если есть доступ к серверу, блокируйте endpoint на уровне nginx/Apache;
- не храните технические правки в родительской теме;
- после изменений проверьте не только статус ответа, но и реальные сценарии входа или публикации;
- если используете плагин безопасности, пересмотрите, не дублирует ли он уже существующие правила на сервере.
В итоге задача сводится к простой последовательности: сначала диагностика, потом точечная блокировка, затем проверка по логам и реальному поведению сайта. Такой подход безопаснее, чем отключать XML-RPC «на всякий случай» и потом разбираться, почему перестала работать интеграция.