XML-RPC в WordPress до сих пор нужен не всем. Если вы не пользуетесь мобильным приложением WordPress, внешними редакторами, Jetpack или старыми интеграциями, этот интерфейс часто только расширяет поверхность атаки и добавляет лишние запросы. На практике задача обычно звучит просто: закрыть /xmlrpc.php, но не сломать сайт и не получить ложное ощущение безопасности.
Ниже — рабочие способы отключения, как проверить результат и где чаще всего ошибаются.
Когда XML-RPC действительно стоит отключить
Отключение имеет смысл, если сайт работает как обычный контентный проект и вы не используете внешние клиенты для публикации. Для большинства админок и редакторов в браузере XML-RPC не нужен вообще.
Типичные сценарии
- сайт не подключен к Jetpack или другим сервисам, которые используют XML-RPC;
- публикация и редактирование идут только через wp-admin;
- в логах видно много обращений к
xmlrpc.phpс ошибками авторизации; - нужно уменьшить риск brute force и pingback-атак.
Если у вас есть внешняя интеграция, сначала проверьте, использует ли она XML-RPC. Иногда это старый мобильный клиент, синхронизация с сервисом заметок или сторонний плагин, который давно не обновлялся.
Диагностика: как понять, используется ли XML-RPC сейчас
Самый практичный способ — посмотреть логи веб-сервера и проверить, есть ли реальные обращения к файлу xmlrpc.php. Если запросы идут только от ботов и сканеров, отключение обычно безопасно. Если есть обращения от ваших устройств или сервисов, сначала меняйте схему работы.
Что проверить перед изменением
- есть ли в логах запросы к
/xmlrpc.phpот ваших IP; - используется ли Jetpack;
- есть ли мобильное приложение WordPress в рабочем процессе;
- есть ли интеграции, которые отправляют записи через XML-RPC;
- не закрыт ли уже доступ на уровне хостинга или CDN.
Если у вас включен кэш или WAF, не путайте блокировку на уровне приложения с блокировкой на уровне сервера. Иногда файл формально доступен, но часть запросов режется раньше, чем доходит до WordPress.
Пошаговое решение без плагинов
Есть два нормальных пути: закрыть доступ на уровне сервера или отключить обработку в WordPress. Лучше использовать серверный вариант, если вы контролируете конфигурацию. Если доступа к конфигу нет, подойдет фильтр в теме или mu-plugin.
Вариант 1: блокировка на уровне сервера
Для Apache можно добавить правило в .htaccess. Оно не зависит от темы и срабатывает раньше WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Если сервер старый и использует Apache 2.2, встречается вариант с Deny from all, но на современных установках лучше использовать Require all denied.
Для Nginx правило добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации нужно перезагрузить веб-сервер и проверить, что файл больше не отвечает снаружи.
Вариант 2: отключение через WordPress
Если серверную конфигурацию трогать нельзя, можно отключить XML-RPC через код. Самый аккуратный способ — добавить небольшой mu-plugin, чтобы решение не зависело от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. Такой подход удобен тем, что код не исчезнет после смены темы и не потеряется при обновлении.
Если нужно не полностью отключать XML-RPC, а только убрать опасные методы, можно фильтровать список методов. Это уже более тонкая настройка, но для большинства сайтов проще и надежнее закрыть интерфейс целиком.
Сравнение подходов: сервер, код, плагин
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Apache/Nginx | Закрывает доступ раньше WordPress, меньше нагрузки | Нужен доступ к конфигу | Есть доступ к серверу |
| mu-plugin | Не зависит от темы, легко откатить | WordPress все равно загружается | Нет доступа к серверу |
| Обычный плагин | Просто включить и выключить | Лишняя зависимость, риск забыть после миграции | Только если нужен временный тест |
Если задача именно в безопасности и снижении лишних запросов, серверный вариант обычно предпочтительнее. Если нужен быстрый и переносимый способ — mu-plugin.
Как проверить, что XML-RPC действительно отключен
Проверка нужна обязательно. Иначе можно закрыть код в WordPress, но оставить доступ на сервере, или наоборот — заблокировать только часть запросов.
Проверка через браузер и curl
Откройте https://example.com/xmlrpc.php. Если блокировка сделана на сервере, вы увидите отказ в доступе или пустой ответ без стандартного сообщения WordPress. Если отключение сделано через фильтр xmlrpc_enabled, WordPress обычно вернет сообщение о том, что XML-RPC отключен.
Через curl удобно проверить код ответа:
curl -I https://example.com/xmlrpc.phpЕсли вы видите 403, блокировка работает на уровне сервера. Если приходит 200 или ответ WordPress с текстом об отключении, значит файл доступен, но обработка выключена на уровне приложения.
Проверка логов
После внедрения посмотрите access log. Запросы к xmlrpc.php могут продолжать появляться, но они должны завершаться отказом в доступе. Это нормально: важно не отсутствие попыток, а отсутствие успешной обработки.
Частые ошибки и как их исправить
- Отключили XML-RPC в теме. При смене темы защита исчезнет. Перенесите код в mu-plugin или на сервер.
- Заблокировали файл, но забыли про Jetpack. Если сервис нужен, он перестанет синхронизироваться. Сначала проверьте зависимости.
- Сделали правило в .htaccess, но сайт на Nginx. Для Nginx этот файл не работает. Нужна правка конфигурации сервера.
- Проверили только главную страницу. Это не доказывает, что
xmlrpc.phpзакрыт. Проверяйте именно этот URL. - Использовали плагин и не удалили его после теста. Лишний плагин — лишняя точка отказа и обновления.
Практические советы по безопасности и производительности
Если вы отключаете XML-RPC ради защиты, не ограничивайтесь только этим файлом. Проверьте, не открыты ли лишние сервисные точки входа: слабые пароли, устаревшие плагины, доступ к wp-login.php без ограничений по попыткам, публичные архивы, которые не нужны для индексации.
Для сайтов с высокой посещаемостью полезно закрывать xmlrpc.php на уровне сервера: так вы не тратите ресурсы PHP на заведомо ненужные запросы. Если у вас уже настроен WAF или CDN, убедитесь, что правило не конфликтует с их политиками и не ломает легитимные интеграции.
Если нужен более широкий аудит технических дублей и служебных страниц, можно посмотреть в сторону инструментов вроде Clearfy Pro, но для самой задачи отключения XML-RPC отдельный плагин не обязателен.
Что должно получиться после внедрения
После настройки /xmlrpc.php не должен принимать обычные запросы извне, а в логах должны остаться только попытки обращения с отказом. Если вы используете внешние сервисы, они либо продолжат работать без XML-RPC, либо сразу покажут ошибку подключения — это сигнал проверить зависимости до продакшена.
Самый надежный сценарий: блокировка на сервере плюс короткая проверка через curl и логи. Тогда вы точно знаете, что доступ закрыт не только визуально, но и технически.