XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: лишняя поверхность атаки, шум в логах, попытки брутфорса через xmlrpc.php или просто отсутствие нужды в старом протоколе. Но у этого решения есть нюанс: если на сайте реально используются внешние клиенты, Jetpack или мобильное приложение WordPress, грубое отключение ломает интеграции без явного сообщения на фронтенде.
Ниже — рабочий сценарий, который помогает сначала понять, нужен ли XML-RPC вообще, а потом отключить его аккуратно: через плагин или через код в теме/му-плагине. Такой подход удобнее, чем править серверные правила вслепую, потому что результат проще проверить и откатить.
Когда XML-RPC действительно стоит отключать
Если сайт редактируется только из админки, а внешние клиенты и интеграции не используются, XML-RPC чаще всего не нужен. В логах при этом нередко видны запросы к /xmlrpc.php от ботов и сканеров. Это не всегда критично, но лишняя нагрузка и лишний шум в безопасности обычно не нужны.
Отключать его стоит, если:
- вы не публикуете записи через мобильное приложение WordPress;
- не используете Jetpack для функций, завязанных на XML-RPC;
- не подключали внешние редакторы и сервисы, которые работают через XML-RPC;
- на сервере регулярно фиксируются попытки авторизации через
xmlrpc.php.
Если хотя бы один из пунктов под вопросом, сначала проверьте фактическое использование, а уже потом отключайте доступ.
Диагностика: как понять, используется ли XML-RPC
Самый простой способ — открыть /xmlrpc.php в браузере. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает, что протокол нужен, но подтверждает, что endpoint живой.
Дальше полезно посмотреть логи веб-сервера или логи безопасности. Если там есть обращения к xmlrpc.php только от неизвестных IP и без успешных вызовов, это хороший аргумент в пользу отключения. Если же в логах видны запросы от ваших сервисов, сначала выясните, что именно их отправляет.
Что проверить перед отключением
- Используется ли Jetpack и какие модули включены.
- Есть ли публикация через мобильное приложение WordPress.
- Подключены ли внешние редакторы, автопостинг или интеграции через XML-RPC.
- Нет ли в логах успешных запросов к
xmlrpc.phpс ваших IP или от доверенных сервисов.
Способ 1: отключить XML-RPC через код в теме или mu-plugin
Если нужен контролируемый и обратимый вариант, проще всего добавить фильтр в functions.php дочерней темы или, что лучше, в отдельный mu-plugin. Для production-сайта mu-plugin предпочтительнее: он не зависит от активной темы и не исчезнет при обновлении.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Если вы добавляете код в functions.php дочерней темы, строка будет той же:
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ отключает сам XML-RPC на уровне WordPress. В отличие от блокировки на сервере, он проще для диагностики: если что-то перестало работать, вы быстро убираете фильтр и проверяете, какой сервис зависит от протокола.
Способ 2: отключить через плагин
Если не хочется трогать код, используйте плагин, который умеет отключать XML-RPC без ручной правки файлов. Удобство здесь в том, что настройку можно включить и выключить из админки, а не через FTP или SSH.
Из практики это полезно на сайтах, где доступ к серверу ограничен или изменения вносятся не разработчиком, а редактором. Но у плагина есть минус: лишний слой логики и зависимость от его качества. Для одной-двух точечных задач код обычно надежнее.
| Подход | Плюс | Минус |
|---|---|---|
| Код в mu-plugin | Не зависит от темы, легко контролировать | Нужен доступ к файлам |
| Код в functions.php | Быстро внедрить | Слетает при смене темы |
| Плагин | Удобно без кода | Лишняя зависимость |
Как проверить, что XML-RPC действительно отключен
После внедрения решения не ограничивайтесь тем, что «ничего не сломалось». Проверьте endpoint напрямую и посмотрите ответ сервера.
- Откройте
https://ваш-домен.ru/xmlrpc.php. - Убедитесь, что WordPress больше не отвечает как активный XML-RPC endpoint.
- Проверьте логи веб-сервера на повторные обращения к этому файлу.
- Если у вас есть Jetpack или мобильное приложение, протестируйте именно те функции, которые могли использовать XML-RPC.
Если вы используете WP-CLI и есть доступ к консоли, полезно дополнительно проверить, не осталось ли в конфигурации сайта кастомных интеграций, завязанных на старый протокол. Сам WordPress не дает отдельной команды для «покажи, кто использует XML-RPC», поэтому тут важнее практическая проверка интеграций, а не формальная галочка.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий. Jetpack в некоторых конфигурациях использует XML-RPC для связи с сайтом. Если модуль нужен, не отключайте протокол вслепую. Сначала проверьте, какие функции Jetpack реально используются, и только потом принимайте решение.
Добавили код в родительскую тему
После обновления темы фильтр исчезает, и XML-RPC снова включается. Для постоянного решения используйте дочернюю тему или mu-plugin.
Спрятали проблему блокировкой на сервере, но не проверили интеграции
Блокировка через .htaccess или конфиг Nginx может быть рабочей, но она хуже для диагностики. Если что-то ломается, вы видите только «не работает», без понимания, на каком уровне произошел сбой. Для начала лучше отключать через WordPress-фильтр, а серверные правила оставлять как следующий шаг, если они действительно нужны.
Проверили только главную страницу
То, что сайт открывается, не значит, что все интеграции живы. Обязательно тестируйте именно те сценарии, которые потенциально используют XML-RPC: публикацию из приложения, удаленную отправку записей, работу Jetpack.
Что делать, если XML-RPC нужен частично
Иногда полный запрет не подходит. Например, сайт использует один внешний сервис, а все остальные запросы к XML-RPC вы хотите закрыть. В таком случае лучше не отключать протокол полностью, а сначала выяснить, какие именно методы вызываются, и ограничить доступ на уровне сервера или через отдельную логику проверки запросов. Это уже более тонкая настройка, и она имеет смысл только тогда, когда вы точно знаете источник запросов.
Если задача сводится к защите от брутфорса, а не к полному запрету протокола, иногда достаточно ограничить доступ по IP или закрыть endpoint на уровне WAF. Но это уже отдельный сценарий, и он требует аккуратной проверки, чтобы не задеть легитимные вызовы.
Практика безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищенным», но убирает один из популярных векторов атаки и снижает количество мусорных запросов. На загруженных сайтах это еще и уменьшает шум в логах, из-за которого сложнее искать реальные проблемы.
Если вы регулярно чистите сайт от лишнего технического мусора, имеет смысл смотреть на XML-RPC вместе с другими точечными оптимизациями: отключением ненужных REST-эндпоинтов, чисткой дублей, ограничением служебных запросов и контролем индексации. Для таких задач удобно использовать Clearfy Pro, если вам нужен набор практических настроек без ручного редактирования каждого участка кода.
Но даже если вы используете плагин, не отключайте все подряд. Сначала проверьте, что именно он меняет, и оставляйте только те настройки, которые действительно решают вашу задачу.