Если в логах регулярно всплывают запросы к /xmlrpc.php, а сайт не использует старые мобильные клиенты и удалённые публикации, этот интерфейс обычно только создаёт лишнюю поверхность атаки. Но отключать его «в лоб» опасно: вместе с XML-RPC можно случайно сломать Jetpack, внешние приложения для публикации и некоторые интеграции, которые до сих пор завязаны на этот механизм.
Ниже — рабочая схема: как понять, нужен ли XML-RPC именно вашему сайту, чем отличается отключение от частичного ограничения, и как проверить, что после правки ничего не отвалилось.
Когда XML-RPC действительно можно отключать
Сначала стоит не править код, а посмотреть на реальные сценарии использования. На большинстве сайтов XML-RPC давно не нужен, но это не универсальное правило. Если вы не публикуете записи через внешние клиенты, не используете старые интеграции и не подключали сервисы, которые работают через XML-RPC, отключение обычно безопасно.
Что чаще всего зависит от XML-RPC
- Jetpack в некоторых конфигурациях и сценариях синхронизации;
- старые мобильные приложения WordPress;
- внешние редакторы и сервисы автопубликации;
- плагины, которые используют удалённый доступ к сайту через XML-RPC;
- pingback и trackback, если они не отключены отдельно.
Если сайт обычный: пишете контент в админке, не используете удалённую публикацию и не видите обращения к XML-RPC в логах от нужных сервисов, можно переходить к отключению.
Диагностика: как понять, кто обращается к xmlrpc.php
Перед изменениями полезно посмотреть, есть ли вообще легитимные обращения. Самый простой способ — проверить access-логи веб-сервера или логи в панели хостинга. Ищите запросы к /xmlrpc.php и смотрите IP, User-Agent и частоту.
Если доступа к логам нет, можно временно поставить ограничение на уровне WordPress и посмотреть, не появятся ли жалобы от редакторов или интеграций. Но лучше сначала собрать факты.
На что смотреть в логах
- регулярные POST-запросы к
xmlrpc.phpс одинаковых IP; - ошибки авторизации, если кто-то пытается подобрать логин и пароль;
- обращения от Jetpack или другого известного сервиса;
- повторяющиеся запросы
pingback.pingи похожие методы.
Если у вас есть доступ к SSH, можно быстро отфильтровать строки по имени файла:
grep -R "xmlrpc.php" /var/log/nginx/ /var/log/apache2/ 2>/dev/null | tail -n 50Команда зависит от структуры логов на сервере, но смысл один: понять, есть ли реальные потребители XML-RPC.
Как отключить XML-RPC безопасно
Есть несколько способов. Самый предсказуемый — отключить XML-RPC через код, а не через сомнительные «оптимизаторы», которые меняют сразу всё подряд. Если нужен обратимый вариант, лучше начать с фильтра, а не с жёсткой блокировки на уровне веб-сервера.
Вариант 1: отключить через functions.php или mu-plugin
Добавьте код в functions.php дочерней темы или, что лучше, в отдельный mu-plugin. Так настройка не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC в WordPress. Для большинства сайтов этого достаточно. Если потом выяснится, что нужен Jetpack или другой сервис, фильтр можно убрать.
Вариант 2: отключить только pingback и trackback
Иногда XML-RPC нужен, но pingback и trackback — нет. Тогда лучше не рубить всё целиком, а убрать только эти механизмы.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );
add_filter( 'pings_open', '__return_false' );Это полезно, если вы хотите оставить совместимость с частью внешних сервисов, но убрать лишний шум и часть атак на pingback.
Вариант 3: блокировать на уровне сервера
Если задача — именно снизить нагрузку и убрать лишние запросы ещё до загрузки WordPress, можно закрыть xmlrpc.php на уровне веб-сервера. Но здесь важно не забыть про зависимости.
Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache в .htaccess можно использовать правило блокировки, но на shared-хостинге не всегда удобно вносить такие изменения. Если не уверены в конфигурации, лучше ограничиться фильтром WordPress.
Сравнение подходов: код, сервер, плагин
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Просто откатить, не трогает сервер | WordPress всё равно загружается | Если нужен безопасный и обратимый вариант |
| Блокировка на сервере | Режет запросы раньше WordPress | Нужно аккуратно проверить зависимости | Если важна защита от лишних обращений и брутфорса |
| Плагин безопасности | Удобно для админов без кода | Лишняя зависимость, иногда много лишних функций | Если уже используете такой плагин и доверяете его настройкам |
Если на сайте уже стоит комплексный плагин для технической чистки, например Clearfy Pro, проверьте, не дублирует ли он ваши ручные правила. Двойное отключение обычно не ломает сайт, но усложняет диагностику.
Пошаговая проверка после отключения
После изменения не ограничивайтесь открытием главной страницы. XML-RPC может быть выключен, а проблема с зависимым сервисом проявится только позже. Проверьте сайт по короткому чек-листу.
- Откройте
/xmlrpc.phpв браузере: вместо рабочей страницы должен быть отказ или сообщение об ошибке доступа. - Проверьте Jetpack, если он установлен: синхронизация, статистика, публикация и другие используемые функции.
- Если есть внешняя публикация или мобильное приложение, попробуйте создать черновик или отправить тестовую запись.
- Посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо блокироваться, либо не доходить до WordPress. - Убедитесь, что на сайте не появились ошибки PHP после добавления кода.
Если вы отключали только pingback, проверьте, что обычная публикация и комментарии работают как раньше, а входящие pingback больше не приходят.
Частые ошибки и как их исправить
Сломали Jetpack и не поняли почему
Чаще всего причина в том, что XML-RPC отключили полностью, а Jetpack в вашей конфигурации ещё использует его для части функций. Решение простое: вернуть фильтр xmlrpc_enabled, проверить нужные возможности Jetpack и уже потом решать, можно ли закрыть XML-RPC иначе.
Блокировали xmlrpc.php на сервере, но забыли про тестовый доступ
Если интеграция работает через белый IP или отдельный сервис, серверное правило может отрезать и нужные обращения. В таком случае лучше оставить WordPress-фильтр или добавить исключение на уровне веб-сервера, если это действительно необходимо.
Поставили плагин, который отключает слишком много
Некоторые плагины безопасности не только отключают XML-RPC, но и меняют REST API, авторизацию, заголовки и другие параметры. Если после установки стало хуже, уберите лишний слой и оставьте только точечное правило.
Проверили только главную страницу
Это типичная ошибка. Сайт может открываться, но внешняя публикация, мобильное приложение или синхронизация записей уже не работают. Проверять нужно именно те сценарии, которые были у вас до изменения.
Что ещё стоит сделать для безопасности и производительности
Отключение XML-RPC полезно, но не заменяет базовую гигиену. Если цель — уменьшить поверхность атаки, имеет смысл дополнительно проверить:
- отключены ли trackback и pingback в настройках обсуждения;
- не открыты ли лишние технические страницы в индексацию;
- нет ли на сайте старых плагинов, которые используют удалённую авторизацию без необходимости;
- не дублируются ли правила в плагине безопасности и в конфиге сервера;
- не создаёт ли тема или кастомный код лишние запросы к админке и REST API.
Если нужен более широкий аудит технических дублей и лишних функций, удобнее сначала собрать список проблем, а потом уже отключать их точечно. Иначе легко получить набор случайных правок без понятного эффекта.
Рабочий критерий простой: после отключения XML-RPC у вас не должно быть лишних обращений к /xmlrpc.php, а все нужные интеграции должны продолжать работать. Если хотя бы один обязательный сервис зависит от этого интерфейса, не отключайте его полностью — ограничьте только pingback или закройте доступ на сервере с исключением для нужного сценария.