XML-RPC в WordPress часто отключают «на всякий случай», а потом неожиданно ломают мобильное приложение, внешнюю публикацию или старый сервис, который всё ещё ходит в xmlrpc.php. На практике задача не в том, чтобы просто заблокировать файл, а в том, чтобы понять, нужен ли он вообще и чем его заменить, если нужен.
Если у вас сайт без внешних интеграций, отключение XML-RPC обычно упрощает поверхность атаки. Но если вы используете Jetpack, старые клиенты для публикации, сервисы автопостинга или сторонние интеграции, сначала проверьте зависимости. Иначе получите не «усиление безопасности», а тихую поломку сценариев, которые не видны в админке.
Когда XML-RPC действительно стоит отключать
Сам по себе xmlrpc.php не является ошибкой. Проблема в том, что этот интерфейс исторически часто используют для перебора паролей, pingback-атак и лишних запросов к сайту. Если вам не нужны удалённые публикации и внешние клиенты, держать его открытым смысла мало.
Сначала проверьте, кто его использует
Перед изменениями посмотрите логи веб-сервера или хотя бы отфильтруйте обращения к /xmlrpc.php. Если запросы идут регулярно, это уже сигнал: либо кто-то реально использует интерфейс, либо сайт постоянно сканируют.
Простой чек-лист диагностики:
- есть ли у вас Jetpack или похожие сервисы, которым нужен XML-RPC;
- используются ли мобильные приложения WordPress для публикации;
- есть ли внешние системы автопостинга или импорта контента;
- есть ли в логах частые POST-запросы к
xmlrpc.php; - не завязан ли на XML-RPC старый плагин или кастомная интеграция.
Как отключить XML-RPC: сравнение подходов
Есть несколько рабочих способов, и у каждого свой компромисс. Для большинства сайтов лучше не начинать с «жёсткой» блокировки на уровне сервера, пока не проверены зависимости.
| Способ | Что делает | Плюс | Минус |
|---|---|---|---|
| Фильтр в WordPress | Отключает XML-RPC на уровне ядра | Легко откатить, удобно тестировать | Не защищает от прямого доступа к файлу на уровне веб-сервера |
| Блокировка в Nginx/Apache | Запрещает запросы к xmlrpc.php | Жёсткая защита, меньше лишней нагрузки | Можно случайно сломать интеграции |
| Плагин безопасности | Даёт переключатель в админке | Быстро для типового сайта | Лишняя зависимость, не всегда понятно, что именно отключено |
Пошаговое решение через код
Если нужен контролируемый вариант, начните с фильтра. Его удобно добавить в мини-плагин или в functions.php дочерней темы, но для продакшна надёжнее отдельный mu-plugin.
Вариант 1: отключить XML-RPC через фильтр
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет принимать XML-RPC-запросы на уровне ядра. Это хороший первый шаг, если вы хотите быстро проверить, не завязаны ли на него внешние сервисы.
Вариант 2: вернуть 403 на уровне WordPress
Если нужно не просто отключить функциональность, а явно блокировать обращения, можно отдать 403. Это полезно, когда вы хотите видеть предсказуемое поведение для сканеров и ботов.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Этот вариант не заменяет серверную блокировку, но помогает, если вы не хотите трогать конфигурацию Nginx или Apache.
Блокировка на уровне сервера: когда это уместно
Если вы уже убедились, что XML-RPC не нужен, логичнее закрыть доступ на уровне веб-сервера. Так вы отсечёте лишние запросы раньше, чем они дойдут до WordPress.
Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Apache
<Files "xmlrpc.php">
Require all denied
</Files>После таких правок обязательно проверьте, не используется ли файл каким-то сервисом. Серверная блокировка хороша тем, что она экономит ресурсы, но именно поэтому откатить проблему потом сложнее, если вы не сделали предварительную диагностику.
Как проверить, что отключение сработало
Проверка должна быть не «на глаз», а по факту ответа сервера. Откройте https://example.com/xmlrpc.php в браузере или выполните запрос из консоли.
curl -i https://example.com/xmlrpc.phpЧто считать нормальным результатом:
- при фильтре WordPress — отказ в обработке XML-RPC;
- при серверной блокировке —
403 Forbidden; - при обращении через браузер — отсутствие стандартного ответа WordPress о доступности XML-RPC;
- в логах — резкое снижение или исчезновение обращений к файлу после внедрения.
Если у вас есть интеграция, которая раньше работала через XML-RPC, протестируйте её отдельно: публикацию записи, отправку черновика, синхронизацию из внешнего сервиса. Не ограничивайтесь проверкой главной страницы сайта.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив Jetpack
Jetpack и некоторые похожие сервисы могут использовать XML-RPC для связи с сайтом. Если после блокировки отвалились статистика, удалённая публикация или синхронизация, сначала подтвердите зависимость, потом решайте, чем заменить сценарий.
Поставили плагин безопасности и забыли, что он делает
У некоторых плагинов переключатель «Disable XML-RPC» работает не так, как ожидается: где-то он блокирует только часть методов, где-то добавляет правила в .htaccess, а где-то просто скрывает настройку. Если нужен предсказуемый результат, лучше использовать один понятный способ и документировать его.
Заблокировали файл, но оставили pingback-логику
Даже если xmlrpc.php закрыт, на старых сайтах могут оставаться связанные механизмы, которые создают шум в логах или лишнюю нагрузку. После отключения проверьте, не идут ли попытки pingback и не появляются ли ошибки в журнале сервера.
Сделали правку в родительской теме
Если вы добавили код в functions.php активной темы, обновление может его затереть. Для постоянного решения используйте дочернюю тему или отдельный mu-plugin.
Что делать, если XML-RPC всё-таки нужен
Если отключать интерфейс нельзя, не оставляйте его без защиты. Минимум, который имеет смысл сделать: ограничить доступ по IP для доверенных сервисов, включить нормальную защиту от перебора паролей, следить за логами и не держать открытыми лишние методы, если это позволяет ваш сценарий.
Для большинства сайтов практичный путь такой: сначала проверить зависимости, потом отключить XML-RPC через фильтр, затем при подтверждённой ненужности закрыть xmlrpc.php на сервере. Это даёт и контроль, и понятный откат, если что-то пошло не так.
Если у вас на сайте уже есть проблемы с дублями, индексируемыми мусорными URL и лишними техническими сущностями, имеет смысл параллельно проверить общую технику сайта. В таких задачах часто помогает Clearfy Pro: он закрывает часть типовых SEO- и технических настроек без ручного разрастания кода, но использовать его стоит только там, где вы понимаете, что именно отключаете.