XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или интеграции, которые до сих пор ходят в xmlrpc.php. Поэтому правильный подход здесь не в слепом запрете, а в проверке, нужен ли этот канал вообще, и только потом — в отключении.
Если сайт не использует удалённую публикацию через XML-RPC, этот файл обычно становится лишней точкой входа для перебора запросов и шумной нагрузки. Но если у вас есть Jetpack, старые приложения для публикации или сторонний сервис, который синхронизирует записи через XML-RPC, сначала нужно убедиться, что вы не отрежете рабочий сценарий.
Когда XML-RPC действительно можно отключать
Отключение оправдано, если сайт живёт обычной админкой WordPress и не принимает публикации извне. Типичный набор признаков:
- в админку заходят только редакторы и администраторы;
- мобильное приложение WordPress не используется;
- нет интеграций, которые публикуют записи через XML-RPC;
- в логах видно много запросов к
/xmlrpc.php, но они не нужны бизнесу.
Если хотя бы один внешний сервис зависит от этого канала, отключать его без замены не стоит. В таком случае лучше сначала перевести интеграцию на REST API или другой поддерживаемый способ доступа.
Диагностика: как понять, используется ли xmlrpc.php
Самый простой способ — посмотреть логи веб-сервера и активность плагинов. Если у вас есть доступ к access log, ищите обращения к xmlrpc.php. Для Nginx это можно сделать так:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если запросы идут регулярно и с разных IP, это не всегда атака, но уже повод проверить, кто именно обращается. Иногда это старые мобильные клиенты, иногда — внешние сервисы, иногда — боты, которые просто стучатся в этот файл в поисках уязвимостей.
Ещё один практический тест — временно заблокировать доступ на тестовой среде и проверить:
- открывается ли
/xmlrpc.phpв браузере; - не ломается ли публикация через внешние инструменты;
- не перестают ли приходить записи из интеграций;
- не появляется ли ошибка в логах плагинов, которые работают с удалённым доступом.
Что именно искать в зависимостях
Особое внимание стоит уделить Jetpack и старым клиентам для публикации. Jetpack в некоторых сценариях использует XML-RPC для части функций, хотя многое уже работает через другие механизмы. Если у вас подключён этот плагин, отключение нужно проверять отдельно, а не по общему правилу.
Также проверьте внешние сервисы автопостинга, синхронизации контента и мониторинга. Если они не документируют способ подключения, значит, отключение XML-RPC может сломать их молча — без явной ошибки в админке.
Как отключить XML-RPC без плагинов
Если зависимости не нашли, самый надёжный вариант — запретить доступ на уровне WordPress. Для этого можно использовать фильтр xmlrpc_enabled. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC внутри WordPress. Для большинства сайтов этого достаточно, но если нужно ещё и отрезать прямой доступ к файлу на уровне сервера, добавьте правило в конфигурацию веб-сервера.
Блокировка на уровне Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант полезен, если сайт получает много лишних запросов к этому файлу и вы хотите убрать их ещё до загрузки WordPress. Для Apache логика похожая, но правило будет другим и зависит от конфигурации виртуального хоста.
Блокировка через .htaccess
<Files xmlrpc.php>
Require all denied
</Files>Этот способ подходит для Apache-серверов. Если сайт работает на Nginx, .htaccess не поможет, потому что сервер его просто не читает.
Сравнение подходов: код, сервер, плагин
| Способ | Где работает | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | WordPress | Просто внедрить, не зависит от сервера | Запрос всё равно доходит до PHP |
| Правило Nginx/Apache | Сервер | Режет доступ раньше, снижает нагрузку | Нужно иметь доступ к конфигу |
| Плагин безопасности | WordPress | Удобно для админов без доступа к коду | Лишняя зависимость, возможны конфликты |
Если у вас есть доступ к серверу, лучше закрывать файл на уровне веб-сервера и дополнительно отключать XML-RPC в WordPress. Если доступа к конфигу нет, достаточно фильтра, но тогда стоит проверить, не остаётся ли лишняя нагрузка на PHP.
Пошаговое решение для боевого сайта
- Проверьте логи на обращения к
xmlrpc.php. - Составьте список интеграций, которые могут использовать XML-RPC.
- На staging-сайте отключите XML-RPC и протестируйте публикацию, вход и внешние сервисы.
- Если всё работает, внесите изменения в продакшн.
- После внедрения ещё раз проверьте логи и убедитесь, что запросы к
xmlrpc.phpне проходят.
Если сайт большой, не делайте отключение в часы пик. Лучше сначала применить правило на тестовой копии, а затем перенести его в рабочую среду с понятным планом отката.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php. Если доступ закрыт на уровне сервера, вы увидите отказ в доступе или 403. Если отключение сделано через WordPress-фильтр, файл может отвечать, но XML-RPC-функции будут недоступны.
Дополнительно проверьте:
- не работают ли старые клиенты публикации;
- нет ли ошибок в логах PHP и веб-сервера;
- не пропали ли события в Jetpack или другой интеграции;
- не выросло ли количество 404/403 на
xmlrpc.phpпосле блокировки.
Если после отключения сайт стал заметно тише в логах, а рабочие сценарии не пострадали, значит, решение выбрано правильно.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали Jetpack
Причина обычно в том, что Jetpack использовался не только для статистики, но и для функций, которые завязаны на удалённое соединение. Решение простое: сначала проверить зависимости, потом отключать. Если Jetpack нужен, не рубите XML-RPC без теста.
Добавили правило в .htaccess, но сайт на Nginx
Это частая ошибка при переносе инструкций между серверами. На Nginx .htaccess не работает, поэтому блокировку нужно делать в конфиге сервера или через WordPress-фильтр.
Отключили только в WordPress, но нагрузка осталась
Если боты продолжают стучаться в xmlrpc.php, WordPress всё равно получает запросы. Чтобы убрать лишнюю нагрузку, блокируйте файл на уровне веб-сервера.
Сразу поставили плагин безопасности без проверки
Это удобно, но не всегда прозрачно. Некоторые плагины закрывают XML-RPC вместе с другими функциями, и потом сложно понять, что именно сломалось. Если задача точечная, лучше сначала использовать код или серверное правило.
Что учесть по безопасности и производительности
Отключение XML-RPC — это не универсальная защита, а один из шагов по сокращению поверхности атаки. Оно полезно, если вы не используете удалённую публикацию и хотите убрать лишний входной канал. Но не заменяет обновления ядра, плагинов и темы, а также нормальную защиту админки.
Если сайт часто получает шумные запросы, имеет смысл дополнительно проверить:
- нужен ли REST API без ограничений;
- нет ли открытых форм авторизации без защиты от перебора;
- включены ли актуальные обновления WordPress;
- не создают ли плагины лишние публичные endpoints.
Для сайтов, где важна техническая чистота и минимизация дублей и лишних точек входа, полезно держать под рукой инструменты вроде Clearfy Pro: он помогает убирать часть ненужных функций и упрощает базовую гигиену сайта. Но даже в этом случае отключение XML-RPC лучше делать осознанно, а не «галочкой ради галочки».
Если нужен безопасный минимум, рабочая схема обычно такая: сначала аудит зависимостей, затем отключение через xmlrpc_enabled, потом серверная блокировка и финальная проверка логов. Это даёт предсказуемый результат без сюрпризов для редакторов и внешних сервисов.