XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, публикация через внешние сервисы или удалённая синхронизация. Проблема в том, что XML-RPC — это не только лишняя поверхность атаки, но и реальный транспорт для старых интеграций. Поэтому правильный подход здесь не «вырубить сразу», а сначала понять, используется ли endpoint /xmlrpc.php, и только потом закрывать его точечно.
Когда XML-RPC действительно стоит отключать
Если сайт не использует Jetpack, мобильное приложение WordPress, внешние клиенты для публикации и старые сервисы автопостинга, XML-RPC обычно не нужен. На многих проектах он остаётся включённым просто по умолчанию, хотя весь рабочий процесс давно переехал на админку и REST API. В таком случае endpoint становится лишней точкой входа для brute force и pingback-атак.
Но есть и обратная ситуация: сайт может быть интегрирован с сервисом, который отправляет записи через XML-RPC, или редакторы публикуют материалы из мобильного приложения. Тогда полное отключение сломает рабочий процесс, и это нужно проверить до изменений.
Диагностика: используется ли xmlrpc.php сейчас
Начните с логов веб-сервера и доступа к endpoint. Если в логах есть регулярные запросы к /xmlrpc.php не только от ботов, но и от ваших сервисов, отключение нужно планировать аккуратно.
Что смотреть в логах
- запросы
POST /xmlrpc.phpс ваших IP или IP интеграций; - частые обращения с кодом ответа
200или403; - ошибки авторизации после публикации из внешнего клиента;
- следы pingback и trackback, если они ещё включены.
Если доступа к логам нет, можно временно добавить простой лог в WordPress и посмотреть, кто обращается к XML-RPC через серверные журналы или WAF.
<?php
// В functions.php дочерней темы или в небольшом mu-plugin.
add_action( 'xmlrpc_call', function( $method ) {
error_log( 'XML-RPC method: ' . $method );
} );Этот способ не покажет все запросы, но поможет понять, какие методы реально вызываются, если endpoint ещё используется.
Как отключить XML-RPC безопасно
Есть три рабочих варианта: через плагин, через код и через серверную блокировку. Для большинства сайтов удобнее код или настройка на уровне веб-сервера. Плагин имеет смысл, если нужен быстрый откат без правок темы.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро включить и выключить, не трогает код темы | Ещё один плагин в стеке, зависит от админки |
| Код | Прозрачно, легко ревизовать в репозитории | Нужно аккуратно тестировать после обновлений |
| Серверная блокировка | Режет запросы до WordPress, меньше нагрузки | Нужно иметь доступ к конфигу Nginx/Apache |
Вариант 1: отключить XML-RPC через код
Если сайт не использует XML-RPC вообще, можно отключить его через фильтр xmlrpc_enabled. Это штатный способ WordPress, без выдуманных хуков и обходных конструкций.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант не ломает остальную часть сайта и работает предсказуемо. Если позже понадобится вернуть endpoint, достаточно убрать фильтр.
Вариант 2: закрыть доступ на уровне сервера
Если цель — не только отключить функциональность, но и снизить нагрузку от массовых запросов, лучше блокировать xmlrpc.php на уровне Nginx или Apache. Это особенно полезно, когда боты долбят endpoint тысячами запросов.
# Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess, если сайт работает на shared-хостинге:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка хороша тем, что запросы не доходят до WordPress и не расходуют PHP-процессы. Но если у вас есть интеграция, она перестанет работать сразу же.
Вариант 3: оставить XML-RPC, но ограничить риск
Иногда endpoint нужен, но только для одного сервиса. В этом случае не стоит отключать его полностью. Лучше ограничить доступ по IP на уровне сервера или WAF и отдельно проверить, что сервис действительно ходит с фиксированного адреса. Это не универсальное решение, но для закрытых интеграций оно практичнее.
Пошаговое решение для типового сайта
- Проверьте логи и список интеграций: Jetpack, мобильное приложение, внешние клиенты публикации, старые сервисы автопостинга.
- Если XML-RPC не нужен, добавьте фильтр
xmlrpc_enabledили серверное правило блокировки. - Проверьте, не используются ли pingback и trackback в настройках обсуждений.
- Протестируйте публикацию, вход в админку и работу форм обратной связи, чтобы не спутать проблему XML-RPC с другой ошибкой.
- Посмотрите, не выросло ли число 403/404/500 в логах после изменения.
Если у вас несколько окружений, сначала проверьте изменения на staging. Это особенно важно, если сайт подключён к мобильному редакторскому процессу или внешней автоматизации.
Как проверить, что отключение сработало
Самый простой тест — открыть /xmlrpc.php в браузере или отправить POST-запрос. При корректной блокировке вы должны получить отказ на уровне сервера или WordPress, а не обычный ответ XML-RPC.
curl -i https://example.com/xmlrpc.phpЕсли endpoint закрыт через WordPress-фильтр, ответ может отличаться от серверной блокировки, но в обоих случаях он не должен принимать рабочие XML-RPC-вызовы. После этого проверьте:
- мобильное приложение WordPress, если оно используется;
- Jetpack и связанные с ним функции;
- публикацию через внешние клиенты;
- логи сервера на предмет повторяющихся ошибок.
Если после отключения редакторы жалуются на невозможность публикации из приложения, значит, XML-RPC был нужен и его нельзя было закрывать полностью.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про интеграции
Это самая частая ошибка. Сайт продолжает работать, но ломается один из внешних сценариев: мобильная публикация, синхронизация или старый сервис автопостинга. Решение простое: сначала список интеграций, потом блокировка.
Поставили плагин и оставили ещё и серверное правило
В итоге диагностика становится мутной: непонятно, где именно режется запрос. Если нужен плагин для временного контроля, не дублируйте его жёстким правилом без понимания последствий. Для постоянной схемы лучше выбрать один уровень блокировки.
Сломали не XML-RPC, а REST API
Иногда после ужесточения безопасности начинают искать причину не там. XML-RPC и REST API — разные механизмы. Если перестали работать блоки редактора, мобильное приложение или интеграции на /wp-json/, это уже другая история и проверять нужно отдельно.
Практические советы по безопасности и производительности
Если XML-RPC не нужен, его отключение — нормальная мера гигиены. Но она не заменяет базовую защиту: сложные пароли, ограничение попыток входа, актуальные обновления ядра, тем и плагинов. Также полезно отключить pingback, если он не используется, потому что он часто связан с лишним шумом в логах и бесполезными запросами.
На загруженных сайтах серверная блокировка предпочтительнее, чем обработка запроса внутри WordPress. Это уменьшает нагрузку на PHP и помогает быстрее отсеивать мусорный трафик. Если у вас есть WAF или CDN, можно добавить правило и там, но только после проверки, что оно не режет легитимные обращения.
Для проектов, где важна чистота технического контура, имеет смысл регулярно проверять не только XML-RPC, но и другие устаревшие точки входа. В таких задачах полезны инструменты для технической чистки сайта, например Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Если после внедрения блокировки всё ещё видите обращения к xmlrpc.php, проверьте не только WordPress, но и CDN, кеширующий прокси и внешние мониторинги. Иногда запросы идут не от пользователей, а от сервисов контроля доступности или старых интеграций, про которые давно забыли.