XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки и шум в логах. Но отключать его вслепую тоже не стоит: у части сайтов через него работают Jetpack, старые мобильные клиенты, внешние публикации и некоторые сервисы автопостинга. Поэтому задача не в том, чтобы просто закрыть файл xmlrpc.php, а в том, чтобы понять, нужен ли он вообще, и если нет — отключить его без побочных эффектов.
Когда XML-RPC реально мешает
Если сайт не использует внешнюю публикацию через старые клиенты, а в админке никто не работает через приложения WordPress для iOS/Android, XML-RPC обычно не нужен. На практике его отключают по трём причинам: уменьшить риск брутфорса, убрать лишние запросы к серверу и закрыть точку входа, которая часто фигурирует в логах безопасности.
Но есть и обратная сторона. Некоторые плагины и сервисы всё ещё обращаются к XML-RPC, особенно если сайт давно живёт и пережил несколько смен стека. Поэтому сначала стоит проверить фактическое использование, а уже потом резать доступ.
Диагностика: используется ли xmlrpc.php сейчас
Начните с логов веб-сервера и плагина безопасности, если он уже стоит. Ищите обращения к /xmlrpc.php, особенно массовые POST-запросы с одинаковыми IP и повторяющимися методами вроде system.multicall. Это типичный признак перебора учётных данных.
Если у вас есть доступ к серверу, можно быстро посмотреть статистику по запросам. Пример для Nginx-логов:
grep 'xmlrpc.php' /var/log/nginx/access.log | tail -n 50Если сайт на Apache, путь к логам будет другим, но смысл тот же: нужно понять, есть ли легитимные обращения или только шум.
Проверка со стороны WordPress
Ещё один практичный способ — временно включить логирование запросов в плагине безопасности или проверить, не завязаны ли на XML-RPC внешние сервисы. Если у вас установлен Jetpack, проверьте его соединение после отключения. Если используются мобильные приложения WordPress, убедитесь, что редакторы действительно не работают через XML-RPC.
Если сомневаетесь, не отключайте файл физически на первом шаге. Сначала ограничьте доступ программно или через серверную конфигурацию, чтобы можно было быстро откатиться.
Как отключить XML-RPC в WordPress: рабочие варианты
Есть три нормальных подхода: через код, через сервер и через плагин. Выбор зависит от того, где вам удобнее управлять доступом и нужен ли быстрый откат.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в functions.php или mu-plugin | Нужен точечный контроль внутри WordPress | Не защищает до загрузки WordPress |
| Правило на уровне Nginx/Apache | Нужно закрыть доступ раньше, чем загрузится PHP | Требует доступа к конфигу сервера |
| Плагин безопасности | Нужен быстрый способ без правок кода | Добавляет зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Если вам нужен простой и понятный контроль, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, если нет внешних интеграций, которые завязаны именно на этот механизм.
Вариант 2: закрыть xmlrpc.php на сервере
Если задача — не просто отключить функциональность, а убрать сам доступ к файлу, лучше сделать это на уровне веб-сервера. Для Nginx можно вернуть 403 на запросы к xmlrpc.php:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный вариант полезен тем, что блокирует запрос ещё до запуска WordPress. Это снижает нагрузку и убирает лишние обращения из логов PHP.
Вариант 3: отключить через плагин безопасности
Если у вас уже стоит плагин, который умеет управлять XML-RPC, можно использовать его настройку. Это удобно для администраторов без доступа к серверу, но важно понимать, что плагин должен быть надёжным и не конфликтовать с другими правилами безопасности. Если нужен более широкий набор технических чисток и SEO-правок, иногда удобнее собрать это в одном инструменте вроде Clearfy Pro, но только если он уже вписывается в ваш стек и не дублирует функции других плагинов.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что XML-RPC не используется легитимно.
- Сделайте резервную копию конфигурации или хотя бы сохраните текущие правила.
- Выберите способ отключения: код, сервер или плагин.
- Примените изменение сначала на staging-сайте, если он есть.
- Проверьте, не сломались ли Jetpack, мобильные приложения и внешние публикации.
- После проверки перенесите изменение на боевой сайт.
Если у вас несколько администраторов, предупредите их заранее. Часто проблема всплывает не сразу, а когда кто-то пытается опубликовать запись через старый клиент и получает неочевидную ошибку.
Как проверить, что XML-RPC действительно отключён
После внедрения не ограничивайтесь «вроде работает». Проверьте конкретно:
- открывается ли
/xmlrpc.phpв браузере или черезcurl; - возвращает ли сервер
403или другой отказ; - не появились ли ошибки в логах WordPress и веб-сервера;
- работают ли интеграции, которые вы считали важными;
- не выросло ли число ошибок авторизации в сторонних сервисах.
Простой тест через командную строку:
curl -I https://example.com/xmlrpc.phpЕсли всё закрыто правильно, вы увидите отказ доступа или другой ответ, который не позволяет использовать endpoint по назначению. Если же приходит обычный ответ WordPress, значит блокировка не сработала или была сделана только частично.
Частые ошибки и как их исправить
Отключили XML-RPC в WordPress, но файл всё ещё доступен
Это нормальная ситуация для варианта с фильтром xmlrpc_enabled: WordPress перестаёт обслуживать запросы, но сам файл остаётся доступным на уровне веб-сервера. Если вам нужен жёсткий запрет, добавьте правило в Nginx, Apache или на уровне WAF.
Сломался Jetpack
Jetpack может использовать XML-RPC для части сценариев подключения и синхронизации. Если после отключения плагин начал ругаться, проверьте, действительно ли он нужен в текущей конфигурации. Иногда достаточно оставить доступ только для конкретных сценариев, но чаще проще пересмотреть саму необходимость Jetpack.
Сайт стал отдавать 500 после правки .htaccess
Обычно причина в синтаксисе или в том, что правило вставили не в тот блок. Верните резервную копию .htaccess, проверьте директивы и добавляйте правило аккуратно, без лишних символов и вложенности.
Отключили XML-RPC, но атаки в логах не исчезли
Это не означает, что защита бесполезна. Просто сканеры продолжают стучаться в endpoint, не зная, что он закрыт. Важен не сам факт запросов, а то, что они больше не доходят до рабочей логики WordPress и не расходуют ресурсы PHP.
Безопасность и производительность: что ещё стоит сделать рядом
Если вы уже чистите поверхность атаки, имеет смысл проверить и другие технические точки. Уберите неиспользуемые плагины, проверьте актуальность ядра и тем, ограничьте доступ к админке по IP там, где это уместно, и следите за логами авторизации. XML-RPC редко бывает единственной проблемой, он обычно просто самый заметный вход.
Для сайтов с высокой нагрузкой серверная блокировка предпочтительнее, чем только PHP-фильтр: меньше лишних обращений, меньше работы для интерпретатора, меньше мусора в логах. Если у вас много технических правок по SEO и чистке сайта, удобнее держать их в одном регламенте, а не разбрасывать по разным плагинам и сниппетам.
Когда XML-RPC лучше не отключать
Если вы точно знаете, что через него работают нужные интеграции, не рубите доступ без плана миграции. Сначала проверьте, можно ли перевести сервис на REST API или другой способ авторизации. Только после этого закрывайте XML-RPC и наблюдайте за логами и поведением интеграций несколько дней.
В практическом смысле правильный сценарий выглядит так: сначала диагностика, потом точечное отключение, затем проверка и только после этого окончательная фиксация правила. Так вы не получите ситуацию, когда защита включена, а публикация контента или синхронизация с внешним сервисом внезапно перестала работать.