XML-RPC в WordPress часто отключают целиком, но на практике это не всегда лучший вариант. Проблема обычно не в самом файле xmlrpc.php, а в отдельных методах, которые используются для удалённой публикации, пинга и интеграций. Если у сайта есть Jetpack, мобильное приложение WordPress или внешняя система публикации, грубое отключение может сломать рабочий сценарий.
Ниже — рабочий подход: сначала понять, какие запросы реально приходят, затем закрыть лишнее точечно и проверить, что нужные интеграции остались живы.
Когда проблема действительно в XML-RPC
Чаще всего к этой настройке приходят после всплеска запросов к /xmlrpc.php, попыток подбора паролей или жалоб хостинга на нагрузку. Но сам факт обращений ещё не означает, что файл нужно блокировать полностью. Если сайт использует удалённую публикацию или синхронизацию, лучше ограничить методы, а не рубить всё подряд.
Признаки, что стоит разбираться именно с XML-RPC
- в логах веб-сервера много POST-запросов к
xmlrpc.php; - в панели безопасности видно много неудачных попыток авторизации через XML-RPC;
- сайт работает с Jetpack, мобильным приложением WordPress или внешним редактором;
- после полного отключения перестали приходить публикации из стороннего сервиса.
Диагностика: что именно использует сайт
Перед изменениями проверьте, есть ли зависимость от XML-RPC. Самый практичный способ — посмотреть логи и протестировать ключевые сценарии вручную. Если доступа к логам нет, хотя бы проверьте, не завязаны ли на XML-RPC плагины и приложения, которыми вы реально пользуетесь.
Что проверить в первую очередь
- Jetpack и его функции удалённого управления;
- мобильное приложение WordPress;
- сервисы автопостинга и кросспостинга;
- старые клиенты для публикации по XML-RPC;
- внешние интеграции, которые отправляют
metaWeblog.newPostили похожие методы.
Если вы не уверены, временно ограничьте доступ не на уровне WordPress, а на уровне веб-сервера или WAF только для подозрительных запросов. Так проще откатить изменения, если что-то сломается.
Пошаговое решение: как закрыть лишние XML-RPC-методы
Есть три нормальных варианта: блокировка на сервере, фильтрация в WordPress и использование плагина безопасности. Выбор зависит от того, нужен ли вам XML-RPC вообще.
| Подход | Что делает | Плюс | Минус |
|---|---|---|---|
| Сервер / WAF | Блокирует запросы до WordPress | Снижает нагрузку раньше | Нужно аккуратно не задеть нужные интеграции |
| Код в теме или mu-plugin | Отключает отдельные методы или весь XML-RPC | Гибко и прозрачно | Нужна правка кода |
| Плагин безопасности | Даёт переключатель и базовые правила | Быстро включить | Меньше контроля над деталями |
Вариант 1: отключить XML-RPC полностью
Если сайт точно не использует удалённую публикацию и внешние клиенты, можно отключить XML-RPC целиком. Для этого достаточно фильтра xmlrpc_enabled.
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код лучше размещать в mu-plugin, а не в теме. Тогда он не исчезнет после смены шаблона. Пример минимального mu-plugin:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен откат, достаточно удалить файл из wp-content/mu-plugins/.
Вариант 2: оставить XML-RPC, но ограничить доступ на сервере
Этот способ полезен, если вы хотите снизить шум от ботов, но не ломать сам механизм. На Apache можно закрыть доступ к xmlrpc.php через .htaccess, а на Nginx — через правило в конфиге. Но здесь важно понимать: это уже не настройка WordPress, а серверная политика.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx обычно используют отдельное правило в location-блоке. Если вы не администрируете сервер сами, лучше согласовать это с хостингом, чтобы не сломать другие правила обработки запросов.
Вариант 3: точечно ограничить опасные методы
Если XML-RPC нужен, но вы хотите убрать только часть методов, используйте фильтр xmlrpc_methods. Это уже более тонкая настройка: можно убрать методы, которые не нужны вашему сайту, и оставить только рабочие.
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );На практике это полезно, если вы хотите убрать pingback-атаку как класс, но оставить удалённую публикацию. Для большинства сайтов именно pingback-методы создают лишний риск и почти никогда не нужны.
Проверка результата после внедрения
После изменения не ограничивайтесь открытием главной страницы. Проверьте именно те сценарии, которые могли пострадать.
- Откройте
/xmlrpc.phpв браузере: если XML-RPC отключён, вы не должны видеть рабочий ответ метода. - Попробуйте выполнить вход из Jetpack или мобильного приложения WordPress, если они используются.
- Проверьте, не перестали ли приходить внешние публикации или пинги.
- Посмотрите логи сервера: число обращений к
xmlrpc.phpможет остаться, но успешных вызовов должно стать меньше.
Если вы отключали только pingback-методы, убедитесь, что остальные XML-RPC вызовы продолжают работать. Это можно проверить через интеграцию, которая реально используется на сайте, а не через абстрактный тест.
Частые ошибки и как их исправить
Отключили XML-RPC в плагине, а потом забыли про Jetpack
Это самая частая ситуация. Сайт выглядит нормально, но уведомления, статистика или удалённое управление перестают работать. Решение простое: сначала инвентаризируйте зависимости, потом отключайте.
Правило в .htaccess или Nginx закрывает больше, чем нужно
Иногда вместе с xmlrpc.php случайно ломают REST API, авторизацию или правила кеша. Проверяйте конфиг на отдельной тестовой копии и не вносите изменения в боевой сайт без отката.
Фильтр добавили в тему
Если код лежит в functions.php, он исчезнет при смене темы. Для системных ограничений лучше использовать mu-plugin или отдельный мини-плагин.
Отключили XML-RPC, но не убрали причину нагрузки
Если сайт атакуют по xmlrpc.php, но при этом открыт слабый пароль администратора, проблема не решена полностью. XML-RPC — только один из векторов. Проверьте ещё двухфакторную аутентификацию, сложность паролей и лимиты входа.
Практика безопасности и производительности
Если цель — не просто убрать шум, а реально снизить риск, полезно сочетать несколько мер. Полное отключение XML-RPC оправдано не всегда, но pingback-методы почти всегда можно убрать без последствий. На уровне сервера имеет смысл ограничить частоту запросов и включить защиту от брутфорса. На уровне WordPress — следить, чтобы не было лишних открытых точек входа.
Если вы используете плагины для чистки и SEO-оптимизации, вроде Clearfy Pro, проверьте, не дублируете ли вы одни и те же ограничения в нескольких местах. Два правила, которые делают одно и то же, часто мешают отладке сильнее, чем помогают.
Короткий чек-лист перед публикацией изменений
- Проверили, нужен ли XML-RPC хотя бы одному сервису.
- Выбрали уровень ограничения: WordPress, сервер или плагин.
- Сделали бэкап или хотя бы подготовили откат.
- Протестировали Jetpack, мобильное приложение и автопостинг.
- Посмотрели логи после изменения.
- Убедились, что отключён именно лишний метод, а не весь рабочий сценарий.
Если нужен максимально аккуратный вариант, начните с блокировки pingback-методов и только потом решайте, стоит ли отключать XML-RPC полностью. Так вы не потеряете полезные интеграции и быстрее поймёте, где именно был риск.