XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация, некоторые интеграции и старые клиенты для удаленного управления сайтом. Проблема не в самом XML-RPC, а в том, что его отключают без проверки зависимостей. Если у вас нет сервисов, которые реально используют этот интерфейс, отключение оправдано. Если есть — нужен точечный подход.
Когда XML-RPC действительно мешает
XML-RPC — это старый удаленный интерфейс WordPress. Его используют не только для атаки перебором логинов, но и для легитимных сценариев: публикация из внешних приложений, синхронизация с некоторыми сервисами, удаленное управление контентом. Поэтому задача звучит не как «выключить навсегда», а как «понять, нужен ли он вообще и чем его заменить».
Если на сайте нет внешних клиентов, которые обращаются к /xmlrpc.php, отключение обычно снижает поверхность атаки и убирает лишний публичный endpoint. Но если вы пользуетесь приложением WordPress на телефоне, подключали сторонний редактор или сервис автопостинга, сначала проверьте, как именно он авторизуется.
Диагностика: как понять, используется ли XML-RPC
Начните с логов веб-сервера и плагинов безопасности. Ищите обращения к /xmlrpc.php, особенно повторяющиеся POST-запросы. Если endpoint дергают только боты, это один сценарий. Если есть запросы с ваших IP, от внешних сервисов или мобильных устройств — уже другой.
Что проверить до отключения
- Используете ли вы приложение WordPress на iOS/Android.
- Есть ли внешняя публикация через Jetpack, IFTTT, Zapier или похожие сервисы.
- Подключены ли старые интеграции, которые работают через XML-RPC, а не через REST API.
- Есть ли в логах регулярные обращения к
xmlrpc.phpс ваших адресов.
Если доступа к логам нет, можно временно включить аудит в плагине безопасности или посмотреть статистику на уровне хостинга. Важно не гадать, а увидеть фактические обращения.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три рабочих варианта: через плагин, через код и через веб-сервер. Для большинства сайтов удобнее код в теме или мини-плагине: он прозрачен, не зависит от интерфейса админки и легко откатывается.
| Способ | Когда подходит | Компромисс |
|---|---|---|
| Плагин безопасности | Нужна быстрая настройка без кода | Дополнительная зависимость и лишний функционал |
Код в functions.php или MU-плагине | Нужен точечный контроль | Нужно следить за обновлениями темы |
| Ограничение на уровне сервера | Нужна жесткая блокировка | Можно случайно сломать внешние интеграции |
Вариант 1: отключить XML-RPC через код
Если вы уверены, что endpoint не нужен, добавьте фильтр в functions.php дочерней темы или в свой мини-плагин:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый простой способ. WordPress перестанет обслуживать XML-RPC-запросы, но сам файл xmlrpc.php на сервере останется доступным как точка входа — просто будет возвращать отказ.
Вариант 2: закрыть только опасные методы
Если XML-RPC нужен частично, можно не отключать его целиком, а ограничить конкретные методы. Например, это полезно, когда нужен удаленный доступ, но вы не хотите оставлять методы, связанные с перебором учетных данных.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['system.multicall'] );
unset( $methods['system.listMethods'] );
return $methods;
} );Такой подход не универсален, но иногда помогает, если вы хотите уменьшить риск без полной поломки интеграций. Перед применением проверьте, не завязаны ли ваши внешние сервисы на эти методы.
Вариант 3: блокировка на уровне nginx или Apache
Если задача именно в защите от массовых обращений, можно закрыть xmlrpc.php на уровне веб-сервера. Это уже более жесткая мера, и ее стоит использовать только если вы точно не используете XML-RPC.
# nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache логика похожая, но синтаксис будет другим. Если вы не уверены в конфигурации хостинга, лучше начать с фильтра WordPress, а не с серверной блокировки.
Что делать, если XML-RPC нужен частично
Иногда отключение ломает не сам сайт, а конкретный сценарий: публикацию из приложения, синхронизацию заметок или удаленный редактор. В этом случае не стоит сразу возвращать все назад. Сначала выясните, можно ли перевести интеграцию на REST API или на другой способ авторизации.
Если сервис сторонний и поддерживает только XML-RPC, оставьте endpoint включенным, но ограничьте доступ по IP на уровне сервера или поставьте дополнительную защиту от перебора логинов. Это лучше, чем полностью открытый интерфейс без контроля.
Проверка результата после внедрения
После отключения проверьте не только статус страницы, но и реальные сценарии использования. Откройте /xmlrpc.php в браузере: в норме вы не должны видеть рабочий endpoint для удаленных вызовов. Затем попробуйте то, что использовали раньше: мобильное приложение, внешний редактор, автопостинг.
- Проверьте, не появились ли ошибки авторизации в приложениях.
- Посмотрите логи сервера на повторные обращения к
xmlrpc.php. - Убедитесь, что публикация и редактирование записей работают через обычную админку.
- Если есть интеграции, протестируйте их вручную, а не по косвенным признакам.
Хороший признак — в логах больше нет успешных обращений к XML-RPC, а все нужные сценарии продолжают работать через админку или REST API.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про мобильное приложение
Если приложение WordPress перестало публиковать записи, значит оно использовало XML-RPC. Решение — либо вернуть доступ, либо перейти на другой инструмент, который работает через REST API.
Закрыли endpoint на сервере и сломали внешнюю интеграцию
Серверная блокировка жестче, чем фильтр WordPress. Если после правки перестал работать сервис публикации, откатите правило и проверьте, действительно ли оно нужно. Иногда достаточно ограничить доступ по IP, а не закрывать endpoint полностью.
Поставили плагин, который делает слишком много
Некоторые плагины безопасности отключают XML-RPC вместе с другими функциями, и потом сложно понять, что именно сломалось. Если нужен точечный контроль, лучше использовать минимальный код или отдельный MU-плагин.
Проверили только главную страницу
XML-RPC нельзя считать отключенным, если сайт просто открывается в браузере. Нужно проверить сам endpoint, логи и реальные интеграции. Иначе проблема всплывет позже, когда кто-то попробует опубликовать материал удаленно.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — разумная мера, но не единственная. Параллельно стоит проверить и другие точки входа: слабые пароли, лишние учетные записи, открытый REST API там, где он не нужен, и устаревшие плагины. Без этого выключение одного endpoint не даст заметного эффекта по безопасности.
Если вы управляете несколькими сайтами, удобнее вынести такие настройки в MU-плагин: он не зависит от темы и не исчезнет после обновления. Для сайтов с жесткими требованиями к безопасности это практичнее, чем править functions.php вручную.
Если нужен более широкий набор мер по чистке сайта, отключению дублей и технической оптимизации, иногда проще собрать это в одном наборе настроек, чем держать десяток разрозненных решений. Но даже в этом случае XML-RPC лучше проверять отдельно, потому что его отключение влияет на внешние сценарии, а не только на SEO или скорость.
Итог здесь простой: сначала выясняете, кто реально использует XML-RPC, потом выбираете способ блокировки, затем проверяете интеграции и логи. Именно такой порядок позволяет убрать лишний риск без неожиданных поломок.