Как отключить XML-RPC в WordPress и проверить, что сайт не ломается

Автор: Лев Ершов | Опубликовано: 10.08.2026

XML-RPC в WordPress часто держат включённым «на всякий случай», хотя на многих сайтах он не нужен. Проблема в том, что вместе с редкими интеграциями он открывает лишнюю поверхность атаки и иногда создаёт шум в логах. Если у вас нет старого мобильного клиента WordPress, внешнего сервиса публикации через XML-RPC или специфической интеграции, отключение — нормальная практическая мера.

Но отключать его вслепую не стоит. На живом сайте сначала нужно понять, кто именно к нему обращается, и только потом резать доступ. Ниже — рабочий сценарий: как диагностировать использование XML-RPC, отключить его без лишнего риска и проверить результат.

Когда XML-RPC действительно можно отключать

На большинстве современных сайтов XML-RPC не нужен. Если вы публикуете записи через админку, используете REST API, мобильное приложение WordPress не подключено, а сторонние сервисы работают через обычный HTTP или вебхуки, то XML-RPC обычно можно убрать без последствий.

Оставлять его имеет смысл только если вы точно знаете, что он нужен. Типичные случаи:

старые мобильные клиенты WordPress;
внешние сервисы автопостинга, которые не умеют работать через REST API;
интеграции, завязанные на xmlrpc.php для pingback/trackback или удалённой публикации;
устаревшие плагины синхронизации, которые не обновлялись годами.

Если сайт обычный: контент, WooCommerce, формы, подписки, аналитика — чаще всего XML-RPC только мешает.

Диагностика: кто обращается к xmlrpc.php

Перед отключением посмотрите, есть ли реальные запросы. Самый простой способ — логи веб-сервера. Ищите обращения к /xmlrpc.php по IP, частоте и user-agent. Если видите только случайные сканеры, это один сценарий. Если есть стабильные запросы от вашего сервиса — другой.

Что проверить в логах

частоту запросов к xmlrpc.php;
IP-адреса и географию, если это важно для вашей инфраструктуры;
HTTP-коды ответа: 200, 403, 404;
периодичность — постоянные попытки могут указывать на брутфорс или сканирование;
совпадение с окнами, когда у вас работают внешние интеграции.

Если доступа к логам нет, можно временно включить простую проверку на уровне WordPress и посмотреть, не ломаются ли сценарии публикации или синхронизации после отключения.

Сравнение подходов: код, сервер, плагин

Способ	Плюсы	Минусы	Когда выбирать
Код в `functions.php` или mu-plugin	Быстро, прозрачно, легко откатить	Зависит от темы или деплоя	Если нужен точечный контроль в WordPress
Правило на сервере	Блокирует запрос раньше загрузки WordPress	Нужен доступ к конфигу Nginx/Apache	Если хотите снизить нагрузку и закрыть доступ на уровне веб-сервера
Плагин безопасности	Удобно для админов без доступа к коду	Лишняя зависимость, не всегда понятно, что именно делает плагин	Если у вас уже есть рабочий security-плагин

Для продакшена я обычно начинаю с кода или сервера. Так проще понять, что именно изменилось, и не тащить лишний функционал в админку.

Пошаговое решение через код

Самый аккуратный вариант — отключить XML-RPC через фильтр xmlrpc_enabled. Это не ломает сайт целиком и легко откатывается.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Код можно добавить в functions.php дочерней темы, но лучше вынести в небольшой mu-plugin, чтобы он не зависел от темы. Для этого создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Если хотите не просто отключить функциональность, а сразу отдавать 403 на сам файл xmlrpc.php, это уже удобнее делать на уровне сервера. Но для большинства задач фильтра достаточно.

Блокировка на уровне Nginx

Если сайт работает на Nginx, можно закрыть доступ к xmlrpc.php до попадания в PHP. Это полезно, когда вы хотите уменьшить нагрузку от массовых запросов.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache обычно используют правило в .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Важно: если у вас сложная инфраструктура с прокси, CDN или WAF, сначала проверьте, где именно лучше блокировать запрос. Иногда разумнее закрыть его на edge-уровне, а не на самом WordPress.

Если XML-RPC нужен частично

Иногда отключать его полностью нельзя: например, один старый сервис ещё живёт, а всё остальное вы уже перевели на REST API. В таком случае лучше не оставлять открытым весь интерфейс, а ограничить доступ на уровне сервера по IP или по отдельному правилу безопасности.

Это уже не универсальная настройка WordPress, а инфраструктурная задача. Самый безопасный путь — оставить доступ только для конкретного сервиса и закрыть всё остальное. Если сервис умеет работать через REST API, лучше мигрировать на него, чем держать XML-RPC ради одного сценария.

Как проверить, что решение сработало

После внедрения проверьте не только статус страницы, но и поведение реальных сценариев.

Откройте /xmlrpc.php в браузере или через curl и убедитесь, что доступ закрыт или функция отключена.
Проверьте, что публикация записей через админку работает как обычно.
Если есть внешние сервисы, протестируйте их вручную: импорт, автопостинг, синхронизацию.
Посмотрите логи веб-сервера: запросы к xmlrpc.php должны либо исчезнуть, либо получать ожидаемый отказ.

Пример проверки через curl:

curl -I https://example.com/xmlrpc.php

Если вы блокировали файл на сервере, ожидайте 403. Если отключали через фильтр WordPress, поведение может отличаться в зависимости от конфигурации, но доступ к XML-RPC должен быть недоступен для использования.

Частые ошибки и как их исправить

Отключили XML-RPC, а потом сломался внешний сервис

Значит, сервис реально использовал XML-RPC. Не возвращайте всё назад автоматически. Сначала выясните, можно ли перевести его на REST API или ограничить доступ только для нужного IP.

Блокировка в .htaccess не сработала

Частая причина — сайт работает не на Apache, а на Nginx, либо .htaccess вообще не читается в текущей схеме. Проверьте веб-сервер и применяйте правило в правильном месте.

Код добавили в тему, а после обновления он исчез

Это типичная ошибка. Для таких настроек лучше использовать дочернюю тему или mu-plugin. Тогда отключение не потеряется при обновлении.

Отключили XML-RPC, но в логах он всё равно светится

Это нормально, если сканеры продолжают стучаться на URL. Важно, чтобы они не получали доступ к функциональности. Смотрите не только факт запроса, но и код ответа, а также нагрузку на PHP.

Практические советы по безопасности и производительности

Если XML-RPC вам не нужен, отключение — это не «оптимизация ради галочки», а удаление лишнего входа в систему. На сайтах с высокой посещаемостью или частыми сканированиями это ещё и способ уменьшить мусор в логах и лишние обращения к PHP.

Но не смешивайте задачи. Если вам нужна защита от брутфорса, не рассчитывайте только на отключение XML-RPC. Используйте нормальные меры: ограничение попыток входа, 2FA, актуальные обновления, WAF, контроль админских учёток. Если нужен аудит безопасности и чистка лишних сущностей, в экосистеме WPShop для этого есть Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Главный принцип простой: отключайте только то, что не используете, и всегда проверяйте реальные интеграции. Тогда решение будет не «жёстким», а управляемым.