XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, удалённая публикация или интеграция с внешним сервисом. На практике задача не в том, чтобы просто заблокировать xmlrpc.php, а в том, чтобы понять, нужен ли он вообще именно вашему сайту, и если нужен — ограничить риск без побочных эффектов.
Если сайт не использует старые внешние клиенты, удалённую публикацию и сервисы, завязанные на XML-RPC, этот интерфейс обычно можно закрыть. Но перед изменениями стоит проверить зависимости: некоторые плагины и сервисы до сих пор обращаются к нему для авторизации, синхронизации или отправки контента.
Когда XML-RPC действительно стоит отключать
Сценарий простой: если вы не публикуете записи через внешние клиенты, не используете Jetpack-функции, завязанные на XML-RPC, и не подключали сервисы автопостинга через этот протокол, то держать его открытым смысла мало. Файл xmlrpc.php часто становится точкой для перебора паролей и лишних запросов, особенно на сайтах без нормального ограничения по частоте обращений.
Но есть и обратная сторона. Если сайт уже интегрирован с мобильным приложением WordPress, некоторыми редакторскими инструментами или старым ПО для публикации, отключение без проверки даст не «усиление безопасности», а просто поломку рабочего процесса. Поэтому сначала диагностика, потом блокировка.
Диагностика: как понять, используется ли XML-RPC
Самый практичный способ — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в журнале безопасности плагина. Если вы видите регулярные запросы от известных сервисов, сначала выясните источник. Если запросы идут только от ботов с попытками авторизации, это уже аргумент в пользу отключения.
Что проверить перед изменением
- используется ли мобильное приложение WordPress для публикации;
- подключён ли Jetpack и какие его функции реально нужны;
- есть ли внешние сервисы автопостинга, мониторинга или импорта;
- не работает ли редакторский процесс через старый клиент, который отправляет записи по XML-RPC;
- есть ли в логах частые POST-запросы к
xmlrpc.php.
Если доступа к логам нет, можно временно проверить ответ сервера на прямой запрос. Это не покажет все зависимости, но даст понимание, открыт ли endpoint вообще.
curl -i https://example.com/xmlrpc.phpНормальный ответ сам по себе ещё не означает проблему. Важнее понять, нужен ли этот endpoint вашему стеку. Если сайт небольшой, без внешней публикации и без интеграций, чаще всего ответ будет «нет».
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, нужен ли вам полный запрет или только защита от злоупотреблений. Полное отключение удобно, если вы точно не используете XML-RPC. Ограничение через плагин или серверный уровень подходит, если нужно оставить совместимость с частью сервисов.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин безопасности | Быстро, без правки кода | Зависимость от плагина | Если нужен простой контроль без разработки |
| Код в теме или mu-plugin | Прозрачно, без лишних интерфейсов | Нужно аккуратно поддерживать | Если вы управляете сайтом как разработчик |
| Блокировка на уровне сервера | Ранний отказ, меньше нагрузки | Требует доступа к конфигу | Если есть доступ к nginx/apache и нужен жёсткий запрет |
Вариант 1: отключить через код
Если нужен именно полный запрет, можно отключить XML-RPC фильтром. Такой способ подходит для небольших сайтов, где вы контролируете кодовую базу. Лучше добавлять это в mu-plugin, а не в тему: так правило не исчезнет при смене шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет обслуживать XML-RPC-запросы штатным способом. Это не панацея от всех атак, но убирает сам интерфейс, который вам не нужен.
Вариант 2: закрыть доступ на уровне веб-сервера
Если у вас nginx, можно отдать 403 на запросы к xmlrpc.php. Это полезно, когда вы хотите отсечь обращения ещё до загрузки WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правила в .htaccess, но там важно не ломать общий обработчик сайта. Если конфигом управляет хостинг, сначала проверьте, допускает ли он такие правки.
Вариант 3: ограничить, а не отключать
Если XML-RPC нужен только для одного сервиса, иногда лучше не выключать его полностью, а ограничить доступ по IP на уровне сервера или WAF. Это компромиссный вариант: меньше поверхность атаки, но сохраняется совместимость с доверенным источником.
Проверка результата после внедрения
После отключения проверьте не только сам endpoint, но и рабочие сценарии, которые могли зависеть от него. Иначе можно получить «безопасный» сайт, на котором перестала публиковаться часть контента или отвалилась синхронизация.
Что должно быть в проверке
- открыть
/xmlrpc.phpв браузере или черезcurlи убедиться, что доступ закрыт; - проверить, не появились ли ошибки в логах PHP и веб-сервера;
- сделать тестовую публикацию через обычную админку WordPress;
- если есть Jetpack или внешняя интеграция — проверить их статус;
- посмотреть, не выросло ли число 403/404 на этом endpoint после изменения.
Если вы отключали XML-RPC через код, полезно убедиться, что правило действительно подхватилось. Иногда mu-plugin лежит не в той папке, а фильтр просто не срабатывает.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
error_log( 'XML-RPC request blocked' );
}
} );Этот фрагмент не нужен в постоянной эксплуатации, но помогает понять, что запросы действительно доходят до WordPress и фильтр работает. После проверки его лучше убрать.
Частые ошибки и как их исправить
Самая распространённая ошибка — отключить XML-RPC, не проверив зависимости. В результате ломается не «что-то абстрактное», а конкретный рабочий процесс: публикация из приложения, синхронизация с сервисом или часть функций Jetpack. Исправление простое: сначала найти источник запросов, потом закрывать endpoint.
Вторая ошибка — считать, что одного плагина безопасности достаточно. Если плагин просто скрывает endpoint, но не ограничивает частоту запросов и не блокирует подозрительные обращения на сервере, нагрузка и шум в логах останутся. Для сайтов с атакующим трафиком лучше сочетать отключение с серверным ограничением или WAF.
Третья проблема — править тему вместо mu-plugin или серверного конфига. При смене темы правило исчезнет, и XML-RPC снова станет доступен. Для технических ограничений это плохая практика: такие вещи должны жить отдельно от дизайна.
Безопасность и производительность: что ещё имеет смысл проверить
Если вы уже трогаете XML-RPC, стоит заодно посмотреть на соседние точки входа. На практике часто оказываются открытыми лишние REST-эндпоинты, старые формы авторизации, неограниченные попытки входа и тяжёлые плагины, которые создают больше проблем, чем сам XML-RPC.
Для сайтов на типовом стеке полезно проверить:
- ограничение попыток входа;
- наличие актуальных обновлений ядра, тем и плагинов;
- правила кеширования для статических страниц;
- отсутствие лишних публичных endpoints, которые не используются;
- логи 403/401 на подозрительные запросы.
Если вам нужен не только контроль XML-RPC, но и чистка лишних функций WordPress, имеет смысл смотреть в сторону инструментов, которые убирают дубли и упрощают техническую поверхность сайта. Например, Clearfy Pro от WPShop закрывает часть типовых задач по SEO и чистке сайта: https://wpshop.ru/plugins/clearfy.
Когда XML-RPC лучше не отключать полностью
Полный запрет не всегда лучший вариант. Если сайт живёт на интеграциях, где XML-RPC — единственный стабильный канал, лучше оставить его доступным и закрыть только лишние источники. Это особенно актуально для проектов, где публикация идёт из внешних редакторов или где есть старые, но рабочие сценарии синхронизации.
В таких случаях безопаснее зафиксировать список доверенных сервисов, ограничить доступ по IP и регулярно смотреть логи. Так вы не ломаете рабочий процесс и при этом убираете массовый шум от ботов.
Если нужен короткий итог для внедрения: сначала найдите реальные обращения к xmlrpc.php, потом выберите уровень блокировки, после этого проверьте публикацию, интеграции и логи. Именно такой порядок позволяет закрыть дыру без сюрпризов.