Как отключить XML-RPC в WordPress без поломки приложений и интеграций

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

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

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

Если сайт не использует удалённую публикацию, Jetpack-синхронизацию через XML-RPC, старые мобильные клиенты или внешние сервисы, которые до сих пор завязаны на этот endpoint, файл xmlrpc.php обычно только создаёт лишнюю поверхность атаки. На практике его часто оставляют включённым по инерции, хотя для обычной админской работы он не нужен.

Но есть важная оговорка: отключать XML-RPC «вслепую» нельзя, если у вас уже подключены сервисы, которые работают именно через него. Типичный пример — старый клиент для публикации постов, интеграция с мониторингом или плагин, который не переведён на REST API.

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

Перед изменениями посмотрите логи веб-сервера. Это самый надёжный способ понять, есть ли реальные запросы к XML-RPC и откуда они идут. Если логов нет, сначала включите их на стороне nginx или Apache, а уже потом принимайте решение.

Что искать в логах

• частые POST-запросы к /xmlrpc.php;
• повторяющиеся запросы с одного IP;
• обращения от известных сервисов, которые вы используете;
• ошибки 200/403/404 в зависимости от текущей конфигурации.

Пример для nginx access log:

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если у вас Apache, принцип тот же — ищите строки с xmlrpc.php в access log. Важно не только наличие запросов, но и их источник. Если это ваш же сервис резервного копирования или мобильное приложение редакции, полный запрет может оказаться лишним.

Пошаговое отключение XML-RPC

Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, нужен ли вам гибкий контроль или достаточно жёстко закрыть endpoint.

Вариант 1: отключить через код

Если вам нужно просто запретить работу XML-RPC на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin.

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

Это самый прямой способ: WordPress перестанет принимать XML-RPC-запросы, но сам файл xmlrpc.php физически останется доступен. Для большинства сайтов этого достаточно.

Вариант 2: закрыть доступ на уровне nginx

Если вы хотите отрубить endpoint ещё до загрузки WordPress, можно вернуть 403 на стороне nginx:

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

Этот вариант полезен, когда вы точно уверены, что XML-RPC не нужен вообще. Но если позже выяснится, что один из сервисов всё-таки его использует, придётся менять конфиг и перезагружать веб-сервер.

Вариант 3: точечная блокировка через .htaccess

Для Apache можно добавить правило в .htaccess:

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

Это рабочее решение, если у вас нет доступа к конфигу виртуального хоста. Но если сайт работает на nginx, этот фрагмент не поможет: там нужно править серверный конфиг.

Если XML-RPC нужен только для одного сервиса

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

Для таких случаев полезно не смешивать задачу «закрыть лишнее» и «не сломать рабочее». Если endpoint нужен хотя бы одному сервису, полная блокировка — плохая идея. Сначала миграция, потом отключение.

Проверка результата после внедрения

После изменения конфигурации проверьте не только страницу в браузере, но и сам endpoint. Обычная загрузка сайта не покажет, что xmlrpc.php всё ещё отвечает.

• Откройте /xmlrpc.php в браузере — в идеале должен быть отказ в доступе или пустой ответ в зависимости от способа блокировки.
• Проверьте POST-запросом через curl, что endpoint не принимает методы XML-RPC.
• Посмотрите логи после теста: не должно быть успешных обращений к endpoint от неизвестных источников.

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

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

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

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

Отключили XML-RPC, а потом перестал работать Jetpack

Значит, у вас был активный сценарий, который использовал именно XML-RPC. Решение простое: либо вернуть endpoint, либо перевести интеграцию на другой механизм, если он поддерживается. Не стоит держать блокировку и надеяться, что сервис «как-нибудь сам адаптируется».

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

Если правка была в functions.php родительской темы, она легко теряется при смене темы или при неаккуратном обновлении. Для таких задач лучше использовать mu-plugin: он не зависит от активной темы и не исчезает при обновлениях.

Закрыли файл на сервере, но WordPress всё ещё отвечает

Проверьте, что правило добавлено именно в активный серверный конфиг. На nginx это не .htaccess, а конфигурация виртуального хоста. На Apache убедитесь, что модуль mod_authz_core активен и директива действительно применяется к нужному каталогу.

Поставили плагин, а он конфликтует с другой защитой

Если у вас уже есть плагин безопасности, который тоже управляет XML-RPC, не дублируйте логику в двух местах. Иначе потом сложно понять, что именно блокирует запросы и почему endpoint ведёт себя нестабильно.

Что проверить после отключения, кроме самого xmlrpc.php

Иногда проблема не в самом endpoint, а в сопутствующих сценариях. После отключения проверьте:

• публикацию из мобильного приложения WordPress, если вы им пользуетесь;
• синхронизацию с внешними сервисами;
• работу резервного копирования, если оно завязано на старые методы доступа;
• ошибки в логах веб-сервера и PHP-логе;
• нет ли всплеска 403/404 на /xmlrpc.php от легитимных клиентов.

Если вы хотите не только закрыть XML-RPC, но и почистить сайт от лишних технических хвостов, удобно делать это в одном проходе: проверять дубли, отключать ненужные endpoints и смотреть, что реально используется. Для этого иногда используют наборы оптимизационных плагинов вроде Clearfy Pro, но сам принцип остаётся тем же: сначала диагностика, потом точечное отключение, затем проверка факта, а не предположений.

В итоге безопасная схема выглядит так: сначала смотрим логи, потом выбираем уровень блокировки, затем тестируем конкретный endpoint и только после этого считаем задачу закрытой. Если у вас есть хотя бы один сервис, завязанный на XML-RPC, не отключайте его без плана замены.