XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестал работать Jetpack, внешняя публикация или мобильное приложение. Проблема в том, что это не просто лишний файл, а интерфейс, через который некоторые сервисы до сих пор общаются с сайтом. Поэтому правильный подход здесь не в грубом запрете, а в проверке, нужен ли он вообще, и в точечной блокировке, если не нужен.
Когда XML-RPC действительно стоит отключать
Если вы не используете старые внешние клиенты, удалённую публикацию, Jetpack-функции, которые завязаны на XML-RPC, и не подключали сторонние сервисы через этот протокол, его можно закрыть. На практике чаще всего XML-RPC оставляют включённым по инерции, хотя сайт работает только через админку и REST API.
Но есть и обратная ситуация: на сайте стоит Jetpack, настроена публикация из приложения WordPress, или редакторы отправляют записи из стороннего инструмента. В этом случае отключение без проверки сломает рабочий процесс. Именно поэтому сначала нужна диагностика, а уже потом — блокировка.
Диагностика: используется ли XML-RPC сейчас
Самый простой способ — проверить, отвечает ли файл /xmlrpc.php и есть ли реальные обращения к нему в логах сервера. Если у вас есть доступ к access.log, ищите запросы к этому файлу за последние дни. Если запросов нет, это ещё не доказательство, что он не нужен, но хороший сигнал.
Ещё один практичный тест — посмотреть, не завязаны ли на XML-RPC ваши плагины и приложения. Jetpack, некоторые мобильные клиенты и сервисы автопостинга могут использовать именно его, а не REST API.
Что проверить перед отключением
- используется ли Jetpack и какие его модули включены;
- публикуют ли редакторы записи из мобильного приложения WordPress;
- подключены ли внешние сервисы автопостинга или синхронизации;
- есть ли в логах запросы к
/xmlrpc.php; - не настроены ли интеграции старого типа, которые не умеют работать через REST API.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Через код в теме или mu-plugin | Нужен контролируемый и предсказуемый вариант | Без лишних плагинов, легко проверить | Нужно аккуратно выбрать место для кода |
| Через плагин безопасности | Если уже используете такой плагин для других задач | Быстро включить и выключить | Лишняя зависимость, иногда блокирует лишнее |
| Через серверную конфигурацию | Если есть доступ к nginx/apache и нужен жёсткий запрет | Запрос не доходит до WordPress | Нужно понимать конфиг сервера, можно задеть другие правила |
Пошаговое решение через код
Если вам нужен прозрачный способ без установки ещё одного плагина, добавьте код в functions.php дочерней темы или, что лучше, в небольшой mu-plugin. Для большинства сайтов этого достаточно.
<?php
/**
* Disable XML-RPC.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот фильтр отключает сам механизм XML-RPC на уровне WordPress. После этого запросы к xmlrpc.php перестанут обрабатываться как раньше. Если сайт использует только обычную авторизацию в админке и REST API, этого обычно достаточно.
Если хочется не просто отключить функциональность, а сразу отдавать 403 на сам файл, можно добавить правило на уровне веб-сервера. Это уже жёстче, и такой вариант имеет смысл, когда вы уверены, что XML-RPC не нужен вообще.
<Files xmlrpc.php>
Require all denied
</Files>
Для Apache это рабочий вариант, но его нельзя бездумно вставлять в любой хостинг. На nginx правила будут другими, и там лучше править конфиг сервера, а не пытаться повторить Apache-синтаксис.
Если нужен компромисс: не отключать всё, а ограничить
Иногда XML-RPC нужен только для одного сервиса. В таком случае лучше не рубить его полностью, а ограничить доступ по IP или оставить только нужный сценарий на уровне сервера. Это уже зависит от инфраструктуры и обычно делается в конфигурации nginx или через firewall, а не в WordPress.
Проверка результата после внедрения
После изменения откройте /xmlrpc.php в браузере или проверьте его через curl. В норме вы должны увидеть отказ в доступе или сообщение о том, что метод недоступен, а не полноценный ответ WordPress.
curl -I https://example.com/xmlrpc.phpЕсли вы отключали XML-RPC через фильтр, проверьте ещё и связанные сценарии:
- открывается ли админка и работает ли вход;
- не сломался ли Jetpack, если он установлен;
- не перестала ли работать публикация из мобильного приложения;
- не появились ли ошибки в логах после изменения.
Хорошая проверка — зайти в Jetpack или в приложение WordPress и попробовать выполнить действие, которое раньше использовало XML-RPC. Если интеграция не нужна, просто убедитесь, что сайт не выдаёт неожиданных ошибок и в логах нет повторяющихся попыток доступа.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичная ситуация, когда блокировку включили без инвентаризации интеграций. Решение простое: либо вернуть доступ, либо перенести нужную функцию на другой способ подключения, если плагин это поддерживает. Сначала проверьте, действительно ли именно XML-RPC был точкой отказа.
Поставили плагин безопасности, но сайт начал блокировать лишнее
Некоторые плагины безопасности отключают не только XML-RPC, но и другие полезные механизмы. Если после установки появились проблемы с авторизацией, REST API или редактором, временно отключите правило и проверьте, что именно оно ломает. Для точечного контроля код или серверное правило обычно предсказуемее.
Добавили правило в .htaccess, но ничего не изменилось
Так бывает, если сайт работает на nginx или если правило стоит не в том месте файла. Для Apache важно, чтобы модуль mod_authz_core поддерживал директиву Require all denied, а для nginx нужен отдельный конфиг. Если вы не уверены в сервере, сначала проверьте его тип в панели хостинга.
Безопасность и производительность: что реально даёт отключение
Отключение XML-RPC само по себе не делает сайт «защищённым от всего», но убирает один из старых векторов атак и уменьшает шум в логах. Это полезно, если сайт не использует протокол вообще. При этом не стоит ожидать заметного ускорения фронтенда: выгода здесь скорее в снижении поверхности атаки и в чистоте инфраструктуры.
Если вам нужен более широкий набор настроек для чистки WordPress, отключения лишнего и контроля технических дублей, имеет смысл смотреть на инструменты уровня Clearfy Pro: Clearfy Pro. Но даже в этом случае не стоит включать всё подряд — сначала проверьте, что именно вы отключаете и как это влияет на рабочие сценарии.
Короткий чек-лист перед публикацией изменения
- проверили, используется ли XML-RPC в текущих интеграциях;
- выбрали способ отключения: код, плагин или сервер;
- сделали резервную копию перед правкой;
- проверили ответ
/xmlrpc.phpпосле изменения; - протестировали Jetpack, мобильное приложение и автопостинг, если они есть;
- посмотрели логи на ошибки после внедрения.
Если сайт небольшой и внешние интеграции не используются, самый практичный путь — отключить XML-RPC через фильтр xmlrpc_enabled и затем проверить, что ничего не завязано на старый протокол. Если же у вас есть рабочие интеграции, сначала разберите их по списку, а потом уже закрывайте доступ точечно.