XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: лишняя поверхность атаки, брутфорс по xmlrpc.php, ненужные запросы от старых клиентов и сервисов, которые давно можно заменить REST API или прямой интеграцией. Но перед тем как рубить доступ, стоит понять, кто именно использует этот endpoint и не завязан ли на него ваш мобильный клиент, внешняя публикация или старый плагин.
Когда XML-RPC действительно стоит отключать
Если сайт не использует Jetpack в режиме, где нужен XML-RPC, не принимает публикации из сторонних приложений через XML-RPC и не подключён к старым сервисам синхронизации, отключение обычно оправдано. На практике это полезно для сайтов, где админка защищена слабо, а в логах уже видны регулярные обращения к /xmlrpc.php.
При этом не стоит считать XML-RPC «вредным» сам по себе. Он всё ещё нужен некоторым сценариям, например старым мобильным клиентам WordPress, внешним редакторам и отдельным интеграциям. Поэтому сначала проверьте, есть ли зависимость, а потом уже блокируйте endpoint.
Диагностика: как понять, используется ли xmlrpc.php
Самый простой способ — посмотреть логи веб-сервера. Если у вас Nginx или Apache, ищите запросы к /xmlrpc.php. Повторяющиеся POST-запросы с одинаковых IP, особенно с ошибками авторизации, обычно означают перебор паролей или сканирование.
Ещё один практичный тест — открыть URL https://example.com/xmlrpc.php в браузере. Если endpoint доступен, WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не доказывает, что он используется, но подтверждает, что точка входа жива.
Если у вас есть доступ к серверу, можно быстро проверить активность через grep по access-логам:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20На shared-хостинге обычно достаточно панели логов или статистики запросов. Если запросы идут постоянно, а вы не знаете источник, лучше сначала ограничить доступ на уровне сервера, а не только WordPress.
Пошаговое решение без плагинов
Вариант 1: отключить XML-RPC через functions.php или mu-plugin
Самый безопасный для поддержки вариант — не править тему, а добавить небольшой mu-plugin. Так код не потеряется при обновлении темы и будет работать независимо от активного шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
* Description: Disable XML-RPC endpoint in WordPress.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает сам механизм XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, но если сервер продолжает отдавать файл xmlrpc.php, лучше добавить ещё и серверную блокировку.
Вариант 2: заблокировать доступ к xmlrpc.php на уровне сервера
Если вы используете Apache, можно добавить правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx удобнее закрыть endpoint в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверная блокировка полезна тем, что запросы даже не доходят до WordPress. Это снижает нагрузку и убирает лишний шум в логах. Если у вас нет доступа к конфигу веб-сервера, оставьте хотя бы фильтр xmlrpc_enabled.
Вариант 3: точечно ограничить, а не отключать полностью
Иногда XML-RPC нужен только для одного сервиса. Тогда вместо полного отключения можно оставить его включённым и закрыть доступ по IP на уровне сервера или firewall. Это уже инфраструктурная задача, и в WordPress-коде её корректно не решить. Такой подход разумен, если вы точно знаете источник запросов и доверяете ему.
Что проверить после внедрения
После отключения откройте /xmlrpc.php в браузере и проверьте ответ. Если блокировка сделана через WordPress, endpoint не должен работать как раньше. Если блокировка сделана на сервере, вы должны увидеть 403 Forbidden или аналогичный отказ.
Дальше проверьте реальные сценарии, которые могли использовать XML-RPC:
- публикация из внешнего клиента WordPress;
- подключение Jetpack, если он у вас используется;
- автоматизированные сервисы, которые отправляют посты через XML-RPC;
- старые интеграции, о которых могли забыть.
Если после отключения что-то перестало работать, это хороший сигнал: значит, зависимость была, и её нужно заменить осознанно, а не держать XML-RPC открытым «на всякий случай».
Сравнение подходов: код, сервер, плагин
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | Отключает XML-RPC внутри WordPress | Быстро, без лишних зависимостей | Файл всё ещё доступен на уровне веб-сервера |
| Блокировка в Nginx/Apache | Отсекает запросы до PHP | Лучше для безопасности и нагрузки | Нужен доступ к конфигу сервера |
| Плагин безопасности | Отключает или ограничивает endpoint | Удобно для админов без доступа к серверу | Лишняя зависимость, возможны конфликты |
Если вы ведёте несколько сайтов, обычно удобнее держать отключение в mu-plugin и дублировать блокировку на сервере там, где есть доступ. Для одиночного сайта на shared-хостинге часто хватает фильтра и проверки логов.
Частые ошибки и как их исправить
Отключили XML-RPC, но запросы всё равно идут
Это нормально, если вы закрыли только WordPress-уровень. Веб-сервер всё ещё принимает запросы и передаёт их в PHP. Чтобы убрать это полностью, добавьте правило в Nginx или Apache.
Сломался Jetpack или внешний клиент
Значит, сервис действительно использовал XML-RPC. В этом случае не стоит просто возвращать всё назад. Сначала проверьте, можно ли перевести интеграцию на REST API, OAuth или штатный плагин-сценарий без XML-RPC.
Правило в .htaccess не сработало
Чаще всего проблема в том, что правило вставили не в тот блок, а на сервере Apache не включена обработка Require в нужном контексте. Проверьте, что сайт действительно работает под Apache, а не под Nginx с проксированием, где .htaccess вообще не влияет на запрос.
Сделали отключение в теме и потеряли его после обновления
Это типичная ошибка. Не вносите такие правки в functions.php активной темы, если не уверены, что тема не будет меняться. Для системных ограничений лучше использовать mu-plugin.
Практические советы по безопасности и производительности
Если цель — защита от перебора паролей, одного отключения XML-RPC может быть мало. Проверьте ещё:
- ограничение попыток входа в админку;
- двухфакторную аутентификацию для администраторов;
- актуальность ядра, темы и плагинов;
- наличие WAF или правил на уровне хостинга.
Если на сайте много технических дублей, мусорных страниц и лишних точек входа, имеет смысл посмотреть и на общую чистку сайта. В таких задачах иногда помогает связка с инструментами вроде Clearfy Pro, но только если вам нужен именно набор точечных оптимизаций, а не очередной «комбайн» ради галочки.
Для производительности важен не сам факт отключения XML-RPC, а то, что вы убираете лишние POST-запросы и потенциальные попытки брутфорса. На нагруженных сайтах это заметно в логах и в количестве бесполезных обращений к PHP.
Как быстро убедиться, что решение сработало
- Откройте
/xmlrpc.phpи проверьте, что он не отвечает как раньше. - Посмотрите access-log: новых успешных обращений быть не должно.
- Проверьте, не сломались ли внешние клиенты и интеграции.
- Убедитесь, что отключение переживает обновление темы.
- Если есть серверная блокировка, проверьте код ответа 403 или аналогичный отказ.
Если после всех проверок XML-RPC больше не нужен, оставьте блокировку на уровне сервера и зафиксируйте её в документации проекта. Это тот случай, когда простое и явное решение обычно лучше, чем попытка «мягко ограничить» старый механизм без понимания, кто его ещё дергает.