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

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

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

Когда XML-RPC реально нужен

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

Типичные признаки, что XML-RPC ещё нужен

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

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

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

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

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

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

Пошаговое решение: как отключить XML-RPC без лишнего риска

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

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

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

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

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

Вариант 2: закрыть xmlrpc.php на уровне Nginx

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

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

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

Вариант 3: использовать плагин безопасности

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

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

Как не сломать Jetpack и мобильное приложение

Главная ошибка — отключить XML-RPC, не проверив, какие функции реально используются. Jetpack может работать частично: часть модулей будет доступна, а часть — нет. Мобильное приложение WordPress тоже может потерять возможность публиковать записи или синхронизировать изменения.

Перед отключением сделайте короткий чек-лист:

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

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

После отключения нужно убедиться, что всё работает так, как вы ожидали. Проверка должна быть не только технической, но и прикладной.

Что проверить вручную

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

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

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

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

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

Отключили XML-RPC, а потом пропала публикация из Jetpack

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

Добавили правило в Nginx, но запросы всё равно идут

Часто правило добавляют не в тот server-блок или забывают перезагрузить конфигурацию. Проверьте, что правило действительно попало в активный виртуальный хост, а затем выполните проверку конфигурации и reload.

Отключили через плагин, но сайт всё равно отвечает на xmlrpc.php

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

Сломали отладку, потому что не сохранили исходное состояние

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

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

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

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

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

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