XML-RPC в WordPress нужен не всем. Если вы не используете мобильное приложение WordPress, внешние публикации через старые клиенты или интеграции, завязанные именно на этот протокол, его можно отключить и тем самым убрать лишний вектор для перебора паролей и запросов к сайту.
Но отключать его стоит не «на всякий случай», а после проверки, что на сайте нет зависимых сценариев. Ниже — как быстро диагностировать ситуацию, отключить XML-RPC без поломки сайта и убедиться, что всё работает так, как нужно.
Когда XML-RPC действительно стоит отключать
На практике этот файл чаще всего оставляют включённым по привычке. Если сайт управляется из админки, а публикация идёт только через браузер, XML-RPC обычно не нужен. Особенно это актуально для небольших корпоративных сайтов, блогов и лендингов, где нет внешних клиентов, синхронизации с приложениями и старых интеграций.
Есть и обратные случаи. Если у вас подключено мобильное приложение WordPress, сторонний редактор, удалённая публикация через API-совместимый клиент или сервис, который использует XML-RPC вместо REST API, отключение сломает этот сценарий. Поэтому сначала проверьте зависимости, а уже потом меняйте поведение на сервере.
Быстрая диагностика проблемы
Самый простой признак — в логах или в отчётах WAF/плагина безопасности появляются частые обращения к /xmlrpc.php. Иногда это видно и без логов: сайт начинает получать много однотипных POST-запросов, а в админке нет объяснимой нагрузки.
Проверить доступность можно вручную:
curl -I https://example.com/xmlrpc.phpЕсли ответ не 404 и не 403, файл доступен. Это ещё не проблема само по себе, но если XML-RPC не используется, доступ лучше закрыть.
Дополнительно проверьте, не завязаны ли на него плагины или внешние сервисы. Если сомневаетесь, поищите в настройках интеграций упоминания XML-RPC, remote publishing, pingback или старых мобильных клиентов WordPress.
Как отключить XML-RPC без поломки сайта
Есть три рабочих подхода: через код, через сервер и через плагин безопасности. Выбор зависит от того, где у вас удобнее управлять правилами и насколько часто вы меняете конфигурацию.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Прозрачно, легко контролировать в Git | Нужно не забыть про обновления темы |
| Правило на сервере | Срабатывает раньше WordPress, меньше нагрузки | Зависит от доступа к конфигу веб-сервера |
| Плагин безопасности | Быстро включить без кода | Ещё один плагин в стеке, не всегда понятно, что именно он делает |
Вариант 1: отключить через PHP-код
Если вам нужен предсказуемый вариант без лишних плагинов, добавьте фильтр xmlrpc_enabled. Лучше класть такой код в mu-plugin или в небольшой сайт-специфичный плагин, а не в functions.php активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если вы используете mu-plugins, файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. Такой код не зависит от темы и не исчезнет после обновления.
Вариант 2: закрыть xmlrpc.php на уровне сервера
Если нужен более жёсткий вариант, можно блокировать сам файл на веб-сервере. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
Для Apache в .htaccess можно добавить:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. На Nginx это особенно важно: ошибка в блоке location может затронуть весь сайт, а не только XML-RPC.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, это допустимый вариант. Но здесь важно понимать, что именно делает плагин: блокирует доступ к файлу, отключает только pingback или меняет поведение частично. Смотрите документацию конкретного решения, а не только название переключателя в интерфейсе.
Если у вас уже используется набор для технической чистки сайта, например Clearfy Pro, проверьте, есть ли в нём отдельная настройка для XML-RPC и как она реализована. Это удобнее, чем держать ещё один отдельный плагин только ради одной функции.
Проверка результата после внедрения
После отключения не ограничивайтесь тем, что страница сайта открывается в браузере. Проверьте именно тот сценарий, который вы меняли.
- Откройте
/xmlrpc.phpв браузере — доступ должен быть закрыт или возвращать пустой ответ в зависимости от способа блокировки. - Повторите запрос через
curl -I https://example.com/xmlrpc.phpи посмотрите код ответа. - Проверьте логи веб-сервера: обращений к файлу должно стать меньше или они должны получать отказ.
- Если у вас есть мобильное приложение WordPress или внешняя публикация, протестируйте вход и отправку записи.
Для более точной проверки можно отправить тестовый XML-RPC-запрос и убедиться, что сервер его не принимает. Если вы блокировали файл на уровне сервера, ответ обычно приходит быстрее, чем при отключении только через WordPress-фильтр.
Частые ошибки и как их исправить
Отключили XML-RPC в теме, а потом сменили тему
Это типичная ошибка. Код в functions.php исчезает вместе с темой или перестаёт выполняться при переключении. Для таких задач используйте mu-plugin или отдельный мини-плагин.
Заблокировали файл, но забыли про зависимые сервисы
Если после отключения перестала работать публикация из внешнего клиента, значит, сервис использовал XML-RPC. В этом случае либо возвращайте доступ, либо переводите интеграцию на REST API, если она это поддерживает.
Сделали жёсткую блокировку и не проверили конфиг
На Apache и Nginx ошибка в правилах может привести к 500-й ошибке или к неработающему сайту. Перед применением на боевом домене проверьте конфигурацию на тестовой среде и сохраните резервную копию файла.
Ожидали, что отключение XML-RPC уберёт все атаки
Это не универсальная защита. Она убирает один канал, но не заменяет нормальную политику паролей, ограничение попыток входа, обновления ядра и плагинов, а также базовую защиту админки.
Что ещё стоит проверить для безопасности
Если вы уже занялись закрытием лишних точек входа, имеет смысл посмотреть и на соседние настройки. На практике полезно:
- ограничить попытки входа в админку;
- включить двухфакторную аутентификацию для администраторов;
- проверить, не открыт ли
/wp-json/шире, чем нужно; - убрать неиспользуемые плагины и темы;
- проверить права на файлы и доступ к
wp-config.php; - следить за логами 403/401/404, чтобы видеть повторяющиеся попытки сканирования.
Если нужен более широкий набор технической чистки сайта, удобнее один раз настроить системные ограничения и не возвращаться к ним после каждого обновления.
Короткий чек-лист перед отключением
- Проверили, используется ли мобильное приложение WordPress или внешний редактор.
- Посмотрели логи на обращения к
/xmlrpc.php. - Выбрали способ отключения: код, сервер или плагин.
- Сделали резервную копию конфигурации.
- После изменения протестировали доступ к
xmlrpc.phpи работу сайта.
Если задача решается на уровне сервера, это обычно самый чистый вариант. Если нужен быстрый и переносимый способ, достаточно фильтра xmlrpc_enabled. Главное — не смешивать подходы без необходимости и обязательно проверить, не сломались ли внешние сценарии публикации.