XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация, некоторые сервисы автопостинга или старые интеграции. Проблема не в самом отключении, а в том, что его делают без диагностики зависимостей. Если сайт давно живёт на плагинах, API и внешних сервисах, сначала нужно понять, кто вообще обращается к /xmlrpc.php.
Когда XML-RPC действительно стоит отключать
Если вы не используете внешнюю публикацию через WordPress.com, мобильное приложение WordPress и сторонние сервисы, которым нужен XML-RPC, этот интерфейс обычно можно закрыть. На практике его оставляют включённым по инерции, хотя для большинства сайтов он не нужен. Но если у вас есть интеграции старого типа, отключение без проверки приведёт к ошибкам на стороне клиента, а не в админке WordPress.
Что обычно ломается первым
- мобильное приложение WordPress не может авторизоваться;
- сервисы автопостинга получают 403 или 405;
- старые интеграции для удалённой публикации перестают создавать записи;
- некоторые плагины синхронизации продолжают пытаться стучаться в
xmlrpc.php, создавая шум в логах.
Диагностика: кто использует xmlrpc.php
Перед изменениями проверьте логи веб-сервера и плагины, которые могут работать через удалённую публикацию. Если доступа к логам нет, хотя бы откройте статистику запросов в панели хостинга или временно включите логирование 404/403 на уровне сервера. Ищите обращения именно к /xmlrpc.php, а не к REST API: это разные механизмы.
Полезно проверить и сам сайт на наличие явных зависимостей. В админке посмотрите список активных плагинов, которые связаны с публикацией по расписанию, внешними CMS, мобильными клиентами и синхронизацией контента. Если такой плагин есть, не отключайте XML-RPC до теста на staging-копии.
Быстрая проверка через запрос
curl -I https://example.com/xmlrpc.phpЕсли XML-RPC включён, сервер обычно отвечает не как на обычную HTML-страницу. Но сам по себе ответ ещё не говорит, что интеграции работают. Важно проверить именно сценарий использования, а не только доступность файла.
Сравнение подходов: плагин, код, сервер
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужно быстро закрыть доступ без правки темы | Просто включить, часто есть логика исключений | Лишняя зависимость, иногда закрывает больше, чем нужно |
| Код в functions.php или mu-plugin | Нужен контроль и предсказуемость | Не зависит от интерфейса плагина, легко ревертить | Нужно аккуратно тестировать на проде |
| .htaccess / nginx | Нужно отсечь запросы на уровне сервера | Ранний отказ, меньше нагрузки | Можно случайно задеть другие правила |
Если задача — именно отключить XML-RPC без побочных эффектов, чаще всего лучше начать с кода. Так проще понять, что именно меняется, и быстро вернуть всё назад, если обнаружится зависимость.
Пошаговое решение через код
Самый безопасный вариант — добавить небольшой mu-plugin. Он не зависит от темы и не потеряется при обновлении. Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.
<?php
/**
* Plugin Name: Disable XML-RPC
* Description: Отключает XML-RPC на сайте.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает сам механизм XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Если нужно не просто выключить функциональность, а ещё и отдавать более жёсткий ответ на запросы к файлу, можно добавить отдельный блок на уровне сервера или ранний отказ в PHP.
Дополнительная защита от прямого доступа
Если вы хотите, чтобы запросы к xmlrpc.php не доходили до ядра WordPress, используйте серверное правило. Для Apache это может выглядеть так:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx обычно делают отдельное правило в конфигурации виртуального хоста:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Не смешивайте оба подхода без необходимости. Если вы уже отключили XML-RPC в WordPress, серверное правило нужно только тогда, когда хотите сократить лишние обращения и шум в логах.
Как проверить, что решение сработало
Проверка должна быть не формальной, а прикладной. Сначала откройте https://example.com/xmlrpc.php в браузере или через curl. Затем проверьте реальные сценарии: мобильное приложение, внешний сервис публикации, интеграцию плагина, который раньше использовал XML-RPC. Если сайт отвечает ошибкой доступа, но интеграции продолжают работать через REST API, значит вы отключили именно старый канал, а не поломали весь удалённый доступ.
- проверить ответ
curl -Iна/xmlrpc.php; - посмотреть логи веб-сервера на повторные обращения;
- протестировать публикацию через все внешние сервисы, которые использовались раньше;
- убедиться, что админка WordPress открывается без ошибок;
- проверить, не появились ли новые 403/405 в логах после изменения.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив сторонние сервисы
Это самая частая ошибка. Если сервис автопостинга или мобильное приложение перестали работать, верните фильтр xmlrpc_enabled и сначала найдите, кто именно зависит от этого канала. Иногда проще перевести интеграцию на REST API, чем держать XML-RPC открытым.
Поставили плагин безопасности и не поняли, что он ещё отключил
Некоторые плагины закрывают XML-RPC вместе с другими функциями, например с REST API-ограничениями, защитой логина или заголовками безопасности. Если после установки появились побочные эффекты, временно отключите плагин и проверьте, какая именно опция вызвала проблему.
Заблокировали файл на сервере, но забыли про кэш
Если перед этим стоял кэш на уровне CDN или reverse proxy, запросы к /xmlrpc.php могут какое-то время отдавать старый ответ. Очистите кэш на всех уровнях: плагин кэша, серверный кэш, CDN. Иначе проверка покажет ложный результат.
Что делать с безопасностью и производительностью
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из лишних входов. Это полезно, если вы не используете старые интеграции. При этом не стоит считать, что после этого можно игнорировать защиту логина, обновления ядра и плагинов, а также контроль прав пользователей.
Если на сайте много технических дублей и мусорных функций, имеет смысл параллельно посмотреть на общую чистку. Для этого иногда используют Clearfy Pro: он помогает закрывать лишние точки входа, убирать дубли и наводить порядок в технических настройках WordPress. Но даже в таком случае сначала проверяйте, что именно включено, а не активируйте всё подряд.
Мини-чек-лист перед отключением
- проверены логи на обращения к
xmlrpc.php; - перечислены все внешние сервисы и плагины, которые публикуют контент удалённо;
- есть staging-копия или хотя бы план отката;
- понятно, где именно будет отключение: код, сервер или плагин;
- после изменения запланирована повторная проверка реальных сценариев.
Если нужен быстрый и управляемый вариант, начинайте с mu-plugin и только потом при необходимости переносите блокировку на серверный уровень. Так проще отследить, что именно изменилось, и не спутать отключение XML-RPC с проблемами кэша, прав доступа или сторонних интеграций.