XML-RPC в WordPress давно стал лишней точкой входа для большинства сайтов, но отключать его «в лоб» опасно, если у вас подключены мобильное приложение, внешние публикации или старые интеграции. На практике задача не в том, чтобы просто закрыть файл xmlrpc.php, а в том, чтобы убрать ненужный канал и не сломать то, что реально используется.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вам, как отключить его через код или плагин, что проверить после внедрения и какие ошибки чаще всего всплывают на продакшене.
Когда XML-RPC можно отключать без риска
Если сайт живёт на обычной админке WordPress, а публикации, комментарии и интеграции идут через браузер, XML-RPC чаще всего не нужен. Его исторически использовали для удалённой публикации, pingback'ов и некоторых старых клиентов. Сейчас часть этих задач закрывает REST API, а часть — вообще не используется.
Отключение обычно безопасно, если у вас нет:
- старого мобильного приложения WordPress, которое публикует записи через XML-RPC;
- внешних сервисов, которые отправляют посты через XML-RPC, а не через REST API;
- наследуемых интеграций с Jetpack или другими решениями, где часть функций завязана на XML-RPC;
- нужды в pingback/trackback, которые на большинстве сайтов только создают шум и спам.
Что именно ломается, если отключить слишком рано
Самый частый сценарий — владелец сайта закрывает xmlrpc.php на уровне сервера, а потом обнаруживает, что перестала работать синхронизация с внешним сервисом или публикация из старого клиента. REST API при этом может быть полностью исправен, но это не поможет, если интеграция ходит именно в XML-RPC.
Поэтому сначала нужно не «рубить», а проверить, кто обращается к этому endpoint'у и нужен ли он вообще.
Диагностика: как понять, используется ли XML-RPC
Начните с логов веб-сервера. Если сайт на Nginx или Apache, в access log обычно видно обращения к /xmlrpc.php. Если запросы идут регулярно и не похожи на случайный шум, стоит выяснить источник.
Пример поиска по логам:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас есть доступ только к панели хостинга, ищите в статистике запросов или журнале ошибок упоминания xmlrpc.php. Отдельно полезно проверить, не использует ли сайт Jetpack, мобильное приложение WordPress или сторонний сервис автопостинга.
Ещё один практический тест — открыть https://example.com/xmlrpc.php в браузере. Если XML-RPC включён, WordPress обычно отвечает сообщением о том, что доступ разрешён только через POST-запросы. Это не доказывает, что функция нужна, но подтверждает, что endpoint доступен извне.
Как отключить XML-RPC: сравнение подходов
Есть три нормальных способа: через код, через плагин безопасности или на уровне сервера. Выбор зависит от того, кто управляет сайтом и насколько вам важна переносимость настройки между окружениями.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Контроль, не зависит от интерфейса плагина | Нужно не забыть про деплой | Если есть доступ к коду и нужен предсказуемый результат |
| Плагин безопасности | Быстро включить, без правки файлов | Дополнительная зависимость | Если сайт ведётся без разработки |
| Блокировка на сервере | Срабатывает раньше WordPress | Можно случайно перекрыть нужные интеграции | Если нужен жёсткий запрет и вы уверены, что XML-RPC не используется |
Вариант 1: отключение через код
Самый прозрачный способ — добавить фильтр xmlrpc_enabled. Это не ломает REST API и отключает именно XML-RPC внутри WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Куда вставлять:
- в
mu-plugins, если нужно принудительное правило для всех окружений; - в плагин сайта, если у вас есть собственный набор технических настроек;
- в
functions.phpтемы — только если вы понимаете, что при смене темы правило исчезнет.
Если хотите отключить не только XML-RPC, но и pingback-заголовки, можно дополнительно убрать соответствующий header:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
if ( isset( $headers['X-Pingback'] ) ) {
unset( $headers['X-Pingback'] );
}
return $headers;
} );Вариант 2: через плагин
Если код на сайте не ведётся централизованно, проще использовать плагин безопасности, где есть отдельная настройка для отключения XML-RPC. Это удобно для администраторов без доступа к репозиторию, но настройку нужно документировать: иначе через полгода никто не вспомнит, почему интеграция перестала отвечать.
Плюс плагина — быстрое включение и отключение. Минус — лишний слой логики. Если у вас уже стоит комплексный плагин для технической чистки сайта, проверьте, не дублирует ли он эту функцию, чтобы не держать две одинаковые настройки одновременно.
Вариант 3: блокировка на сервере
Если XML-RPC точно не нужен, можно закрыть доступ на уровне веб-сервера. Это полезно против лишнего трафика и брутфорса, потому что запросы даже не доходят до WordPress.
Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache в .htaccess можно использовать правило доступа, но здесь важно не сломать общий конфиг сайта и не конфликтовать с другими правилами безопасности. Если вы не уверены в порядке обработки директив, безопаснее ограничиться фильтром WordPress или плагином.
Пошаговое решение без сюрпризов
- Проверьте логи и список интеграций: есть ли обращения к
xmlrpc.php. - Сделайте бэкап или хотя бы сохраните текущий конфиг, если меняете серверные правила.
- Отключите XML-RPC через
xmlrpc_enabledили настройку плагина. - Если нужно, закройте endpoint на уровне Nginx/Apache.
- Проверьте, что REST API и обычная авторизация в админке работают как раньше.
- Наблюдайте логи 1–2 дня: нет ли ошибок от внешних сервисов.
Если сайт работает в нескольких окружениях, лучше хранить правило в коде, а не в ручной настройке панели. Так вы не получите ситуацию, когда на staging XML-RPC выключен, а на production — нет.
Как проверить, что решение сработало
После внедрения нужно проверить не только факт блокировки, но и побочные эффекты. Самый простой тест — открыть /xmlrpc.php в браузере или отправить POST-запрос. При корректном отключении WordPress не должен принимать XML-RPC-вызовы.
Проверка через curl:
curl -i https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки:
- при отключении через WordPress может вернуться стандартный ответ без возможности вызова методов;
- при блокировке на сервере часто будет
403 Forbidden; - если endpoint всё ещё доступен, значит правило не применилось или его перекрывает другой конфиг.
Отдельно проверьте:
- вход в админку WordPress;
- публикацию и обновление записей;
- работу REST API, если сайт использует Gutenberg, мобильные клиенты или внешние сервисы;
- отправку форм, если они завязаны на сторонние интеграции.
Частые ошибки и как их исправить
Закрыли не XML-RPC, а весь REST API
Иногда в попытке усилить безопасность администратор отключает лишнее через плагин или серверные правила и случайно ломает /wp-json/. Это уже другая система, и её нельзя отключать без проверки зависимостей. Если редактор блоков, мобильное приложение или интеграции работают через REST API, сайт начнёт вести себя как «поломанный», хотя проблема будет не в XML-RPC.
Сломали интеграцию, которая была неочевидной
Некоторые сервисы продолжают использовать XML-RPC по старой схеме. Если после отключения перестала публиковаться запись из внешней системы, ищите в настройках этого сервиса упоминание XML-RPC, а не REST API. В таких случаях лучше сначала перевести интеграцию на современный способ, а уже потом закрывать endpoint.
Оставили дублирующую защиту
Если XML-RPC отключён и в WordPress, и на сервере, и ещё в плагине, потом трудно понять, что именно сломало запрос. Для поддержки это плохой сценарий: одна настройка должна отвечать за одно действие. Если используете код, зафиксируйте это в документации проекта.
Забыли про pingback'и
Даже если XML-RPC закрыт, заголовок X-Pingback может оставаться в ответах, а это лишний сигнал для сканеров. Если вы сознательно убираете этот канал, проверьте и заголовки, и доступ к endpoint'у.
Практические советы по безопасности и производительности
Отключение XML-RPC не делает сайт «защищённым полностью», но убирает популярную точку для перебора паролей и лишний шум в логах. Это особенно полезно на сайтах, где нет нужды в удалённой публикации.
- Не закрывайте всё подряд без проверки интеграций.
- Если нужен жёсткий запрет, лучше блокировать endpoint на сервере, а не только в интерфейсе WordPress.
- Держите правило в коде проекта, если сайт проходит через деплой.
- После изменений смотрите access log: это самый честный способ понять, что реально происходит.
Если вам нужен более широкий набор технических настроек для WordPress — от удаления дублей до чистки служебных элементов — такие задачи обычно удобнее решать централизованно, а не набором разрозненных правок. В этом сценарии полезно держать под рукой инструменты уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Если после отключения XML-RPC у вас остаются сомнения, проверьте проект в двух режимах: обычный пользовательский сценарий и сценарий внешней интеграции. Только так видно, что вы закрыли именно ненужный канал, а не сломали рабочий.