XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack, внешние публикации и некоторые интеграции. Проблема не в самом XML-RPC, а в том, что его закрывают без проверки зависимостей. Ниже — рабочая схема: как понять, нужен ли он вообще, как отключить безопасно и как проверить, что сайт не потерял нужные функции.
Когда XML-RPC действительно стоит отключать
Если вы не используете старые внешние клиенты, удалённую публикацию и интеграции, завязанные на xmlrpc.php, то этот интерфейс чаще всего только расширяет поверхность атаки. На практике его отключают, когда сайт управляется через обычную админку, REST API и современные плагины, а мобильное приложение WordPress не используется.
Но есть важная оговорка: если на сайте подключён Jetpack, настроены внешние сервисы для публикации или синхронизации, сначала проверьте, не используют ли они XML-RPC. Иначе вы получите не «усиление безопасности», а сломанный рабочий процесс.
Диагностика: используется ли XML-RPC сейчас
Самый простой способ — проверить, отвечает ли файл /xmlrpc.php и есть ли в логах обращения к нему. Если у вас есть доступ к серверным логам, ищите регулярные POST-запросы к этому пути. Если доступа нет, можно проверить поведение снаружи.
curl -I https://example.com/xmlrpc.phpНормальный ответ сам по себе ещё не означает, что XML-RPC нужен. Важно посмотреть, нет ли ошибок в сервисах, которые его используют. Если Jetpack или другой плагин после отключения начинает ругаться на соединение с сайтом, значит, закрывать интерфейс полностью нельзя без замены сценария.
Что проверить перед отключением
- используется ли Jetpack и какие его модули включены;
- настроена ли публикация через внешние клиенты;
- есть ли интеграции с CRM, редакторами или мобильными приложениями;
- есть ли в логах частые обращения к
xmlrpc.php; - не завязаны ли на XML-RPC сторонние сервисы резервного копирования или мониторинга.
Как отключить XML-RPC безопасно
Есть три практических варианта: через плагин, через код и на уровне веб-сервера. Для большинства сайтов достаточно кода в functions.php дочерней темы или в небольшом mu-plugin. Если нужен быстрый и обратимый вариант, удобнее использовать плагин безопасности или оптимизации, который умеет отключать XML-RPC без ручных правок ядра.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро, без правки кода | Лишняя зависимость, не всегда понятно, что именно отключено |
| Код в теме / mu-plugin | Прозрачно, легко контролировать | Нужно аккуратно обновлять и не забыть про дочернюю тему |
| .htaccess / nginx | Режет запросы раньше PHP | Нужно понимать конфиг сервера, можно задеть другие правила |
Вариант через код
Если вам нужно именно отключить обработку XML-RPC, используйте фильтр xmlrpc_enabled. Это корректный способ для WordPress, и он не ломает остальную логику сайта.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите дополнительно закрыть сам файл от прямого доступа, можно отдать 403 на уровне веб-сервера. Для Apache это обычно делают через .htaccess, для nginx — в конфигурации виртуального хоста. Но сначала убедитесь, что вам не нужен этот endpoint для сервисов выше по списку.
Вариант через .htaccess
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант работает только на Apache и совместимых конфигурациях. Если у вас nginx, правило нужно писать в серверный блок, а не в .htaccess, потому что nginx его не читает.
Пошаговое решение без сюрпризов
- Проверьте, используется ли XML-RPC в Jetpack, мобильном приложении и внешних сервисах.
- Сделайте резервную копию конфигурации и, если есть возможность, базы данных.
- Отключите XML-RPC через фильтр
xmlrpc_enabledили серверное правило. - Проверьте, не появились ли ошибки в админке и в логах плагинов.
- Протестируйте все сценарии публикации и синхронизации, которые были подключены до изменения.
Если вы ведёте несколько сайтов, удобнее вынести отключение в маленький mu-plugin. Тогда правило не потеряется при смене темы и не зависит от конкретного шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужно убедиться, что endpoint действительно закрыт и что ничего важного не сломалось.
- Откройте
/xmlrpc.phpв браузере или черезcurl— доступ должен быть запрещён или обработан по вашему правилу. - Проверьте Jetpack и другие подключённые сервисы на ошибки синхронизации.
- Посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать ожидаемый отказ. - Сделайте тестовую публикацию тем способом, который использовался до отключения.
Если сайт работает через REST API, проверьте и его отдельно. XML-RPC и REST API — это разные механизмы, и отключение одного не должно влиять на другой.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив Jetpack
Это самая частая причина «внезапно сломалось всё». Jetpack может использовать XML-RPC для части функций. Если модуль нужен, не закрывайте endpoint полностью — сначала проверьте, можно ли перевести сценарий на другой способ связи или отказаться от конкретной функции.
Закрыли файл на сервере, но забыли про кеш
После изменения правил старые ответы могут продолжать отдаваться из кеша или CDN. Очистите серверный кеш, кеш плагина и, если он есть, кеш на стороне прокси или CDN. Иначе вы увидите старую картину и решите, что правило не работает.
Использовали неподходящий способ для своего сервера
.htaccess не работает на nginx. Если у вас другой стек, правило нужно переносить в конфиг веб-сервера или использовать фильтр WordPress. Это банальная ошибка, но именно из-за неё люди тратят время на «неработающий код».
Поставили плагин, который делает больше, чем нужно
Некоторые плагины безопасности отключают сразу несколько API и функций. Если задача точечная, лучше использовать минимальное решение. Это снижает риск побочных эффектов и упрощает поддержку.
Что делать, если XML-RPC нужен только частично
Иногда полностью отключать его нельзя, но и оставлять открытым без ограничений не хочется. В таком случае лучше не искать «магический» плагин, а ограничить доступ на уровне веб-сервера, WAF или правил безопасности хостинга. Если у вас есть возможность, можно дополнительно ограничить частоту запросов к xmlrpc.php и мониторить подозрительную активность в логах.
Для сайтов, где важна чистка лишних функций и уменьшение поверхности атаки, иногда удобнее использовать набор точечных настроек в одном инструменте, чем собирать это вручную из нескольких плагинов. Например, в Clearfy Pro есть функции для отключения лишнего и чистки WordPress, но применять такой инструмент стоит только если он реально закрывает ваши задачи, а не ради очередного плагина в списке.
Если вам нужно именно техническое снижение риска, а не косметическая «оптимизация», держите правило простым: отключайте только то, что вы проверили, и сразу тестируйте зависимые сценарии. В WordPress это почти всегда экономит больше времени, чем последующий разбор инцидента.