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