XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, публикация из мобильного приложения или внешние сервисы, которые подключаются к сайту по старому протоколу. Если задача не в полном отказе от интеграций, а в снижении риска и лишнего шума, отключать XML-RPC нужно осознанно: сначала понять, кто его использует, потом выбрать способ блокировки.
Ниже разберём рабочую схему: как диагностировать зависимость, как отключить XML-RPC на уровне WordPress или сервера, как проверить результат и какие ошибки чаще всего ломают интеграции.
Когда XML-RPC действительно стоит отключать
XML-RPC — это не «фича для SEO», а старый интерфейс удалённого доступа. Через него WordPress может принимать запросы от внешних клиентов, например от мобильного приложения, Jetpack, некоторых планировщиков публикаций и сервисов автопостинга. Проблема в том, что этот же endpoint часто используют для перебора паролей и лишней нагрузки на сайт.
Отключение имеет смысл, если:
- вы не публикуете записи из мобильного приложения WordPress;
- не используете Jetpack или уже перевели его на другие сценарии;
- нет внешних сервисов, которым нужен XML-RPC;
- на сайте регулярно видны запросы к
/xmlrpc.phpв логах.
Если хотя бы один сервис зависит от XML-RPC, лучше не рубить его полностью, а ограничить доступ точечно или заменить интеграцию.
Диагностика: кто вообще обращается к xmlrpc.php
Перед изменениями проверьте, есть ли реальные обращения к endpoint. Это можно сделать по логам веб-сервера, по статистике в панели хостинга или через инструменты мониторинга. Важно смотреть не только факт запросов, но и их источник: иногда это бот, иногда — ваш же сервис.
Что искать в логах
Если у вас есть доступ к access log, запросы к XML-RPC обычно выглядят так:
POST /xmlrpc.php HTTP/1.1Полезно посмотреть частоту, IP-адреса и коды ответа. Если видите много повторяющихся POST-запросов с одинаковых адресов, это уже повод ограничить endpoint. Если запросы идут с IP Jetpack, мобильного приложения или внешнего сервиса публикации, сначала проверьте, можно ли перевести их на другой способ подключения.
Проверка зависимостей в админке
Перед отключением пройдитесь по списку подключений:
- Jetpack и его модули;
- мобильное приложение WordPress;
- сервисы автопостинга и кросспостинга;
- старые плагины синхронизации контента;
- внешние CRM, если они публикуют записи через XML-RPC.
Если сайт обслуживает несколько редакторов, лучше заранее предупредить, что публикация через приложение может перестать работать.
Как отключить XML-RPC: три рабочих варианта
Универсального способа нет. Выбор зависит от того, нужен ли вам полный запрет или достаточно закрыть доступ на уровне WordPress.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужно быстро и без кода | Просто включить и откатить | Добавляет ещё один слой логики |
| Код в теме или mu-plugin | Есть доступ к коду и нужен контроль | Не зависит от стороннего плагина | Нужно аккуратно обновлять |
| Блокировка на сервере | Нужен жёсткий запрет до WordPress | Снимает нагрузку раньше PHP | Требует доступа к конфигу сервера |
Вариант 1. Отключить через код
Если нужен простой и понятный способ, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Для полного отключения XML-RPC в WordPress используйте фильтр xmlrpc_enabled:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм внутри WordPress, но не всегда убирает сам файл xmlrpc.php из доступа на уровне веб-сервера. Обычно этого достаточно, чтобы запросы перестали обрабатываться, но если цель — сократить лишние обращения ещё до загрузки WordPress, лучше добавить серверную блокировку.
Вариант 2. Закрыть доступ через сервер
Если сайт работает на Apache, можно запретить доступ к файлу xmlrpc.php через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>На Nginx логика будет другой: правило добавляют в конфигурацию сайта. Пример:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверная блокировка полезна тем, что запросы не доходят до WordPress и не тратят PHP-ресурсы. Но если у вас есть легитимный клиент, он тоже перестанет работать сразу.
Вариант 3. Использовать плагин для точечного контроля
Если не хочется лезть в код, можно использовать плагин, который отключает XML-RPC или ограничивает связанные с ним функции. Такой подход удобен на проектах, где админка ведётся не разработчиком. Но важно проверить, что плагин не конфликтует с другими мерами безопасности и не блокирует нужные интеграции без предупреждения.
Если у вас уже стоит набор для технической чистки сайта, например Clearfy Pro, проверьте, нет ли в нём отдельной опции для отключения XML-RPC и связанных с ним поверхностей. Важно не включать сразу несколько плагинов, которые делают одно и то же: потом сложно понять, что именно сломало интеграцию.
Пошаговая схема внедрения без сюрпризов
- Сначала проверьте, кто использует XML-RPC: логи, Jetpack, мобильные приложения, внешние сервисы.
- Выберите способ отключения: код, сервер или плагин.
- Сделайте бэкап конфигурации и файлов, если правите
.htaccessили конфиг Nginx. - Внедрите одно изменение, а не несколько сразу.
- Проверьте, что
/xmlrpc.phpбольше не отвечает как раньше. - Протестируйте все интеграции, которые могли использовать этот endpoint.
Если сайт рабочий и на нём есть редакторы, лучше сначала отключить XML-RPC на тестовой копии. Это особенно важно, если вы не уверены, как именно подключён Jetpack или сторонний сервис.
Как проверить, что отключение сработало
Проверка должна быть не «страница открывается», а именно по поведению endpoint. Есть несколько быстрых тестов.
Проверка через браузер или curl
Откройте https://ваш-домен/xmlrpc.php. В норме после блокировки вы должны увидеть отказ в доступе, пустой ответ или сообщение о запрете, в зависимости от способа отключения. Но для точной проверки лучше использовать POST-запрос:
curl -i -X POST https://example.com/xmlrpc.phpЕсли блокировка работает, вы не должны получать обычный ответ WordPress на XML-RPC-запрос. При серверной блокировке часто будет 403 Forbidden. При отключении через фильтр WordPress может вернуть другой код или сообщение об ошибке, но сам сервис уже не должен принимать XML-RPC-команды.
Проверка зависимых сервисов
После изменения обязательно проверьте:
- публикацию из мобильного приложения WordPress;
- подключение Jetpack;
- автопостинг в сторонних сервисах;
- синхронизацию с внешней системой, если она есть;
- формы и REST API — они не должны пострадать, если вы блокировали только XML-RPC.
Если что-то перестало работать, не откатывайте всё сразу. Сначала выясните, действительно ли сервис использовал XML-RPC, а не другой канал связи.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Это ожидаемое поведение. Решение простое: либо вернуть XML-RPC, либо отказаться от Jetpack в этом сценарии, либо перевести нужную функцию на другой механизм. Не стоит держать одновременно несколько конфликтующих ограничений и надеяться, что плагин «как-нибудь обойдёт» блокировку.
Поставили плагин, а endpoint всё равно отвечает
Некоторые плагины отключают только обработку XML-RPC внутри WordPress, но не закрывают сам файл на сервере. В логах запросы будут продолжать появляться, просто WordPress их не обработает. Если цель — снизить нагрузку и шум, добавьте серверное правило.
Сломали .htaccess и получили 500 ошибку
Чаще всего это происходит из-за неверного синтаксиса или вставки правила не в тот блок. Если сайт на Apache, проверяйте конфиг аккуратно: один лишний символ в .htaccess может положить весь сайт. Сначала сохраните копию файла, потом вносите правку.
Отключили не только XML-RPC, но и нужные REST-интеграции
Это типичная путаница. XML-RPC и REST API — разные механизмы. Если после правок перестали работать мобильные приложения или внешние сервисы, проверьте, что вы не блокировали лишнее правило в nginx, WAF или плагине безопасности.
Что делать, если XML-RPC нужен частично
Иногда полный запрет не подходит. Например, Jetpack нужен только для статистики, а мобильная публикация не используется. В таком случае лучше не отключать всё подряд, а посмотреть, можно ли ограничить доступ на уровне сервера по IP или по конкретным сценариям. Но такие схемы требуют поддержки и регулярной проверки: IP сервисов меняются, а правила быстро устаревают.
Если задача именно в технической чистке сайта, а не в точечной интеграции, часто разумнее отключить XML-RPC полностью и перевести рабочие процессы на REST API или штатные инструменты WordPress. Это проще сопровождать и легче объяснить редакторам.
Практика безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа в админку, лимиты на попытки авторизации и обновления ядра, тем. Но это полезный шаг, если endpoint не нужен. Он убирает лишнюю поверхность атаки и может снизить количество бесполезных запросов к сайту.
На нагруженных проектах серверная блокировка обычно предпочтительнее: она отсекает мусор до запуска PHP. На небольших сайтах достаточно фильтра xmlrpc_enabled, если вы хотите быстро и безопасно проверить эффект. Главное — не смешивать сразу несколько методов без необходимости.
Если нужен более широкий набор настроек для технической чистки WordPress, имеет смысл смотреть в сторону инструментов, которые позволяют управлять дублями, служебными поверхностями и лишними запросами из одной панели. Но даже в этом случае проверка после внедрения остаётся обязательной: отключение XML-RPC — это не «включил и забыл», а изменение, которое должно быть подтверждено тестом и логами.