XML-RPC в WordPress до сих пор часто остаётся включённым по умолчанию, хотя на большинстве сайтов он не нужен. Если вы не используете старые мобильные клиенты, внешние сервисы публикации или интеграции, завязанные именно на XML-RPC, этот интерфейс только расширяет поверхность атаки. На практике чаще всего его отключают не «на всякий случай», а после конкретных симптомов: перебор логинов, подозрительные запросы к xmlrpc.php, лишняя нагрузка на сервер.
Ниже — рабочие способы отключить XML-RPC без выдуманных плагинов и без лишней магии. Сначала разберём, как понять, что он действительно нужен или не нужен, потом покажу два безопасных варианта блокировки: через PHP и через .htaccess. В конце — как проверить результат и что ломается чаще всего.
Когда XML-RPC лучше отключить
Сам по себе файл xmlrpc.php не является уязвимостью, но он часто используется для атак на подбор паролей и для запросов, которые создают лишнюю нагрузку. Если у вас обычный сайт на WordPress без внешних клиентов публикации, отключение обычно не мешает работе.
Сначала проверьте, используется ли он вообще
Перед блокировкой посмотрите на реальные сценарии:
- публикуете ли вы записи через внешние приложения;
- используете ли Jetpack или похожие сервисы, которым нужен XML-RPC;
- есть ли интеграции, которые отправляют посты по XML-RPC;
- не завязаны ли на него старые мобильные приложения или десктопные клиенты.
Если ничего из этого нет, отключение обычно безопасно. Если есть сомнения, сначала проверьте логи сервера: частые обращения к /xmlrpc.php без понятной причины — хороший повод закрыть доступ.
Диагностика: как понять, что запросы идут именно через XML-RPC
Самый простой способ — посмотреть access log веб-сервера. Ищите обращения к xmlrpc.php и частые POST-запросы. Для Nginx это может выглядеть так:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Если у вас Apache, путь к логам может отличаться, но принцип тот же. Важно не просто увидеть один запрос, а понять, есть ли регулярная активность. Один-два обращения от вашего же сервиса — не проблема. Постоянный поток запросов с разных IP — уже сигнал.
Ещё один практический тест — открыть https://example.com/xmlrpc.php в браузере. Если интерфейс доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказательство атаки, но подтверждение, что endpoint открыт.
Способ 1: отключить XML-RPC через PHP
Это самый предсказуемый вариант, если вы контролируете тему или используете mu-plugin. Он не зависит от настроек веб-сервера и работает на уровне WordPress.
Куда добавить код
Лучше не править functions.php активной темы, если есть риск потерять изменения при обновлении. Надёжнее добавить небольшой mu-plugin в wp-content/mu-plugins/. Если mu-plugins у вас ещё нет, создайте папку и файл, например disable-xmlrpc.php.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр штатный и возвращает false для XML-RPC. Для большинства сайтов этого достаточно.
Если нужно не просто отключить, а вернуть 403
Иногда полезно не только выключить обработку, но и явно закрыть сам файл. Тогда можно добавить проверку на раннем этапе:
<?php
/**
* Plugin Name: Block XML-RPC Requests
*/
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Этот вариант полезен, если вы хотите, чтобы запрос не доходил до обычной логики WordPress. Но в большинстве случаев фильтра xmlrpc_enabled достаточно и он чище.
Способ 2: закрыть xmlrpc.php через .htaccess
Если сайт работает на Apache или LiteSpeed с поддержкой .htaccess, можно заблокировать доступ на уровне веб-сервера. Это особенно полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache 2.2 может встречаться синтаксис:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Если у вас Nginx, .htaccess не поможет. Там блокировку нужно делать в конфиге сервера, например так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот вариант особенно хорош, если на сайт идёт много мусорных запросов и вы хотите снизить нагрузку до уровня веб-сервера.
Что выбрать: PHP, .htaccess или серверный конфиг
| Способ | Где работает | Плюс | Минус |
|---|---|---|---|
Фильтр xmlrpc_enabled | WordPress | Просто внедрить, легко откатить | WordPress всё равно стартует |
.htaccess | Apache/LiteSpeed | Блокирует до загрузки WP | Не подходит для Nginx |
| Конфиг Nginx | Nginx | Самый ранний отказ, меньше нагрузки | Нужен доступ к конфигу сервера |
Если у вас есть доступ к конфигу веб-сервера, лучше блокировать на его уровне. Если доступа нет, используйте PHP-способ через mu-plugin.
Проверка результата после внедрения
После изменения не ограничивайтесь визуальной проверкой. Нужно убедиться, что endpoint действительно закрыт и сайт не потерял нужные функции.
- Откройте
/xmlrpc.phpв браузере — должен быть отказ в доступе или пустой ответ без стандартного сообщения WordPress. - Проверьте POST-запросом через
curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли блокировка настроена правильно, вы увидите 403 Forbidden или другой отказ, а не обычный ответ XML-RPC.
- Проверьте, не сломались ли внешние интеграции, если они у вас есть.
- Посмотрите логи веб-сервера: количество обращений к
xmlrpc.phpдолжно либо исчезнуть, либо резко снизиться.
Частые ошибки и как их исправить
Отключили XML-RPC, а атаки всё равно идут
Это нормально, если блокировка сделана только на уровне WordPress. Запросы могут продолжать приходить, но WordPress будет их отвергать. Если хотите уменьшить нагрузку сильнее, переносите блокировку в Nginx или Apache.
Сломался Jetpack или внешняя публикация
Значит, XML-RPC действительно использовался. В таком случае не отключайте его полностью, а ограничьте доступ по IP или пересмотрите саму интеграцию. Полное закрытие без проверки сценариев часто приводит к неожиданным сбоям.
Добавили код в тему и потеряли его после обновления
Это типичная ошибка. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин. Так код не исчезнет при обновлении темы.
В .htaccess правило не сработало
Чаще всего причина в том, что сайт работает не на Apache, а на Nginx, либо правило вставлено не в тот блок. Для Nginx нужен конфиг сервера, а не .htaccess.
Практические советы по безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа. Если у вас уже есть перебор паролей, добавьте ограничение попыток входа, двухфакторную аутентификацию и актуальные обновления ядра, тем и плагинов. Если на сайте много мусорного трафика, блокировка XML-RPC даст небольшой, но полезный выигрыш по нагрузке, особенно на слабых хостингах.
Если вы управляете несколькими сайтами, удобно вынести такие ограничения в отдельный mu-plugin и хранить его как часть базовой конфигурации. Тогда вы не будете искать, где именно был отключён XML-RPC, через полгода после внедрения.
Для сайтов, где нужны дополнительные меры по чистке технических дублей, индексации и базовой SEO-гигиене, иногда удобнее собрать это в одном наборе настроек, чем держать разрозненные куски кода. Но даже в этом случае проверяйте каждое изменение отдельно: отключение XML-RPC не должно быть «побочным эффектом» другого плагина или темы.