XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, внешние клиенты для публикации и некоторые мобильные сценарии. Проблема в том, что это не просто старый интерфейс обмена данными, а точка входа для интеграций, которые у части сайтов всё ещё используются.
Если задача стоит практично — убрать лишнюю поверхность атаки и при этом не поломать рабочие подключения, — сначала нужно понять, кто именно обращается к /xmlrpc.php, а уже потом выбирать способ блокировки.
Когда XML-RPC действительно стоит отключать
На большинстве обычных сайтов XML-RPC не нужен, если вы не используете внешние приложения для публикации, старые мобильные клиенты и сервисы, которые до сих пор ходят через этот endpoint. Для безопасности это полезная точка сокращения риска: именно сюда часто бьют перебором паролей и попытками массовых запросов.
Но есть важная оговорка: если у вас подключён Jetpack, приложение WordPress на телефоне, сторонний планировщик публикаций или интеграция с внешним сервисом, отключение может сломать синхронизацию или авторизацию.
Быстрая диагностика: нужен ли XML-RPC вашему сайту
Проверка занимает пару минут и экономит много времени на откатах. Смотрите на реальные признаки использования:
- в админке Jetpack показывает ошибки соединения;
- мобильное приложение WordPress не публикует записи;
- в логах веб-сервера есть запросы к
/xmlrpc.phpот доверенных сервисов; - вы используете внешние клиенты публикации или старые интеграции;
- на сайте нет ни одной причины оставлять удалённый постинг через XML-RPC.
Если сомневаетесь, временно не блокируйте endpoint полностью, а сначала ограничьте доступ по логам и проверьте, кто обращается к файлу.
Как отключить XML-RPC безопасно
Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Для большинства сайтов самый предсказуемый вариант — код в теме или mu-plugin, потому что поведение видно и легко откатить.
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Если нужен быстрый переключатель без правки кода | Лишняя зависимость и иногда избыточные функции |
Код в functions.php или mu-plugin | Если нужен точный контроль и понятный откат | Нужно аккуратно тестировать после обновлений темы |
| Блокировка на сервере | Если нужно жёстко закрыть endpoint до PHP | Можно случайно сломать интеграции без диагностики |
Вариант 1: отключить XML-RPC через код
Если вы уверены, что endpoint не нужен, добавьте фильтр в functions.php дочерней темы или в отдельный mu-plugin:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый короткий способ. WordPress перестанет обслуживать XML-RPC-запросы, и большинство попыток обращения к /xmlrpc.php будут получать отказ.
Вариант 2: закрыть только опасные методы, а не весь XML-RPC
Если вам нужен сам endpoint для Jetpack или мобильного приложения, но вы хотите убрать часть рисков, можно фильтровать методы. Например, отключить публикацию через XML-RPC, оставив базовые сценарии:
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['wp.newPost'] );
unset( $methods['wp.editPost'] );
unset( $methods['wp.deletePost'] );
return $methods;
} );Этот вариант полезен, когда нужно сохранить совместимость, но убрать удалённое создание и редактирование записей. Подходит не для всех интеграций, поэтому после внедрения обязательно проверьте свои сценарии публикации.
Вариант 3: блокировка на уровне Nginx или Apache
Если задача — снизить нагрузку и не отдавать запросы в PHP вообще, можно закрыть xmlrpc.php на уровне веб-сервера. Для Nginx это обычно выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Этот способ жёстче, чем фильтр WordPress. Он хорош, когда вы точно знаете, что XML-RPC не нужен, но хуже для диагностики: если что-то сломается, причина не всегда очевидна с первого взгляда.
Пошаговый план внедрения без сюрпризов
- Проверьте, используется ли Jetpack, мобильное приложение WordPress или внешняя публикация.
- Посмотрите access log и найдите обращения к
/xmlrpc.php. - Выберите способ: полный запрет, частичное ограничение или серверная блокировка.
- Внесите изменение сначала на staging-копии сайта.
- Проверьте авторизацию, публикацию и синхронизацию после правки.
- Только потом переносите изменение на боевой сайт.
Как проверить, что отключение сработало
Проверка должна быть не только «страница открывается», а именно по точке входа XML-RPC. Самый простой тест — открыть https://ваш-домен/xmlrpc.php в браузере. Если endpoint отключён, вы не должны увидеть рабочий ответ WordPress.
Для более точной проверки можно отправить тестовый запрос. Например, через curl:
curl -i https://example.com/xmlrpc.phpЕсли блокировка настроена корректно, вы увидите отказ в доступе, ошибку 403 или другой неуспешный ответ в зависимости от способа блокировки. Если же приходит стандартный ответ WordPress, значит endpoint всё ещё доступен.
После этого проверьте прикладные сценарии:
- Jetpack подключается без ошибок;
- мобильное приложение WordPress публикует запись, если оно вам нужно;
- внешние сервисы синхронизации не потеряли доступ;
- в логах больше нет лишних обращений к XML-RPC от ботов.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина обычно простая: Jetpack использует этот канал для части обмена данными. Решение — не отключать endpoint полностью, а ограничить только опасные методы или отказаться от блокировки на уровне сервера.
Добавили код в родительскую тему и потеряли изменение после обновления
Если правка лежит в functions.php основной темы, она может исчезнуть при обновлении. Для постоянных технических изменений лучше использовать дочернюю тему или mu-plugin.
Поставили плагин безопасности, но XML-RPC всё равно отвечает
Не все плагины блокируют endpoint одинаково. Иногда они только ограничивают отдельные методы или включают защиту при определённых настройках. Проверьте, что именно делает плагин, и не полагайтесь на название опции без теста.
Закрыли XML-RPC в Nginx, но забыли про staging
Если у вас несколько окружений, правило может быть применено только на одном сервере. Сравните конфигурации и убедитесь, что изменение внесено там, где реально работает сайт.
Что ещё стоит сделать для безопасности
Отключение XML-RPC — не замена нормальной защите входа. Если у сайта есть брутфорс по wp-login.php, слабые пароли или открытый REST API без нужды, одна эта мера проблему не решит.
- включите ограничение попыток входа или защиту на уровне WAF;
- используйте сложные пароли и двухфакторную аутентификацию для админов;
- проверьте, не открыт ли лишний функционал в REST API;
- уберите неиспользуемые интеграции, которые обращаются к старым endpoint’ам;
- следите за логами после изменений, чтобы не пропустить сломанный сценарий.
Если нужен более широкий технический аудит сайта, удобно сначала убрать дубли, мусорные настройки и лишние точки входа, а уже потом резать интеграции. В таких задачах часто помогает Clearfy Pro, если вам нужен набор практических инструментов для чистки и SEO-оптимизации: https://wpshop.ru/plugins/clearfy.
Если подойти к задаче без спешки, XML-RPC можно отключить без побочных эффектов. Ключевой момент — не делать это вслепую: сначала диагностика, потом точечная блокировка, затем проверка рабочих сценариев.