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

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

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

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

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

Отключать его имеет смысл, если:

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

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

Диагностика: используется ли XML-RPC на вашем сайте

Самый практичный способ — посмотреть логи доступа и поискать обращения к xmlrpc.php. Если у вас есть доступ к nginx/apache логам или панели хостинга, это быстрее всего. Для сайтов с высокой нагрузкой полезно проверить и плагины, которые могут использовать удалённую публикацию.

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

В access-логах обычно видны POST-запросы к /xmlrpc.php. Если запросы идут регулярно и с разных IP, это может быть как легитимный клиент, так и попытка подбора пароля. Если запросов нет совсем, а интеграции не жалуются, отключение обычно проходит безболезненно.

Пример для grep по логам:

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

Если у вас нет доступа к серверу, можно временно включить логирование на уровне WAF или посмотреть статистику в панели хостинга. Иногда достаточно открыть отчёт по URL и убедиться, что /xmlrpc.php не используется.

Как отключить XML-RPC: сравнение подходов

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

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

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

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

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

Пример мини-плагина:

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

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

Вариант для nginx

На nginx можно отдать запрет ещё до загрузки WordPress:

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

Это хороший вариант, если вы хотите снизить лишнюю нагрузку и не пускать запросы в PHP. Для Apache логика похожая, но настраивается через правила доступа в конфиге или .htaccess, если хостинг это позволяет.

Что проверить после отключения

После внедрения не ограничивайтесь тем, что «сайт открылся». Нужно проверить именно те сценарии, которые XML-RPC мог обслуживать.

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

Команда для быстрой проверки ответа сервера:

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

Если вы отключали через фильтр, обычно увидите отказ или пустой ответ в зависимости от конфигурации. Если закрывали на уровне nginx, должен приходить 403 Forbidden.

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

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

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

Поставили плагин, но запросы всё равно проходят

Так бывает, если плагин только «маскирует» XML-RPC, но не режет его полностью, или если у вас есть кеширующий/защитный слой, который не применяет правило к /xmlrpc.php. В таком случае лучше использовать фильтр WordPress или серверный запрет.

Закрыли файл, но не проверили логи

Иногда после отключения начинается шквал 403-запросов от ботов. Это не критично, но лучше убедиться, что WAF или rate limiting не создают лишнюю нагрузку на журналирование. Если атака идёт массово, полезно дополнительно ограничить частоту запросов на уровне сервера или CDN.

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

Отключение XML-RPC само по себе не заменяет нормальную защиту входа. Если цель — снизить риск брутфорса, параллельно проверьте:

• есть ли ограничение попыток входа;
• включена ли двухфакторная аутентификация для админов;
• не открыт ли wp-login.php без ограничений;
• не используются ли слабые пароли у редакторов и администраторов;
• нет ли лишних пользователей с правами выше нужного.

Если на сайте уже стоит набор для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не дублирует ли он ваши правила безопасности. Дублирующие настройки в разных местах часто мешают отладке: потом трудно понять, что именно закрыло доступ.

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

Итог считается успешным, если выполняются три условия: /xmlrpc.php недоступен или возвращает отказ, внешние зависимости не сломались, а в логах нет ошибок PHP, связанных с XML-RPC. Если после отключения сайт ведёт себя как раньше, а лишние запросы перестали доходить до ядра, значит задача решена правильно.

Для контроля можно оставить проверку в мониторинге: периодически запрашивать /xmlrpc.php и фиксировать код ответа. Это полезно, если на сайт часто лезут боты и вы хотите видеть, не «открылось» ли что-то после обновления плагинов, темы или правил на сервере.