Если сайт на WordPress начал получать лишние запросы к xmlrpc.php, а в логах видно перебор методов вроде system.multicall, обычно речь не о «поломке», а о старом механизме, который давно не нужен большинству сайтов. При этом отключать XML-RPC вслепую нельзя: у части сайтов через него всё ещё работают мобильное приложение WordPress, Jetpack и некоторые внешние сервисы публикации.
Отдельно стоит pingback. Даже если XML-RPC вам нужен частично, pingback часто остаётся лишним источником мусорных запросов и попыток злоупотребления. Поэтому практичнее решать задачу в два шага: сначала понять, используется ли XML-RPC вообще, потом отключить только то, что не нужно.
Когда XML-RPC и pingback реально мешают
Типичный сценарий выглядит так: в access log много обращений к /xmlrpc.php, иногда с одинаковым User-Agent, а в панели безопасности или на хостинге появляются уведомления о brute force. Сам по себе факт запросов ещё не означает взлом, но это лишняя поверхность атаки и лишняя нагрузка.
Что обычно ломается при отключении
Если у вас нет внешних интеграций, отключение проходит незаметно. Но если сайт использует:
- мобильное приложение WordPress для публикации;
- Jetpack или сервисы, которые синхронизируются через XML-RPC;
- удалённую публикацию из сторонних клиентов;
- старые интеграции, завязанные на pingback;
— их нужно проверить заранее. Иначе вы получите не «усиление безопасности», а просто неработающую связку.
Диагностика: используется ли XML-RPC на вашем сайте
Самый надёжный способ — не гадать, а проверить фактические обращения и зависимости.
- Откройте логи веб-сервера и посмотрите, есть ли регулярные запросы к
xmlrpc.php. - Проверьте, используете ли вы Jetpack, мобильное приложение WordPress или сторонний клиент публикации.
- Если есть доступ к staging-копии, сначала отключите XML-RPC там и протестируйте сценарии публикации.
Если вы не уверены, начните с мягкой проверки: заблокируйте только pingback, а не весь XML-RPC. Это уже убирает часть мусора и не ломает все методы сразу.
Что лучше: плагин, код или серверная блокировка
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Если нужен интерфейс и быстрый откат | Дополнительная нагрузка и зависимость от плагина |
| Код в теме или mu-plugin | Если нужен точечный контроль | Нужно аккуратно обновлять и не потерять при смене темы |
| Блокировка на сервере | Если XML-RPC точно не нужен вообще | Можно случайно задеть нужные интеграции |
Для большинства рабочих сайтов самый предсказуемый вариант — код в mu-plugin или в небольшом плагине. Так правило не исчезнет при смене темы и не потеряется после обновления.
Пошаговое решение: отключаем XML-RPC и pingback безопасно
Ниже — вариант, который отключает XML-RPC полностью. Используйте его только если вы уже проверили, что он не нужен.
<?php
/**
* Plugin Name: Disable XML-RPC and pingbacks
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
if ( isset( $headers['X-Pingback'] ) ) {
unset( $headers['X-Pingback'] );
}
return $headers;
} );
add_filter( 'pings_open', '__return_false' );
Что делает этот код:
xmlrpc_enabledвыключает сам XML-RPC;X-Pingbackубирает заголовок, который подсказывает клиентам о наличии pingback;pings_openзакрывает pingback для записей, где это применимо.
Если вам нужен XML-RPC, но не нужен pingback, не отключайте всё целиком. В этом случае лучше убрать только pingback-методы. Это уже более тонкая настройка, и её стоит тестировать на staging, потому что список методов зависит от используемых сервисов.
Если нужен более жёсткий вариант на сервере
Когда XML-RPC точно не используется, можно закрыть доступ на уровне веб-сервера. Для Nginx это обычно делают отдельным правилом в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант уменьшает количество бесполезных запросов ещё до загрузки WordPress. Но если потом выяснится, что интеграция всё-таки нужна, придётся возвращать доступ на уровне сервера и заново проверять сценарии.
Проверка результата после внедрения
После отключения важно не ограничиться «страница открывается». Проверьте именно те точки, которые связаны с XML-RPC и pingback.
- Откройте
/xmlrpc.phpв браузере: при полном отключении он не должен отвечать как рабочий endpoint WordPress. - Посмотрите access log: число обращений к
xmlrpc.phpдолжно перестать расти как раньше. - Проверьте публикацию через админку, если вы используете только стандартный редактор.
- Если есть Jetpack или внешний клиент, выполните тестовую синхронизацию или публикацию.
Для pingback можно дополнительно проверить HTML-ответ страницы: заголовок X-Pingback должен отсутствовать, если вы его убрали.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо, если Jetpack был завязан на XML-RPC. Решение простое: либо вернуть XML-RPC, либо отказаться от этой связки и перейти на другой сценарий подключения, если он доступен в вашей конфигурации.
Спрятали проблему плагином, но запросы всё равно идут
Некоторые плагины только блокируют обработку внутри WordPress, но сам запрос до PHP уже доходит. Если цель — снизить нагрузку и шум в логах, лучше закрывать xmlrpc.php на уровне веб-сервера или WAF.
Отключили pingback, но комментарии и уведомления ведут себя странно
Проверьте, не перепутали ли вы pingback с обычными комментариями. Это разные механизмы. pings_open влияет на pingback/trackback, но не должен ломать стандартные комментарии, если тема и плагины не вмешиваются в логику.
Внесли код в тему и потеряли его после обновления
Это частая ошибка. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин. Тогда правило не исчезнет при обновлении темы.
Практические советы по безопасности и производительности
Если сайт публичный и без удалённой публикации, отключение XML-RPC обычно оправдано. Но не делайте это «на всякий случай» без проверки зависимостей. Сначала убедитесь, что у вас нет внешних клиентов и сервисов, которые реально используют этот канал.
Если вы ведёте несколько сайтов, удобно держать такие технические правила в одном небольшом mu-plugin. Это проще сопровождать, чем разбрасывать по functions.php. Для сайтов, где нужно ещё и чистить лишние SEO-дубли, отключать ненужные архивы и убирать мусорные элементы, часто разумно собрать базовую техгигиену в одном наборе правил, а не плодить отдельные костыли по теме.
В связке с этим обычно имеет смысл проверить и другие точки шума: лишние архивы, ненужные REST-эндпоинты, старые редиректы и заголовки, которые только увеличивают поверхность атаки. Но каждое такое изменение лучше вносить отдельно и проверять по логам, а не пачкой.
Короткий чек-лист перед отключением
- Проверил, используется ли Jetpack или мобильное приложение WordPress.
- Посмотрел логи на реальные обращения к
xmlrpc.php. - Решил, нужно ли отключать XML-RPC полностью или только pingback.
- Внёс изменение в
mu-pluginили отдельный плагин, а не в тему. - После внедрения проверил публикацию, синхронизацию и логи сервера.
Если нужен более широкий набор технической чистки сайта, в том числе удаление дублей и лишних SEO-элементов, такие задачи удобно решать через отдельный набор инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику отключения XML-RPC лучше понимать и проверять вручную, а не полагаться только на кнопку в интерфейсе.