XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу по /xmlrpc.php и странным обращениям от старых приложений. На практике задача обычно не в том, чтобы просто «вырубить XML-RPC», а в том, чтобы понять, нужен ли он вообще именно вашему сайту, и отключить его так, чтобы не сломать удалённую публикацию, Jetpack или внешние сервисы.
Если сайт не использует мобильное приложение WordPress, старые интеграции через XML-RPC и пинги от внешних сервисов, этот интерфейс чаще всего можно закрыть. Но делать это лучше после короткой диагностики: иначе можно отключить то, что реально используется редакцией или автоматизацией.
Когда XML-RPC действительно мешает
Сам по себе файл xmlrpc.php не является уязвимостью, но он часто становится точкой входа для перебора паролей и источником лишней нагрузки. Особенно это заметно на сайтах, где в логах много запросов с POST /xmlrpc.php, а в панели безопасности регулярно всплывают попытки авторизации через XML-RPC.
Есть и другой сценарий: сайт работает нормально, но на хостинге растёт число медленных запросов, а в access log видно, что к xmlrpc.php обращаются боты. В таком случае отключение интерфейса даёт не магический прирост скорости, а просто убирает ненужный вектор атак и шум в логах.
Что проверить перед отключением
- Использует ли редакция мобильное приложение WordPress.
- Есть ли Jetpack или другой сервис, который опирается на XML-RPC.
- Настроены ли внешние публикации, пинги или старые интеграции с CMS и скриптами.
- Есть ли в логах реальные обращения к
/xmlrpc.php, а не только сканирование ботами.
Диагностика: нужен ли вам XML-RPC вообще
Самый простой способ — посмотреть логи сервера и понять, кто и зачем стучится в xmlrpc.php. Если у вас есть SSH-доступ, можно быстро отфильтровать обращения по файлу. Пример для Apache/Nginx access log:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Если логов много, полезно посмотреть не только факт обращения, но и статус ответа. Часто видно, что сервер уже отдаёт 403 или 404, а значит, дополнительная блокировка на уровне WordPress может быть избыточной. Если же запросы получают 200 и идут регулярно, интерфейс лучше закрыть осознанно.
В админке тоже можно проверить косвенные признаки: если у вас нет подключённых внешних клиентов, а редакция публикует материалы только через браузер, XML-RPC почти наверняка не нужен. Но если сайт связан с мобильным приложением или автоматизацией, отключать его без теста нельзя.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее контролировать поведение: в коде, на сервере или через плагин. Для большинства сайтов достаточно первого варианта.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Код в functions.php или mu-plugin | Прозрачно, легко откатить | Нужно не забыть про обновления темы | Когда нужен точечный контроль |
| Правило на сервере | Блокирует раньше WordPress | Нужен доступ к конфигу сервера | Когда хотите убрать лишнюю нагрузку до PHP |
| Плагин безопасности | Быстро включить без кода | Лишняя зависимость от плагина | Когда нет доступа к коду или серверу |
Вариант 1: отключить через код
Самый аккуратный способ — добавить фильтр xmlrpc_enabled. Лучше делать это не в теме, а в небольшом mu-plugin, чтобы настройка не пропала при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужно не просто отключить XML-RPC, а ещё и убрать сам доступ к файлу, можно дополнительно закрыть его через init и проверку запроса. Но обычно фильтра достаточно: WordPress перестаёт принимать XML-RPC-методы, а файл остаётся доступным только формально.
Вариант 2: блокировка на уровне сервера
Если цель — отрезать запросы ещё до запуска WordPress, можно закрыть xmlrpc.php в конфиге веб-сервера. Для Nginx это выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Этот вариант полезен, если на сайт идёт много мусорных запросов и вы хотите сэкономить ресурсы. Но если позже понадобится внешний сервис, придётся не забыть вернуть доступ.
Вариант 3: через плагин
Если у вас уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC без дополнительных костылей. Это удобно, когда нужно быстро закрыть проблему на нескольких сайтах. Но для одного проекта я бы всё же предпочёл код или серверное правило: меньше зависимостей, проще аудит.
Пошаговое решение без сюрпризов
- Проверьте, используется ли XML-RPC в реальных сценариях: мобильное приложение, Jetpack, внешняя публикация.
- Сделайте резервную копию конфигурации и кода, если планируете править сервер или mu-plugin.
- Выберите один способ отключения, а не несколько сразу, чтобы не запутаться при отладке.
- Внедрите фильтр
xmlrpc_enabledили правило на сервере. - Очистите кеш, если он есть на уровне плагина, сервера или CDN.
- Проверьте ответ на
/xmlrpc.phpи тестовую публикацию из всех нужных каналов.
Если у вас есть staging-копия, лучше сначала повторить отключение там. Это особенно важно, когда сайт подключён к внешним сервисам, которые не всегда очевидны из админки.
Как проверить, что всё сработало
После отключения не ограничивайтесь открытием главной страницы. Нужно проверить именно тот endpoint, который вы закрывали.
- Откройте
/xmlrpc.phpв браузере: в идеале вы увидите отказ в доступе или пустой ответ без возможности авторизации. - Проверьте логи сервера: запросы к
xmlrpc.phpдолжны получать 403/404, а не 200. - Если использовали фильтр в WordPress, попробуйте отправить тестовый запрос через внешний клиент или старую интеграцию, если она у вас есть.
- Убедитесь, что публикация через обычную админку работает как раньше.
Для быстрой проверки с консоли можно использовать curl:
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает 403 Forbidden или 404 Not Found, это обычно означает, что внешний доступ закрыт. Если ответ 200 OK, но XML-RPC отключён фильтром WordPress, это тоже допустимо, но сам файл остаётся доступным для сканеров.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Jetpack в некоторых сценариях использует XML-RPC для связи с сайтом. Если после отключения пропали статистика, удалённые действия или синхронизация, значит, этот канал был нужен. Решение простое: либо вернуть XML-RPC, либо перенести функциональность на другой способ интеграции, если он доступен.
Поставили блокировку и забыли про кеш
Иногда /xmlrpc.php всё ещё отвечает по старому из-за кеша на уровне CDN или reverse proxy. В таком случае нужно очистить не только WordPress-кеш, но и серверный кеш, а также проверить правила на стороне CDN.
Закрыли файл в .htaccess, но сайт на Nginx
Это типичная ошибка при переносе инструкций между хостингами. .htaccess работает только на Apache и совместимых конфигурациях. На Nginx правило нужно писать в конфиге сервера, иначе оно просто не сработает.
Сделали отключение в теме
Если правило лежит в functions.php активной темы, оно исчезнет после смены темы или обновления, если вы правили не дочернюю тему. Для таких настроек лучше использовать mu-plugin или обычный плагин с минимальным кодом.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC не заменяет базовую защиту входа в админку. Если у вас идут переборы паролей, параллельно проверьте ограничения на wp-login.php, двухфакторную аутентификацию и политику паролей для пользователей с правами редактора и выше.
Если сайт регулярно получает мусорные запросы, полезно смотреть не только на XML-RPC, но и на общую картину: лишние REST-запросы, сканирование /wp-json/, попытки доступа к резервным копиям и старым путям. Иногда правильнее закрывать проблему на уровне WAF или сервера, чем лечить её только внутри WordPress.
Для сайтов, где важна чистота и контроль технических настроек, удобно держать такие правки в отдельном mu-plugin или в плагине оптимизации вроде Clearfy Pro: так проще централизованно управлять отключением лишних функций и не терять настройки при обновлениях темы. Но даже в этом случае лучше понимать, что именно отключается и зачем.
Если коротко: XML-RPC стоит отключать тогда, когда он не нужен, а не просто потому, что это популярный совет. Проверка логов, тест после внедрения и понятный способ отката важнее самого факта блокировки.