Если на сайте в логах регулярно всплывают обращения к /xmlrpc.php, а в админке не нужны удалённые публикации через старые приложения, чаще всего имеет смысл отключить XML-RPC и отдельно убрать pingback/trackback. Это не про «ускорить сайт вдвое», а про сокращение лишних запросов и уменьшение поверхности атаки.
Важно не путать задачи: xmlrpc.php — это один механизм, а pingback и trackback — другой слой, который часто живёт рядом с ним. Иногда сайт ломают не из-за самого XML-RPC, а из-за включённых pingback, которые продолжают генерировать шум и спам-уведомления.
Когда это действительно нужно
Отключать XML-RPC стоит не «на всякий случай», а если у вас нет сценариев, которые реально его используют. Типичный набор признаков:
- в логах много POST-запросов к
/xmlrpc.php; - сайт не подключён к старым мобильным клиентам WordPress;
- не используется Jetpack в режиме, где XML-RPC нужен для связи с сайтом;
- в админке приходят лишние уведомления о pingback;
- на сайте есть следы brute force по XML-RPC, хотя вход через
/wp-login.phpуже защищён.
Что проверить до изменений
Сначала убедитесь, что XML-RPC не нужен для интеграций. На практике это проверяется не догадкой, а списком подключений и сценариев:
- есть ли мобильные приложения, которые публикуют записи через WordPress;
- используется ли Jetpack и какие его функции реально включены;
- есть ли внешние сервисы, которые отправляют контент по XML-RPC;
- не завязаны ли на pingback внутренние процессы редакции — обычно нет, но лучше проверить.
Если сомневаетесь, сначала протестируйте на staging-копии. Это особенно важно, если сайт старый и на нём есть нестандартные плагины.
Диагностика: как понять, что XML-RPC и pingback дают лишнюю нагрузку
Самый простой способ — посмотреть access log веб-сервера. Если вы видите повторяющиеся обращения к /xmlrpc.php с разных IP, это уже повод проверить, нужен ли endpoint вообще.
Ещё один практический признак — спам в комментариях или уведомлениях о pingback. Когда на сайте включены pingback и trackback, WordPress может принимать уведомления от внешних источников, и это часто превращается в мусор.
Если у вас есть доступ к WP-CLI, можно быстро проверить состояние настроек записи:
wp option get default_pingback_flag
wp option get default_ping_status
wp option get default_comment_statusПервая команда показывает, включены ли pingback для новых записей по умолчанию. Это не отключает XML-RPC, но помогает понять, не создаёт ли сайт лишние уведомления сам.
Пошаговое решение без плагинов
Надёжнее всего закрывать XML-RPC на уровне WordPress и сервера одновременно. Если нужен только один слой, можно ограничиться WordPress, но для публичного сайта лучше убрать и сам endpoint, и связанные с ним функции.
1. Отключить XML-RPC в WordPress
Добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Так безопаснее, чем править ядро или ставить сомнительный «security pack» ради одной галочки.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает XML-RPC на уровне WordPress. После этого запросы к xmlrpc.php должны перестать проходить штатно.
2. Убрать pingback из заголовков и комментариев
Даже если XML-RPC отключён, полезно убрать pingback-ссылку из <head> и отключить сам механизм для новых записей.
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'wp_generator' );
} );
add_filter( 'pre_option_default_pingback_flag', '__return_zero' );
add_filter( 'pre_option_default_ping_status', '__return_zero' );Здесь важно понимать разницу: rsd_link убирает ссылку на RSD-эндпоинт, wlwmanifest_link — следы старого Windows Live Writer, а фильтры по умолчанию выключают pingback для новых записей.
3. Если есть доступ к серверу — закрыть endpoint на уровне веб-сервера
Это полезно как дополнительная защита. Для Nginx можно вернуть 403 на запросы к xmlrpc.php:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через прокси или CDN, проверьте, что правило не конфликтует с кешированием и не ломает служебные запросы.
Сравнение подходов: плагин, код или серверное правило
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Отключает XML-RPC и часть связанных функций | Быстро включить | Лишняя зависимость, возможны конфликты |
| Код в теме / mu-plugin | Гибко отключает XML-RPC и pingback | Прозрачно, без лишнего UI | Нужно следить за обновлениями и местом подключения |
| Правило веб-сервера | Блокирует запросы ещё до WordPress | Снижает шум и нагрузку | Нужно иметь доступ к конфигу сервера |
На практике лучше сочетать код и серверное правило. Если серверный доступ ограничен, достаточно фильтра xmlrpc_enabled и отключения pingback.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. После внедрения сделайте три теста:
- Откройте
/xmlrpc.phpв браузере или черезcurl— ответ не должен быть штатным XML-RPC-экраном WordPress. - Проверьте исходный код страницы: в
<head>не должно бытьrsd_linkиwlwmanifest. - Посмотрите access log: количество обращений к
/xmlrpc.phpдолжно резко снизиться или исчезнуть, если endpoint закрыт на сервере.
Пример проверки через curl:
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 403 Forbidden, правило работает. Если видите 200 OK и XML-ответ, блокировка не применена или её перебивает другой слой.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Некоторые установки Jetpack используют XML-RPC для связи с сайтом. Если после отключения часть функций перестала работать, сначала проверьте, действительно ли они нужны. Иногда проще отказаться от конкретной функции, чем держать открытым весь endpoint.
Поставили блокировку в плагине, а на сервере осталось открыто
Это не критично, но лишний запрос всё равно доходит до WordPress. Для публичного сайта лучше закрывать endpoint на уровне веб-сервера, если это возможно.
Удалили pingback, но уведомления продолжают приходить
Проверьте, не включены ли pingback для уже опубликованных записей и не активны ли старые плагины комментариев. Иногда источник шума находится не в ядре, а в теме или в плагине, который переопределяет поведение комментариев.
Сломали редактирование через мобильное приложение
Это ожидаемый риск, если приложение использует XML-RPC. Решение простое: либо вернуть endpoint, либо перейти на другой способ публикации. Для большинства современных сайтов это не проблема, но старые рабочие процессы лучше проверить заранее.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не заменяет защиту входа и не отменяет нормальную гигиену сайта. Но в связке с другими мерами оно полезно:
- ограничьте попытки входа в админку;
- обновляйте ядро, темы и плагины без задержек;
- уберите неиспользуемые плагины, которые могут добавлять свои точки входа;
- проверьте, не создаёт ли тема лишние pingback или служебные ссылки в
<head>; - если сайт под атакой, смотрите не только WordPress, но и логи веб-сервера и CDN.
Если нужен более широкий набор технических чисток — от дублей до скрытых служебных ссылок — имеет смысл смотреть в сторону инструментов, которые закрывают несколько задач сразу, а не ставить отдельный плагин под каждый мелкий симптом.
После внедрения не полагайтесь на ощущение «вроде стало тише». Проверьте логи, ответ xmlrpc.php и поведение интеграций, которые реально используются на сайте. Только так можно понять, что вы убрали лишнее, а не сломали рабочий сценарий.