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

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

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

Когда XML-RPC реально мешает, а когда его трогать не стоит

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

Отключать XML-RPC имеет смысл, если:

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

Трогать его осторожно нужно, если сайт старый, есть удалённые редакторы, синхронизация с CRM или публикация через сторонние клиенты. В таких проектах лучше сначала проверить фактическое использование, а не опираться на предположение.

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

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

Если доступа к логам нет, проверьте поведение сайта вручную. Откройте https://example.com/xmlrpc.php в браузере. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не означает, что интерфейс нужен, но подтверждает, что файл доступен.

Для быстрой проверки интеграций полезен такой чек-лист:

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

Что выбрать: код, плагин или серверное правило

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

Подход	Плюсы	Минусы	Когда брать
Код в теме или мини-плагине	Просто откатить, не требует доступа к nginx/apache	Нужно следить, чтобы код не потерялся при смене темы	Если нужен управляемый вариант внутри WordPress
Плагин безопасности	Быстро включить, часто есть готовая настройка	Добавляет ещё один плагин, не всегда понятно, что именно он делает	Если нужен интерфейс без правки кода
Правило на сервере	Отсекает запросы раньше WordPress	Зависит от конфигурации хостинга, сложнее поддерживать	Если есть доступ к конфигу и нужен жёсткий запрет

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

Пошаговое решение через мини-плагин

Создайте файл wp-content/plugins/disable-xmlrpc/disable-xmlrpc.php и вставьте туда код ниже. Затем активируйте плагин в админке.

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Отключает XML-RPC для WordPress.
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_filter( 'xmlrpc_enabled', '__return_false' );

add_filter( 'wp_headers', function( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

add_filter( 'pings_open', '__return_false' );

Этот вариант отключает сам XML-RPC и убирает заголовок X-Pingback, который тоже часто оставляют без внимания. Для большинства сайтов этого достаточно.

Если нужно не просто выключить XML-RPC, а отдать на него 403 ещё до загрузки WordPress, используйте серверное правило. Для Apache это может выглядеть так:

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

Для nginx логика обычно строится через location:

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

Серверный вариант жёстче, но его нельзя включать, если вы не проверили зависимости. Иначе можно отрезать рабочую интеграцию без предупреждения.

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

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

curl -i -X POST https://example.com/xmlrpc.php

Ожидаемое поведение зависит от способа отключения:

• при отключении через xmlrpc_enabled WordPress должен не принимать XML-RPC-запросы;
• при серверном deny вы увидите 403 Forbidden;
• в логах больше не должно быть успешных обращений к /xmlrpc.php.

Дополнительно проверьте:

• мобильное приложение WordPress, если оно используется;
• внешнюю публикацию через сторонний сервис;
• отправку пингов и трекбеков, если они ещё нужны на сайте;
• нет ли новых ошибок в логах после отключения.

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

Отключили XML-RPC в теме, а потом сменили тему

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

Сломали мобильное приложение редакторов

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

Отключили только XML-RPC, но оставили X-Pingback

Это не критическая дыра, но лишний шум в заголовках и лишняя поверхность для сканеров. Убирайте и заголовок, и сам endpoint, если он вам не нужен.

Поставили плагин безопасности и не поняли, что именно он блокирует

У некоторых плагинов есть общий переключатель «защиты», который влияет не только на XML-RPC. После включения обязательно проверьте логи и функциональность сайта, а не ограничивайтесь галочкой в настройках.

Безопасность и производительность: что ещё имеет смысл сделать

Отключение XML-RPC — не замена нормальной защите, а один из слоёв. Если на сайт идут брутфорс-атаки, полезно дополнительно ограничить частоту запросов на уровне WAF или сервера. Если у вас есть доступ к Cloudflare или аналогичному фильтрующему слою, блокировка /xmlrpc.php там часто даёт лучший эффект, чем обработка запроса уже внутри WordPress.

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

Если нужен более широкий аудит технических дублей, служебных страниц и лишних точек входа, удобно сначала пройтись по сайту инструментами для чистки и SEO-оптимизации, а уже потом отключать отдельные интерфейсы. В экосистеме WPShop для этого есть Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Короткий рабочий порядок для админа

1. Проверьте логи и найдите обращения к /xmlrpc.php.
2. Уточните, не используют ли редакторы мобильное приложение или внешнюю публикацию.
3. Выберите способ отключения: мини-плагин, плагин безопасности или серверное правило.
4. Внедрите блокировку и уберите заголовок X-Pingback.
5. Проверьте POST-запрос через curl и убедитесь, что рабочие интеграции не сломались.

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