Как отключить XML-RPC API в WordPress без поломки внешних интеграций

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

Когда XML-RPC действительно стоит отключать

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

Что обычно ломается первым

Чаще всего проблемы проявляются не сразу, а в одном из таких сценариев:

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

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

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

Быстрая проверка через curl

Самый простой тест — посмотреть, отвечает ли endpoint вообще. На живом сайте без блокировок вы обычно увидите ответ WordPress, а не 404.

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

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

Проверка в логах

Ищите запросы к xmlrpc.php и смотрите User-Agent, IP и частоту. Если это бот-сканер, блокировка обычно безопасна. Если это ваш сервис публикации или приложение редактора, сначала переведите его на другой способ интеграции.

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

У каждого способа есть свой компромисс. Если нужен быстрый и обратимый вариант, лучше начать с кода или плагина. Если нужен жёсткий запрет на уровне сервера, используйте правила веб-сервера или WAF.

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

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

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

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

Вариант 2: блокировка на уровне веб-сервера

Если цель — уменьшить нагрузку и убрать лишние обращения ещё до загрузки WordPress, можно закрыть xmlrpc.php в конфигурации сервера. Для Apache обычно используют правило в .htaccess:

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

Для Nginx логика похожая, но правило пишется в конфиге виртуального хоста. Смысл один: запросы к файлу должны отрезаться до PHP. Это полезно на сайтах, где XML-RPC точно не нужен и есть поток ботов.

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

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

Пошаговое решение без поломки интеграций

1. Составьте список сервисов, которые публикуют или синхронизируют контент с сайтом.
2. Проверьте, используют ли они XML-RPC или REST API.
3. Если XML-RPC нужен хотя бы одному рабочему сценарию, не отключайте его глобально.
4. Если не нужен, сначала включите блокировку через код или плагин, а не на уровне сервера.
5. После этого проверьте доступ к xmlrpc.php и логи ошибок.

Если нужен только один сервис

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

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

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

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

Мини-тест через WP-CLI

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

wp option get siteurl
wp plugin status

Это не заменяет проверку интеграций, но помогает отсеять грубые ошибки после внесения правок в код или конфиг.

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

Отключили XML-RPC, не проверив мобильные приложения

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

Поставили блокировку в теме вместо mu-plugin

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

Закрыли файл на сервере, но забыли про внешние сервисы

Жёсткая блокировка на уровне Apache или Nginx хороша только тогда, когда вы уверены в сценариях использования. Иначе получите тихую поломку автопостинга или синхронизации, которую заметите слишком поздно.

Смешали XML-RPC и REST API

Это разные механизмы. Отключение XML-RPC не должно влиять на REST API, но на практике администраторы иногда путают их и начинают искать проблему не там. Если сломались интеграции на REST, причина не в xmlrpc.php.

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

Если сайт регулярно атакуют на xmlrpc.php, блокировка даёт не только безопасность, но и экономию ресурсов: меньше бесполезных PHP-запросов, меньше шума в логах, меньше нагрузки на авторизацию. Но не стоит считать это полноценной защитой от всех атак. Пароли, 2FA, ограничение попыток входа и обновления ядра остаются обязательными.

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

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