XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильные клиенты, удалённая публикация или старые интеграции. Проблема не в самом XML-RPC, а в том, что его выключают без проверки зависимостей. Ниже — рабочий сценарий: как понять, нужен ли он вам, как отключить его без лишнего риска и как проверить, что сайт после этого ведёт себя нормально.
Когда XML-RPC действительно мешает
Если сайт не использует удалённую публикацию, старые приложения WordPress, внешние сервисы, которые ходят в /xmlrpc.php, или pingback/trackback, то XML-RPC чаще всего только расширяет поверхность атаки. На практике его отключают ради снижения шума от брутфорса и для того, чтобы убрать ненужную точку входа. Но если у вас есть мобильное приложение WordPress, Jetpack или сторонний сервис автопостинга, сначала проверьте, не завязаны ли они на XML-RPC.
Быстрая диагностика перед изменениями
Сначала посмотрите, кто вообще обращается к /xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите запросы к этому файлу и оцените, это реальные клиенты или только попытки перебора.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если доступа к логам нет, проверьте сам endpoint из браузера или через curl. Нормально, если файл отвечает текстом про XML-RPC сервер WordPress; после отключения он должен возвращать 403 или 404 в зависимости от способа блокировки.
curl -I https://example.com/xmlrpc.phpЕщё один практический шаг — вспомнить, какие сервисы подключены к сайту:
- мобильное приложение WordPress;
- Jetpack и похожие сервисы;
- автопостинг в соцсети через старые плагины;
- внешние CRM или агрегаторы, которые публикуют записи по XML-RPC;
- старые клиенты для удалённого редактирования.
Как отключить XML-RPC: сравнение подходов
Есть три нормальных варианта. Выбор зависит от того, насколько жёстко вы хотите блокировать доступ и есть ли у вас Nginx/Apache на уровне сервера.
| Способ | Плюсы | Минусы |
|---|---|---|
Код в functions.php или мини-плагине | Просто внедрить, легко откатить | Не блокирует запрос на уровне веб-сервера, а только отключает обработку в WordPress |
| Правило в Nginx/Apache | Режет доступ раньше, меньше лишней нагрузки | Нужно править конфиг сервера и иметь доступ к нему |
| Плагин безопасности | Удобно для админов без доступа к серверу | Добавляет ещё один слой логики и зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Если вам нужен быстрый и обратимый вариант, добавьте фильтр в мини-плагин или в functions.php дочерней темы. Для продакшена мини-плагин надёжнее: он не исчезнет при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключит обработку XML-RPC внутри WordPress. Для большинства сайтов этого достаточно, если цель — убрать удалённую публикацию и снизить риск перебора паролей через этот канал.
Вариант 2: заблокировать доступ на уровне веб-сервера
Если у вас Nginx, можно отдать 403 для /xmlrpc.php. Это полезно, когда вы хотите не просто отключить функциональность, а ещё и не тратить ресурсы на обработку запроса.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Если сайт работает за CDN или прокси, проверьте, что блокировка не ломает кэширование и не конфликтует с правилами безопасности на уровне хостинга.
Вариант 3: отключить только pingback, если XML-RPC нужен частично
Иногда XML-RPC нужен для внешнего клиента, но pingback и trackback — нет. Тогда можно точечно убрать pingback, не трогая весь механизм. Это более аккуратный вариант, если вы не уверены, что все интеграции уже переведены на REST API.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Пошаговое решение без сюрпризов
- Проверьте логи и список подключённых сервисов.
- Решите, нужен ли XML-RPC полностью или только частично.
- Сделайте резервную копию файла конфигурации или подготовьте отдельный мини-плагин.
- Внедрите блокировку кодом или на уровне сервера.
- Проверьте ответ
/xmlrpc.phpи тестовые сценарии публикации. - Посмотрите логи ошибок и access log после изменения.
Если вы предпочитаете плагин, выбирайте тот, который явно умеет отключать XML-RPC и не навязывает лишние функции. Для сайтов, где одновременно нужно чистить технические дубли, отключать лишние скрипты и убирать мусор из head, иногда удобнее использовать комплексный инструмент вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но если задача только в XML-RPC, код или серверное правило обычно проще и прозрачнее.
Как проверить, что всё сработало
После внедрения не ограничивайтесь открытием главной страницы. Нужны проверки именно по точке риска.
- Откройте
/xmlrpc.phpв браузере или черезcurl -I. - Убедитесь, что ответ стал
403или404, если вы блокировали доступ. - Проверьте, не сломалась ли публикация из мобильного приложения или внешнего клиента.
- Посмотрите access log: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Если у вас включён мониторинг ошибок, проверьте, не появились ли новые записи после изменения.
Хороший практический тест — попытаться выполнить удалённую публикацию тем способом, который использовался раньше. Если интеграций нет, этого достаточно. Если интеграции есть, тестируйте их до и после изменения на одном и том же аккаунте.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Jetpack и похожие сервисы могут использовать XML-RPC для связи с сайтом. Если сервис нужен, не блокируйте endpoint полностью. Сначала проверьте документацию конкретного продукта и только потом решайте, можно ли перейти на другой способ связи.
Поставили код в тему, а после обновления он исчез
Это классическая ошибка. Для таких правок лучше использовать дочернюю тему или мини-плагин. Тогда отключение не пропадёт после обновления темы.
Заблокировали файл на сервере, но WordPress всё равно отвечает
Так бывает, если правило добавили не в тот виртуальный хост, не в тот .htaccess или запрос обрабатывается через другой слой прокси. Проверьте конфигурацию именно того сервера, который реально принимает запрос.
Отключили XML-RPC, но брутфорс не уменьшился
Это нормально, если атакуют не только через XML-RPC, но и через wp-login.php. В этом случае нужно отдельно смотреть ограничения по логину, rate limiting, двухфакторную аутентификацию и защиту на уровне WAF.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC — не замена нормальной защите. Если вы уже трогаете этот участок, имеет смысл проверить соседние настройки:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- отключение ненужных pingback/trackback, если они не используются;
- актуальность ядра, тем и плагинов;
- наличие WAF или хотя бы базовых правил на уровне хостинга.
С точки зрения производительности выигрыш от отключения XML-RPC обычно не драматический, но на шумных сайтах он помогает убрать лишние запросы и уменьшить нагрузку от мусорного трафика. Главное — не ломать рабочие интеграции ради формальной «безопасности».
Если нужен аккуратный технический аудит сайта после таких изменений, удобно проверять не только endpoint, но и связанные настройки индексации, дубли и лишние элементы в шаблоне. Именно здесь часто всплывают проблемы, которые маскируются под «безопасность», но на деле связаны с общей гигиеной WordPress.