XML-RPC в WordPress часто отключают по одной причине: через него удобно атаковать сайт брутфорсом и дергать лишние методы, если они вообще не нужны. Но у этого решения есть обратная сторона: часть интеграций до сих пор опирается на /xmlrpc.php. Если просто закрыть файл без проверки, можно сломать публикацию через внешние клиенты, Jetpack или старые мобильные сценарии.
Ниже — рабочий порядок действий: как понять, нужен ли XML-RPC именно вам, как отключить его без лишнего риска и как быстро проверить результат.
Когда XML-RPC действительно стоит отключать
Отключение имеет смысл, если сайт не использует внешние приложения для публикации и не завязан на сервисы, которым нужен этот endpoint. На обычных корпоративных и контентных сайтах XML-RPC чаще всего не нужен вообще.
Типичные признаки, что XML-RPC можно закрыть
- публикация идет только из админки WordPress;
- Jetpack не используется или его функции, завязанные на XML-RPC, не нужны;
- нет старых интеграций с мобильными клиентами и десктопными редакторами;
- в логах видны частые обращения к
/xmlrpc.phpс попытками подбора пароля.
Когда лучше не отключать
Если вы публикуете записи через внешние редакторы, используете Jetpack для синхронизации или у вас есть старый рабочий процесс, который опирается на XML-RPC, сначала проверьте, можно ли заменить его REST API или штатными способами WordPress. В противном случае отключение приведет к неочевидным сбоям: запросы будут уходить, но публикация не пройдет.
Диагностика: нужен ли endpoint вашему сайту
Перед изменениями проверьте, отвечает ли xmlrpc.php и кто его дергает. Это можно сделать без плагинов.
curl -I https://example.com/xmlrpc.phpЕсли endpoint открыт, сервер обычно вернет не 404. Это еще не проблема само по себе, но повод посмотреть логи веб-сервера или WAF. На практике полезно искать повторяющиеся POST-запросы к этому файлу с разных IP.
Если у вас есть доступ к журналам Nginx или Apache, проверьте частоту обращений. Для Nginx это обычно выглядит как строки с POST /xmlrpc.php. Если таких запросов много и они не связаны с вашими сервисами, отключение оправдано.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, как устроен сайт. Если нужен быстрый и обратимый способ — используйте фильтр в теме или мини-плагине. Если нужен уровень сервера — блокируйте запросы на веб-сервере. Если вы не хотите писать код, можно использовать плагин безопасности, но это уже компромисс по контролю.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в WordPress | Прозрачно, легко откатить, не зависит от плагинов | Нужно аккуратно разместить код |
| Правило на сервере | Режет запросы раньше WordPress, экономит ресурсы | Нужен доступ к конфигу Nginx/Apache |
| Плагин безопасности | Быстро для админов без доступа к серверу | Лишняя зависимость, настройки могут отличаться |
Вариант 1. Отключить XML-RPC через код
Самый предсказуемый способ — запретить сам файл и убрать pingback. Добавьте код в мини-плагин или в functions.php дочерней темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
if ( isset( $headers['X-Pingback'] ) ) {
unset( $headers['X-Pingback'] );
}
return $headers;
} );
add_filter( 'pings_open', '__return_false' );Этого обычно достаточно, чтобы WordPress перестал обслуживать XML-RPC как штатный механизм. Но если сервер все еще отдает сам файл, лучше дополнить решение блокировкой на уровне веб-сервера.
Вариант 2. Заблокировать xmlrpc.php на сервере
Если сайт работает на Nginx, можно отдать 403 для этого файла. Это полезно, когда вы хотите отсечь запросы до загрузки WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка особенно полезна, если сайт регулярно получает брутфорс по этому endpoint. Она не решает все проблемы безопасности, но уменьшает шум и нагрузку.
Вариант 3. Использовать плагин безопасности
Если у вас уже стоит плагин с функцией отключения XML-RPC, это допустимо. Но проверьте, что он действительно блокирует запросы, а не только скрывает опцию в интерфейсе. Важно смотреть на фактический ответ /xmlrpc.php, а не на галочку в настройках.
Пошаговое внедрение без сюрпризов
- Сделайте резервную копию файлов и базы, если правите серверный конфиг или тему.
- Проверьте, какие интеграции используют XML-RPC: Jetpack, внешние редакторы, мобильные клиенты.
- Выберите способ блокировки: код, сервер или плагин.
- Внесите изменение сначала на staging, если он есть.
- Проверьте ответ
/xmlrpc.phpи протестируйте рабочие сценарии публикации. - Если все работает, перенесите изменение на продакшен.
Если вы ведете несколько сайтов, удобнее оформить код в отдельный mu-plugin. Тогда правило не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте endpoint напрямую и посмотрите код ответа:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на сервере, ожидайте 403 или 404 в зависимости от правила. Если отключали через WordPress, поведение может отличаться, но endpoint не должен использоваться как рабочий канал публикации.
Дальше проверьте ваши реальные сценарии:
- если используете Jetpack — выполните синхронизацию и убедитесь, что нужные функции не отвалились;
- если публикуете из внешнего клиента — попробуйте создать черновик или запись;
- если есть мобильное приложение — проверьте авторизацию и отправку контента;
- посмотрите логи сервера: обращения к
/xmlrpc.phpдолжны либо исчезнуть, либо получать отказ.
Частые ошибки и как их исправить
Сломали Jetpack и не поняли почему
Причина обычно в том, что XML-RPC был нужен для части функций Jetpack. Решение простое: либо вернуть endpoint, либо отказаться от конкретной функции и перейти на другой способ интеграции. Не отключайте XML-RPC вслепую на сайте, где уже есть завязки на внешние сервисы.
Отключили кодом, но запросы все равно доходят
Значит, WordPress уже получил запрос и только потом отказал. Это не ошибка кода, но и не лучший вариант для сайта под нагрузкой. Добавьте блокировку на уровне Nginx или Apache.
Поставили плагин, но endpoint по-прежнему отвечает
Некоторые плагины меняют только поведение WordPress, но не закрывают сам файл на сервере. Проверьте реальный HTTP-ответ. Если нужен жесткий запрет, используйте серверное правило.
Скопировали код в родительскую тему
После обновления темы правило может исчезнуть. Для таких задач лучше использовать дочернюю тему или mu-plugin.
Что учесть для безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа. Если у вас слабые пароли, открытая админка и нет ограничения попыток входа, проблема останется. Но закрытие ненужного endpoint снижает поверхность атаки и убирает лишние запросы.
Если сайт часто атакуют по /xmlrpc.php, полезно дополнительно:
- включить ограничение попыток входа;
- использовать двухфакторную аутентификацию для админов;
- проверить правила WAF/CDN;
- убрать ненужные сервисы, которые держат XML-RPC открытым без причины.
Если вам нужен более широкий набор точечных настроек безопасности и чистки сайта, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае все равно стоит проверить, что именно отключается и как это влияет на ваши интеграции.
Главный критерий здесь простой: если после изменения сайт перестал принимать только те запросы, которые вам не нужны, а рабочие сценарии не пострадали, решение внедрено правильно.