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

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

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

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

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

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

Сценарии, где отключение обычно безопасно

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

Сценарии, где сначала нужна проверка

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

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

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

Пример поиска по access log:

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

Если используется Apache, путь к логам может отличаться, но логика та же: ищите запросы к xmlrpc.php, частоту, IP и user-agent. Отдельно смотрите, нет ли всплесков с одинаковыми параметрами POST — это часто признак перебора или ботов.

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

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

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

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

Самый понятный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так код не потеряется при обновлении темы.

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

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

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

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

Для Nginx:

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

Для Apache можно использовать правило в .htaccess, если сервер это позволяет:

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

Этот вариант стоит применять только тогда, когда вы точно понимаете последствия. Если позже понадобится Jetpack или старый клиент, придётся возвращать доступ на сервере.

Вариант 3: точечная защита вместо полного отключения

Иногда XML-RPC нужен, но только для одного сервиса. Тогда лучше не выключать его полностью, а ограничить доступ по IP или защитить внешним уровнем, например через WAF или правила хостинга. Это уже не задача WordPress как такового, но для некоторых проектов это единственный безопасный компромисс.

Пошаговое решение без лишнего риска

1. Проверьте, используется ли Jetpack, мобильное приложение WordPress или старые интеграции.
2. Посмотрите access log и убедитесь, что обращения к xmlrpc.php не идут от легитимных сервисов.
3. Сделайте бэкап файлов и базы перед изменениями.
4. Выберите способ отключения: фильтр WordPress, серверное правило или ограничение доступа.
5. После внедрения проверьте, что сайт открывается, вход в админку работает, а нужные интеграции не сломались.

Если вы работаете через Git или деплой, лучше вынести решение в отдельный mu-plugin. Это уменьшает шанс случайно потерять правку при обновлении темы.

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

Такой файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. WordPress подхватит его автоматически, без активации в админке.

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере: в зависимости от конфигурации вы увидите либо сообщение о том, что XML-RPC сервер принимает только POST-запросы, либо отказ в доступе, если блокировка сделана на уровне сервера. Это ещё не финальная проверка, но уже полезный сигнал.

Дальше проверьте POST-запрос тестом через curl:

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

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

После этого проверьте прикладные сценарии:

• вход в админку через /wp-admin/;
• публикация и редактирование записей;
• работу Jetpack, если он установлен;
• мобильное приложение WordPress, если оно используется;
• внешние сервисы, которые отправляют контент на сайт.

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

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

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

Закрыли xmlrpc.php на сервере, но забыли про тестовую копию

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

Сделали правку в теме, а потом потеряли её после обновления

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

Проверили только браузером и решили, что всё закрыто

Браузерный запрос к xmlrpc.php не показывает реальную картину. Нужен именно POST-запрос и, желательно, проверка логов. Иначе можно пропустить ситуацию, когда endpoint доступен и продолжает принимать обращения.

Что ещё стоит сделать для безопасности и производительности

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

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

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