XML-RPC в WordPress до сих пор встречается на живых сайтах, хотя для большинства проектов он давно не нужен. Проблема в том, что его часто отключают «в лоб» через .htaccess или плагин безопасности, а потом внезапно перестают работать Jetpack, внешние публикации, старые мобильные клиенты или интеграции, которые до сих пор ходят через xmlrpc.php.
Если задача не в том, чтобы просто «закрыть всё подряд», а в том, чтобы убрать лишнюю поверхность атаки без побочных эффектов, лучше сначала понять, кто именно обращается к XML-RPC, и только потом выбирать способ блокировки.
Когда XML-RPC можно отключать, а когда нет
XML-RPC нужен не всем. На большинстве сайтов он используется редко или вообще не используется. Но есть сценарии, где его отключение ломает рабочий процесс:
- Jetpack подключается к сайту и использует XML-RPC для части функций;
- публикация из внешних клиентов и приложений, которые не перешли на REST API;
- старые интеграции с CRM, редакторами или сервисами автопостинга;
- мобильные приложения и сторонние инструменты, завязанные на классический WordPress API.
Если у вас обычный корпоративный сайт, блог или лендинг без внешней публикации, XML-RPC чаще всего можно отключить. Если сайт связан с Jetpack или старой интеграцией, сначала проверьте, что именно использует этот канал.
Диагностика проблемы: кто обращается к xmlrpc.php
Самая частая ошибка — отключить XML-RPC до проверки логов. В результате вы получаете не «усиление безопасности», а сломанный функционал, который потом ищут по симптомам. Начните с простого: посмотрите обращения к /xmlrpc.php в логах веб-сервера или в логах безопасности, если они уже собираются.
Что искать в логах
В access-логах обычно видно частые POST-запросы к xmlrpc.php. Если это регулярные обращения с одного и того же IP или от известных сервисов, у вас уже есть зацепка. Если запросов нет, отключение пройдет безболезненно, но это лучше подтвердить тестом после внедрения.
Полезно также проверить, не используется ли Jetpack. Если плагин подключен и активен, не стоит блокировать XML-RPC без отдельной проверки его функций. Jetpack не всегда зависит от него целиком, но на практике проблемы после грубой блокировки встречаются.
Быстрая проверка с curl
Можно вручную проверить, отвечает ли endpoint. Это не заменяет анализ логов, но помогает понять, открыт ли он вообще:
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает 405 Method Not Allowed, 403 Forbidden или отдает страницу с сообщением об ошибке, это уже сигнал, что endpoint не пустой. Но сам по себе ответ еще не говорит, нужен он вам или нет.
Как отключить XML-RPC безопасно
Есть три рабочих подхода: через код, через серверную конфигурацию и через плагин безопасности. Для продакшена я обычно выбираю код или серверную блокировку, если нужно именно исключить доступ. Плагин удобен, когда сайт ведется без доступа к конфигам, но это дополнительная зависимость.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль, легко откатить, не зависит от внешнего плагина | Нужно не забыть, где лежит код |
| .htaccess / nginx | Блокирует на уровне веб-сервера | Нужен доступ к конфигу, можно ошибиться в правилах |
| Плагин безопасности | Быстро включить без кода | Лишняя зависимость, иногда блокирует лишнее |
Вариант 1: отключить через код
Если вы хотите просто запретить использование XML-RPC в WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так код не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC на уровне WordPress. Если кто-то попробует обратиться к xmlrpc.php, он не получит рабочий API-ответ. Для большинства сайтов этого достаточно.
Вариант 2: закрыть доступ на уровне сервера
Если нужно именно отрезать запросы до WordPress, можно добавить правило в веб-сервер. Для Apache это обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>На nginx логика будет другой, но смысл тот же: не отдавать xmlrpc.php наружу. Этот способ жестче, и его стоит использовать только если вы уверены, что сайт не зависит от XML-RPC.
Вариант 3: блокировка через плагин
Если у вас уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC без побочных эффектов. Это удобно для типовых сайтов, но важно понимать, что плагин может закрыть не только XML-RPC, но и другие функции, если включить агрессивные настройки без проверки.
Если нужен более широкий набор технических чисток, иногда удобнее использовать инструменты вроде Clearfy Pro, но и там нужно отдельно проверять, что именно включено, а что нет. Автоматическая «оптимизация» без ревизии настроек часто приносит больше проблем, чем пользы.
Пошаговое решение без лишнего риска
- Проверьте, используется ли Jetpack и какие внешние интеграции подключены к сайту.
- Посмотрите access-логи на обращения к
xmlrpc.php. - Если запросов нет и интеграции не нужны, выберите способ отключения: код или сервер.
- Внесите изменение сначала на staging, если он есть.
- Проверьте главную, админку, отправку форм, публикацию записей и работу подключенных сервисов.
- Только после этого переносите изменение на продакшен.
Если сайт обслуживает несколько редакторов или внешние сервисы, лучше заранее зафиксировать, кто и как публикует контент. Иначе XML-RPC могут отключить «по безопасности», а потом искать причину, почему перестал работать старый редактор или автопостинг.
Как проверить, что отключение сработало
После внедрения нужно проверить не только то, что endpoint перестал отвечать, но и то, что сайт не потерял нужные функции.
Проверка endpoint
Самый простой тест:
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки: 403, 404 или сообщение об ошибке без рабочего XML-RPC. Если вы отключали через фильтр xmlrpc_enabled, можно дополнительно попробовать отправить тестовый запрос через клиент, который раньше работал с этим endpoint.
Проверка побочных эффектов
- откройте Jetpack и убедитесь, что он не потерял связь с сайтом;
- проверьте публикацию и обновление записей из админки;
- если есть внешняя интеграция, выполните тестовую отправку;
- посмотрите error_log и логи веб-сервера на 4xx/5xx после изменения.
Если после отключения появились ошибки авторизации или синхронизации, значит, какой-то сервис все еще завязан на XML-RPC. В этом случае не нужно «дожимать» блокировку — сначала найдите конкретную интеграцию.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Причина обычно в том, что Jetpack был подключен раньше, чем провели ревизию зависимостей. Решение простое: либо вернуть XML-RPC, либо перевести нужные функции Jetpack на другой режим, если это возможно в вашем сценарии.
Заблокировали xmlrpc.php на сервере, но WordPress все равно отвечает
Часто это означает, что правило добавили не в тот конфиг или оно перекрывается другим правилом. Проверьте порядок директив и то, действительно ли сайт работает под Apache, nginx или через прокси.
Использовали плагин и забыли, что он делает еще что-то
Некоторые плагины безопасности отключают XML-RPC вместе с другими механизмами защиты или оптимизации. Если после установки начались странные эффекты, отключайте функции по одной и проверяйте результат, а не весь пакет сразу.
Проверили только главную страницу
Это типичная ошибка. Главная может открываться нормально, а интеграция для публикации уже сломана. После изменения всегда проверяйте не только фронтенд, но и админку, REST API, внешние подключения и журналы ошибок.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищенным», но убирает один из лишних входов, который часто используют для перебора и шумных запросов. Это полезно, если у вас нет реальной потребности в этом интерфейсе.
- не отключайте XML-RPC вслепую на сайте с интеграциями;
- если нужен только один сервис, проверьте, можно ли перевести его на REST API;
- не ставьте несколько плагинов безопасности с одинаковой функцией блокировки;
- после изменений смотрите не только на отсутствие ошибок, но и на снижение лишних запросов в логах.
Если вам нужен более широкий набор технической чистки сайта — от дублей и служебных хвостов до части SEO-настроек — имеет смысл смотреть на инструменты, которые решают несколько задач сразу, а не ставить отдельный плагин под каждую мелочь. Но и в этом случае сначала проверяйте, что именно меняется в конфигурации, а не включайте все подряд.
В итоге рабочая схема простая: сначала диагностика, потом точечное отключение, затем проверка зависимостей. Так вы убираете XML-RPC там, где он не нужен, и не ломаете то, что еще живет на старых интеграциях.