XML-RPC в WordPress до сих пор встречается на старых сайтах, в мобильных клиентах и в некоторых интеграциях. Но если вы не используете удаленную публикацию, внешние сервисы синхронизации или старые приложения, этот интерфейс часто только расширяет поверхность атаки и создает лишний шум в логах. На практике задача обычно звучит так: отключить XML-RPC, но не сломать сайт и не гадать, нужен ли он вообще.
Когда XML-RPC можно отключать, а когда лучше не трогать
Отключение уместно, если сайт работает через обычную админку, REST API и современные интеграции, а в логах регулярно появляются запросы к /xmlrpc.php. Если вы не пользуетесь приложением WordPress для удаленной публикации, не подключали внешние сервисы, которым нужен XML-RPC, и не видите зависимость в документации плагинов, отключение обычно безопасно.
Не стоит рубить интерфейс вслепую, если на сайте есть:
- старые мобильные клиенты WordPress;
- сервисы автопостинга, которые работают именно через XML-RPC;
- интеграции, где в документации прямо указан XML-RPC, а не REST API;
- устаревшие плагины синхронизации контента.
Диагностика: как понять, используется ли XML-RPC сейчас
Перед отключением проверьте, есть ли реальные обращения к xmlrpc.php. Самый простой способ — посмотреть access-логи веб-сервера или логи защиты на хостинге. Если у вас есть доступ к серверу, ищите запросы вида POST /xmlrpc.php. Если доступа нет, иногда достаточно посмотреть отчеты в панели хостинга или в плагине безопасности.
Полезно также проверить, не завязаны ли на XML-RPC внешние сценарии:
- публикация из мобильного приложения WordPress;
- синхронизация с внешними редакторами;
- автоматическая публикация через старые сервисы;
- подключенные плагины, которые давно не обновлялись.
Если сомневаетесь, временно ограничьте доступ к файлу на уровне сервера и посмотрите, что перестанет работать. Но для большинства сайтов проще и безопаснее сначала сделать отключение через код, а потом проверить поведение.
Пошаговое решение: отключаем XML-RPC через код
Самый предсказуемый вариант — добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin. Если вы правите тему, помните: при обновлении родительской темы изменения могут потеряться. Для постоянного правила лучше использовать отдельный мини-плагин.
Вариант 1. Отключить XML-RPC полностью
Этот способ подходит, если вы уверены, что интерфейс не нужен вообще.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
После этого WordPress перестанет обслуживать XML-RPC-запросы на уровне ядра. Это не удаляет файл xmlrpc.php физически, но делает его бесполезным для нормальных запросов WordPress.
Вариант 2. Ограничить доступ на уровне сервера
Если нужен более жесткий контроль, можно закрыть xmlrpc.php на уровне веб-сервера. Это полезно, когда на сайт идет много мусорных запросов и вы хотите отрезать их раньше, чем они попадут в PHP.
Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx обычно добавляют отдельное правило в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Если у вас нет доступа к конфигу сервера, используйте вариант с фильтром WordPress. Он проще в сопровождении и не требует вмешательства в инфраструктуру.
Сравнение подходов: код, сервер, плагин
| Способ | Где работает | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | WordPress | Просто, быстро, не зависит от веб-сервера | Запрос все равно доходит до PHP |
| Правило в Apache/Nginx | Сервер | Режет запрос раньше, меньше нагрузки | Нужен доступ к конфигу |
| Плагин безопасности | WordPress | Удобно для админов без доступа к коду | Лишняя зависимость, возможны конфликты |
Если вам нужно просто убрать функциональность, достаточно фильтра. Если сайт атакуют по xmlrpc.php, лучше дополнить его серверным правилом.
Если нужен не полный запрет, а частичное ограничение
Иногда XML-RPC нужен только для одной интеграции, а все остальное хочется закрыть. В таком случае лучше сначала проверить, можно ли перевести интеграцию на REST API. Это более современный и прозрачный вариант. Если перевести нельзя, не отключайте XML-RPC полностью, пока не убедитесь, что нужный сценарий работает через альтернативный канал.
На практике полезно сначала отключить XML-RPC на тестовой копии сайта и прогнать реальные сценарии:
- публикацию записи из внешнего сервиса;
- синхронизацию медиа, если она есть;
- работу мобильного приложения;
- автоматические задания, которые запускаются по расписанию.
Проверка результата после внедрения
После отключения откройте https://ваш-домен/xmlrpc.php. В зависимости от способа блокировки вы увидите либо запрет на уровне сервера, либо ответ WordPress о том, что XML-RPC недоступен. Главное — не должно быть успешного ответа, который позволяет выполнять методы XML-RPC.
Дополнительно проверьте:
- не появились ли ошибки в журнале PHP;
- работает ли вход в админку и обычная публикация записей;
- не сломались ли плагины, которые используют удаленные вызовы;
- не изменилось ли поведение REST API, если он используется отдельно.
Если у вас есть мониторинг, посмотрите, уменьшилось ли количество запросов к xmlrpc.php после блокировки. Это хороший косвенный признак, что правило действительно сработало.
Частые ошибки и как их исправить
Отключили XML-RPC, а мобильное приложение перестало публиковать
Значит, приложение или сервис реально использовали XML-RPC. Решение простое: либо вернуть доступ, либо перевести сценарий на REST API, если приложение это поддерживает.
Добавили правило в тему, а после обновления оно исчезло
Код в functions.php родительской темы — плохое место для таких настроек. Перенесите фильтр в дочернюю тему или в отдельный mu-plugin.
Поставили плагин безопасности и получили дублирующее блокирование
Некоторые плагины уже умеют отключать XML-RPC. Если вы добавили еще и серверное правило, это не ошибка, но при диагностике будет сложнее понять, что именно блокирует запрос. Лучше оставить один основной механизм и документировать его.
Закрыли XML-RPC, но атаки в логах не исчезли
Это нормально: боты продолжают стучаться в старые URL. Важен не сам факт запросов, а то, что они больше не проходят дальше. Если нагрузка все еще заметна, добавьте блокировку на уровне веб-сервера или WAF.
Практические советы по безопасности и производительности
Если сайт публичный и XML-RPC не нужен, отключение — разумная мера гигиены. Но не стоит считать ее полноценной защитой. Она уменьшает лишнюю поверхность атаки, однако не заменяет обновления ядра, тем, плагинов и нормальную политику паролей.
Для сайтов с высокой нагрузкой серверная блокировка обычно полезнее, чем только фильтр WordPress: запросы отсекаются раньше, а PHP не тратит ресурсы на обработку заведомо ненужных обращений. Если у вас уже есть плагин безопасности, проверьте, не умеет ли он делать это штатно, чтобы не плодить несколько слоев одного и того же ограничения.
Если нужно регулярно чистить сайт от технического мусора, дублирующихся архивов и лишних служебных страниц, иногда удобнее собрать это в один набор настроек. В таком случае можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpedu.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xmlrpc-v-wordpress-cherez-funktsii-temy-ili-plagina
Мини-чек-лист перед выкладкой на боевой сайт
- Проверили, что XML-RPC не нужен для текущих интеграций.
- Сделали изменение в дочерней теме, mu-plugin или конфиге сервера, а не в родительской теме.
- Протестировали публикацию, вход в админку и внешние сервисы.
- Посмотрели логи после изменения.
- Зафиксировали, какой именно способ блокировки используется.
Если после внедрения все штатные сценарии работают, а /xmlrpc.php больше не отвечает как рабочий интерфейс, задача решена корректно. В этом случае вы убираете ненужный вход в систему без лишнего риска для остального сайта.