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