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

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

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

Когда XML-RPC действительно мешает

Если вы видите в логах частые обращения к /xmlrpc.php, это не всегда атака, но очень часто именно туда приходят переборы логинов и паролей. Для WordPress это неудобно по двум причинам: endpoint доступен публично, а ответы на некоторые запросы позволяют злоумышленнику автоматизировать проверку доступности сайта и учётных данных.

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

Быстрая диагностика

Перед отключением проверьте, есть ли у вас реальные зависимости:

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

Проверить наличие endpoint можно простым запросом:

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

Если сервер отвечает 200 или 405, endpoint доступен. Это ещё не значит, что он используется, но значит, что его можно атаковать и что его стоит оценить отдельно.

Как отключить XML-RPC: три рабочих подхода

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

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

Если вам нужен понятный и контролируемый способ, добавьте фильтр в mu-plugin или в плагин сайта. Так настройка не потеряется при смене темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Вариант 2: заблокировать xmlrpc.php на сервере

Если цель — не просто отключить функциональность, а ещё и снизить нагрузку от мусорных запросов, лучше резать их на уровне веб-сервера. Тогда запросы не дойдут до PHP.

Для nginx можно использовать отдельное правило:

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

Для Apache обычно используют правила в .htaccess:

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

Серверная блокировка особенно полезна на сайтах с высоким числом автоматических запросов. Но если у вас есть рабочая интеграция через XML-RPC, этот вариант сломает её сразу.

Вариант 3: отключить через плагин

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

Если у вас уже стоит плагин для технической чистки сайта, например Clearfy Pro, проверьте, нет ли там отдельной настройки для XML-RPC и других лишних сервисов WordPress. Это удобнее, чем держать несколько узких плагинов под одну задачу.

Пошаговая схема внедрения без сюрпризов

Не отключайте XML-RPC сразу на боевом сайте без проверки зависимостей. Лучше пройти короткий сценарий.

1. Сделайте резервную копию файлов и базы.
2. Проверьте, используете ли Jetpack, мобильные клиенты или внешние публикации.
3. Выберите способ отключения: код, сервер или плагин.
4. Внесите изменение сначала на staging, если он есть.
5. Проверьте, что /xmlrpc.php больше не отвечает как раньше.
6. Убедитесь, что вход в админку, REST API и публикация записей работают штатно.

Если нужен не полный запрет, а только защита

Иногда XML-RPC нужен для одного конкретного сервиса, и тогда полный запрет не подходит. В такой ситуации лучше ограничить доступ на уровне веб-сервера по IP или закрыть endpoint через WAF, а не ломать функциональность целиком. Это более точный вариант, но он требует дисциплины: список разрешённых адресов нужно поддерживать в актуальном состоянии.

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

После отключения проверьте не только сам endpoint, но и связанные сценарии. Это важнее, чем просто увидеть «403» в браузере.

• Откройте https://example.com/xmlrpc.php в браузере или через curl.
• Убедитесь, что ответ либо запрещён, либо не даёт использовать endpoint по назначению.
• Проверьте логи веб-сервера: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ без загрузки PHP.
• Если используете Jetpack, проверьте его статус подключения в админке WordPress.com/Jetpack.
• Если у вас есть внешняя публикация записей, протестируйте её отдельно.

Для быстрой проверки можно отправить тестовый POST-запрос:

curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/xmlrpc.php

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

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

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

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

Поставили плагин, но endpoint всё равно отвечает

Часто причина в том, что плагин только частично блокирует запросы, а на сервере есть кэш или другое правило, которое пропускает endpoint. Проверьте, не дублируется ли логика в .htaccess, nginx-конфиге и нескольких плагинах одновременно.

Сломали мобильную публикацию и не заметили сразу

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

Оставили endpoint открытым, но спрятали его только плагином

Плагин — не всегда плохой вариант, но он не заменяет серверную защиту. Если сайт регулярно получает мусорные запросы, лучше блокировать их раньше PHP, иначе вы всё равно тратите ресурсы на обработку.

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

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

Для более устойчивой конфигурации держите в порядке базовые вещи:

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

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

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