Файл xmlrpc.php в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу и странным обращениям в логах. При этом отключать его вслепую тоже не стоит: у части сайтов через XML-RPC до сих пор работают публикации из мобильных приложений, внешние клиенты и старые интеграции.
Ниже — практический разбор: как понять, нужен ли вам xmlrpc.php, как отключить его безопасно и чем проверить, что вы ничего не сломали.
Когда xmlrpc.php действительно мешает
Сам по себе файл не является уязвимостью, но он расширяет поверхность атаки. Чаще всего его трогают по трём причинам:
- в логах много запросов к
/xmlrpc.phpс попытками подбора паролей; - на хостинге растёт число подозрительных POST-запросов;
- сайт не использует старые интеграции, которым XML-RPC вообще не нужен.
Если у вас обычный сайт на WordPress без публикации через сторонние клиенты, без Jetpack-частей, завязанных на XML-RPC, и без старых мобильных приложений, отключение обычно оправдано. Но сначала проверьте зависимости.
Что может сломаться после отключения
Чаще всего страдают:
- публикация и редактирование через старые мобильные приложения WordPress;
- некоторые внешние сервисы синхронизации и автопостинга;
- интеграции, которые используют XML-RPC вместо REST API;
- старые плагины для удалённой работы с сайтом.
Если вы не уверены, откройте настройки подключённых сервисов и посмотрите, какой протокол они используют. Если в документации есть REST API — это хороший знак: отключение xmlrpc.php не должно мешать.
Диагностика: нужен ли вам xmlrpc.php
Перед изменениями проверьте, кто и как обращается к файлу. Это можно сделать по логам веб-сервера или по журналу безопасности, если он есть в панели хостинга.
Признаки, что XML-RPC можно отключать безболезненно:
- в логах нет легитимных запросов от ваших сервисов;
- вы не используете публикацию по email через старые схемы, завязанные на XML-RPC;
- внешние интеграции работают через REST API или прямой доступ к базе/очередям;
- админка и мобильные приложения WordPress вам не нужны.
Если у вас есть сомнения, временно ограничьте доступ к файлу только для проверки, а не удаляйте его сразу. Так проще откатиться.
Как отключить xmlrpc.php: рабочие варианты
Есть три нормальных подхода: через плагин безопасности, через код и на уровне веб-сервера. Выбор зависит от того, кто управляет сайтом и где вам удобнее держать правило.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правок темы | Ещё один слой логики в админке | Если нужен простой откат и нет доступа к серверу |
| Код в теме/плагине | Контроль в репозитории, прозрачно для разработчика | Нужно не забыть про обновления и место вставки | Если есть свой mu-plugin или кастомный плагин |
| Веб-сервер | Отсекает запросы до WordPress | Нужен доступ к конфигу nginx/apache | Если хотите снизить нагрузку и закрыть файл на уровне сервера |
Вариант 1: отключить через код
Самый понятный способ — вернуть 403 на запросы к xmlrpc.php. Лучше класть такой код не в functions.php темы, а в небольшой mu-plugin или отдельный плагин для сайта.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот фильтр отключает XML-RPC на уровне WordPress. Для большинства сценариев этого достаточно. Но если вы хотите отсечь обращения ещё раньше, добавьте правило на сервере.
Вариант 2: закрыть файл на уровне nginx
Если сайт работает на nginx, можно вернуть 403 для /xmlrpc.php до передачи запроса в PHP. Это полезно, когда файл постоянно атакуют и вы хотите убрать лишнюю нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
После правки конфигурации проверьте синтаксис и перезагрузите nginx. Не вносите это правило в блок, который уже обрабатывается другими location-правилами, иначе можно получить неожиданный приоритет.
Вариант 3: закрыть через Apache
Если у вас Apache, используйте .htaccess или конфиг виртуального хоста. Для .htaccess подойдёт такой вариант:
<Files xmlrpc.php>
Require all denied
</Files>
Это простой и прозрачный способ. Но если у вас сложная схема с проксированием или кэшированием, проверьте, что правило действительно применяется к нужному виртуальному хосту.
Пошаговое решение без сюрпризов
- Проверьте, есть ли легитимные обращения к
xmlrpc.phpв логах за последние дни. - Сверьте подключённые сервисы: мобильные клиенты, автопостинг, внешние редакторы, старые интеграции.
- Выберите способ отключения: код, сервер или плагин.
- Внесите правило в отдельный слой, а не в случайную правку темы.
- Очистите кэш страницы и серверный кэш, если он есть.
- Протестируйте доступ к
/xmlrpc.phpи работу нужных интеграций.
Если у сайта есть staging-копия, сначала проверьте всё там. Для таких изменений это не формальность: иногда внешний сервис «молчит» до следующей синхронизации, и проблема всплывает уже на боевом сайте.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере или выполните запрос через curl. В норме вы должны увидеть отказ в доступе или ответ WordPress о том, что XML-RPC отключён.
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали доступ через nginx или Apache, код ответа должен быть не 200. Если использовали фильтр WordPress, убедитесь, что файл не отвечает как рабочий endpoint.
Дополнительно проверьте:
- в логах больше нет успешных обращений к
xmlrpc.php; - внешние сервисы продолжают публиковать или синхронизировать данные;
- админка WordPress работает без ошибок;
- REST API не затронут:
/wp-json/должен отвечать как раньше.
Частые ошибки и как их исправить
Отключили XML-RPC в теме
Если правило лежит в functions.php активной темы, оно исчезнет после смены темы. Для системной настройки это плохое место. Перенесите код в mu-plugin или отдельный плагин.
Заблокировали не тот endpoint
Иногда путают xmlrpc.php и REST API. Это разные механизмы. Если после правки перестали работать мобильные приложения или интеграции, проверьте, не задели ли вы /wp-json/ или правила безопасности плагина целиком.
Сломали внешний сервис, который не был задокументирован
Такое бывает, если сайт давно живёт и к нему подключали сервисы без нормальной документации. В этом случае временно верните доступ, найдите источник запросов по логам и уже потом отключайте точечно.
Поставили плагин, который блокирует лишнее
Некоторые security-плагины умеют отключать XML-RPC вместе с другими функциями. Это удобно, но после обновления настроек можно случайно потерять ещё и полезные возможности. Если нужен предсказуемый контроль, лучше использовать точечное правило.
Безопасность и производительность: что учесть дополнительно
Отключение xmlrpc.php не заменяет базовую защиту. Если сайт регулярно атакуют, проверьте ещё и:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, тем и плагинов;
- наличие WAF или правил на уровне хостинга;
- отдельные права на
wp-adminиwp-login.php.
Если вам нужен более широкий набор технической чистки сайта, иногда удобнее собрать это в одном инструменте. Например, Clearfy Pro закрывает часть типовых задач по SEO и технической оптимизации, но даже в этом случае правило для XML-RPC лучше проверять отдельно, а не полагаться на «магическую» галочку.
Главная идея простая: отключайте xmlrpc.php только после проверки зависимостей и только так, чтобы правило было легко найти и откатить. Тогда вы уберёте лишний шум и не потеряете нужные интеграции.