Если в логах или в браузере вы видите /xmlrpc.php с ответом 403 или 404, это не всегда ошибка ядра WordPress. Чаще всего так проявляется либо защита на уровне сервера, либо отключение XML-RPC в плагине безопасности, либо правила в .htaccess / nginx. Проблема в том, что один и тот же симптом может означать разные вещи: где-то XML-RPC действительно нужно закрыть, а где-то вы случайно поломали мобильное приложение, Jetpack или внешнюю интеграцию.
Ниже — практический разбор: как понять, что именно блокирует XML-RPC, когда его можно отключать, чем заменить старые сценарии, и как проверить, что после правки сайт не потерял нужные подключения.
Когда XML-RPC вообще нужен
XML-RPC — старый интерфейс WordPress для удалённых запросов. Он до сих пор встречается в трёх типичных сценариях:
- мобильное приложение WordPress;
- Jetpack и некоторые связанные сервисы;
- сторонние публикации и интеграции, которые до сих пор не переведены на REST API.
Если у вас обычный сайт без внешней публикации и без старых интеграций, XML-RPC чаще всего не нужен. Но отключать его стоит осознанно: сначала убедитесь, что никто из команды и никаких сервисов не использует его для входа, публикации или синхронизации.
Диагностика: что именно даёт 403 или 404
Первый шаг — не править код, а понять источник ответа. Один и тот же 403 может прийти от WordPress, от плагина безопасности, от nginx, от Apache или от WAF/CDN. 404 тоже бывает разным: файл отсутствует физически, запрос переписан, либо сервер специально маскирует наличие XML-RPC.
Проверка с сервера и из браузера
Сначала посмотрите заголовки ответа. Это помогает понять, кто именно отвечает на запрос.
curl -I https://example.com/xmlrpc.phpЕсли вы видите заголовки, характерные для nginx, Cloudflare или другого прокси, проблема может быть не в WordPress. Если ответ идёт от самого сайта, дальше проверяйте плагины и правила в конфигурации.
Что искать в логах
Полезно посмотреть:
- access log веб-сервера — есть ли запросы к
/xmlrpc.phpи какой код ответа; - error log — нет ли сообщений о блокировке по правилам безопасности;
- логи плагина безопасности — многие из них пишут отдельные события о запрете XML-RPC.
Если в логах есть 403 с пометкой плагина, значит блокировка сделана на уровне WordPress. Если в логах вообще нет следов запроса, возможно, его режет внешний фильтр до попадания в PHP.
Как отключить XML-RPC безопасно
Есть три рабочих подхода: плагин безопасности, правило на сервере или код в теме/мини-плагине. Для продакшена лучше выбирать тот вариант, который соответствует вашей архитектуре и не ломает обновления.
| Подход | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужно быстро закрыть XML-RPC без правок сервера | Просто включить, легко откатить | Зависимость от плагина, лишняя нагрузка |
| Правило на сервере | Есть доступ к nginx/Apache и нужен жёсткий запрет | Блокировка до PHP, меньше нагрузки | Нужно аккуратно сопровождать конфиг |
| Код в мини-плагине | Нужен точечный контроль внутри WordPress | Прозрачная логика, можно версионировать | Если сделать в теме, потеряется при смене темы |
Вариант 1: отключение через код
Если вам нужен управляемый вариант без стороннего плагина, добавьте фильтр в мини-плагин или mu-plugin. Это не удаляет файл xmlrpc.php, но запрещает его использование на уровне WordPress.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой способ подходит, если вы хотите быстро остановить XML-RPC и при этом оставить возможность включить его обратно без правок сервера.
Вариант 2: блокировка на уровне nginx
Если сайт работает на nginx и XML-RPC точно не нужен, лучше закрыть его до передачи запроса в PHP:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Это снижает лишнюю нагрузку и убирает шум в логах. Но перед применением проверьте, что у вас нет интеграций, которым этот файл нужен.
Вариант 3: блокировка в Apache
Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт за прокси или CDN, убедитесь, что блокировка не конфликтует с внешними правилами. Иначе получите ситуацию, когда вы отключили XML-RPC в двух местах, а потом долго ищете, кто именно отдаёт 403.
Как понять, что решение сработало
После изменения проверьте не только код ответа, но и побочные эффекты. Нужен именно рабочий контроль, а не визуальная проверка в админке.
- выполните
curl -I https://example.com/xmlrpc.phpи убедитесь, что ответ соответствует выбранной политике; - проверьте логи на отсутствие новых обращений к XML-RPC с ошибками;
- если используется Jetpack, мобильное приложение или внешняя публикация, протестируйте их отдельно;
- посмотрите, не выросло ли число 404/403 на уровне WAF или CDN после изменения;
- убедитесь, что сайт не начал отдавать лишние ошибки в консоли мониторинга.
Если вы отключали XML-RPC ради безопасности, полезно проверить ещё и сценарий brute force: многие боты используют этот endpoint для массовых попыток авторизации. После блокировки таких запросов в логах должно стать заметно меньше.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо: Jetpack в ряде сценариев использует XML-RPC для связи с сайтом. Решение простое — либо вернуть доступ, либо перевести нужную задачу на другой механизм, если он поддерживается конкретным сервисом.
Поставили плагин безопасности и забыли, где именно блокировка
В итоге админ видит 403, а разработчик ищет проблему в .htaccess. Чтобы не путаться, фиксируйте место изменения: в тикете, в README проекта или хотя бы в комментарии к мини-плагину.
Скрыли XML-RPC через 404, но не убрали нагрузку
Если ответ маскируется на уровне WordPress, запрос всё равно может доходить до PHP. Для высоконагруженного сайта лучше закрывать endpoint на уровне веб-сервера или WAF.
Сделали правило в теме
Это типичная ошибка. При смене темы защита исчезнет. Для таких настроек используйте мини-плагин или mu-plugin, а не файл темы.
Практические советы по безопасности и производительности
Если XML-RPC не нужен, его лучше закрыть не только из соображений безопасности, но и ради чистоты инфраструктуры. Меньше лишних запросов — меньше шума в логах и меньше поводов для автоматических блокировок.
- не дублируйте блокировку в трёх местах без необходимости;
- не отключайте XML-RPC, пока не проверили внешние интеграции;
- если сайт под атакой, сначала ограничьте endpoint на сервере, а потом уже разбирайтесь с плагинами;
- для постоянной защиты лучше хранить правило в конфигурации, а не в ручных правках админки.
Если вам нужно одновременно почистить сайт от лишних технических хвостов, отключить дубли и упростить SEO-настройки, иногда удобнее вынести часть таких задач в отдельный инструмент вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае важно понимать, что именно отключается и где это хранится.
Мини-чек-лист перед выкладкой на продакшен
- Проверен список сервисов, которые могут использовать XML-RPC.
- Выбран один основной способ блокировки, без дублирования правил.
- Сделан тест
curl -Iс ожидаемым кодом ответа. - Проверены логи веб-сервера и плагинов безопасности.
- Подтверждено, что Jetpack или другие интеграции не сломались.
- Изменение зафиксировано в документации проекта.
Если задача была именно в том, чтобы убрать лишний доступ к xmlrpc.php, после этих проверок вы уже будете понимать, что блокировка работает не только формально, но и по факту. А если 403 или 404 продолжает появляться в неожиданных местах, значит источник ответа нужно искать выше по цепочке: CDN, WAF, серверный конфиг или сторонний security-плагин.