XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки, шум в логах и ненужные запросы к /xmlrpc.php. Если вы не используете удалённую публикацию, старые мобильные клиенты или интеграции, которые завязаны именно на XML-RPC, этот интерфейс обычно можно отключить без заметных последствий.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без лишних побочных эффектов и как быстро проверить, что всё действительно закрыто.
Когда XML-RPC можно отключать, а когда лучше не трогать
Проблема не в самом файле xmlrpc.php, а в том, что он доступен извне и принимает специфические запросы. На практике он нужен редко. Чаще всего его используют:
- старые приложения WordPress для публикации с телефона или десктопа;
- Jetpack и некоторые внешние сервисы, которые ещё опираются на XML-RPC;
- редкие интеграции с удалённой публикацией и pingback.
Если у вас обычный сайт, где публикация идёт из админки, через REST API или через современный мобильный интерфейс, XML-RPC чаще всего не нужен. Но если вы не уверены, сначала проверьте логи и список подключённых сервисов, а не отключайте его «вслепую».
Быстрая диагностика проблемы
Признаки, что XML-RPC можно убрать:
- в логах веб-сервера регулярно встречаются запросы к
/xmlrpc.php; - в панели безопасности или WAF фиксируются попытки брутфорса через XML-RPC;
- вы не используете Jetpack, старые клиенты публикации и удалённые интеграции;
- при открытии
/xmlrpc.phpв браузере вы видите стандартный ответ WordPress, а не ошибку 403/404.
Если у вас включён Jetpack, сначала проверьте, какие функции реально используются. Не все модули требуют XML-RPC, но отключать его без проверки в таком случае не стоит.
Как отключить XML-RPC: сравнение вариантов
Есть три нормальных пути: через плагин, через код в теме/му-плагине и через серверную блокировку. Для большинства сайтов самый предсказуемый вариант — код или плагин. Серверная блокировка полезна, если вы хотите отрезать доступ ещё до загрузки WordPress.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правки кода | Ещё один плагин в системе | Если нужен простой откат и нет доступа к коду |
Код в functions.php или mu-plugin | Контроль, без лишних зависимостей | Нужно аккуратно разместить код | Если вы ведёте сайт как разработчик |
| Серверная блокировка | Отсекает запросы раньше WordPress | Нужно править конфиг сервера | Если важна минимизация нагрузки и атак |
Если у вас уже стоит комплексный плагин для технической чистки сайта, например Clearfy Pro, проверьте, нет ли там отдельной опции для отключения XML-RPC. Это удобнее, чем держать ещё один узкий плагин только ради одной настройки.
Отключение XML-RPC через код
Самый прозрачный способ — добавить фильтр, который запрещает XML-RPC на уровне WordPress. Лучше не вставлять это в активную тему, если сайт живёт долго и тема может меняться. Надёжнее использовать mu-plugin.
Вариант для mu-plugin
Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC штатно, без редиректов и без лишней логики. WordPress перестанет отвечать на XML-RPC-запросы, но сам сайт продолжит работать как обычно.
Если нужно не отключить, а вернуть 403 на уровне WordPress
Иногда удобнее явно завершать запрос, чтобы не оставлять двусмысленных ответов. Тогда можно использовать хук xmlrpc_call или проверку в раннем этапе загрузки, но для большинства задач это избыточно. На практике фильтра xmlrpc_enabled достаточно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Второй фрагмент нужен не всегда. Его имеет смысл использовать только если вы точно понимаете, как у вас устроены ранние запросы и не хотите оставлять даже стандартный ответ WordPress.
Серверная блокировка: когда это уместно
Если вы хотите отрезать доступ к xmlrpc.php до загрузки WordPress, можно сделать это на уровне веб-сервера. Это особенно полезно, когда сайт регулярно получает брутфорс или мусорные запросы.
Apache: блокировка через .htaccess
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант работает, если у вас Apache и разрешено использовать .htaccess. После добавления правила запросы к /xmlrpc.php должны получать отказ ещё до запуска WordPress.
Nginx: запрет на location
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Nginx это обычно самый чистый способ. Он не нагружает PHP и не создаёт лишних записей в логах, если вы отключили логирование для этого location.
Как проверить, что отключение сработало
Проверка нужна не формально, а по факту. После внедрения сделайте несколько простых тестов:
- откройте
https://ваш-домен/xmlrpc.phpв браузере; - проверьте ответ через
curl; - посмотрите логи веб-сервера и WAF;
- если используете Jetpack или внешние сервисы, убедитесь, что они не потеряли связь.
Для быстрой проверки через консоль можно использовать такой запрос:
curl -i https://example.com/xmlrpc.phpЧто считать нормальным результатом зависит от способа блокировки. Если вы отключали XML-RPC через WordPress, обычно увидите ответ, который не позволяет выполнить XML-RPC-вызов. Если блокировали на сервере, ожидайте 403 Forbidden или аналогичный отказ. Главное — чтобы endpoint больше не принимал рабочие XML-RPC-запросы.
Дополнительно проверьте, что:
- админка WordPress открывается без ошибок;
- публикация записей не сломалась;
- REST API продолжает отвечать, если вы его используете;
- в логах исчезли попытки успешного обращения к XML-RPC.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли Jetpack
Это самый частый сценарий. Если Jetpack нужен, не отключайте XML-RPC до проверки конкретных модулей. Сначала отключите только те функции, которые вам не нужны, или оставьте XML-RPC включённым, если интеграция критична.
Добавили код в тему и забыли про него
Если код лежит в functions.php, при смене темы защита исчезнет. Для технических настроек лучше использовать mu-plugin или отдельный мини-плагин. Так решение не зависит от дизайна сайта.
Поставили плагин, который делает слишком много
Некоторые плагины безопасности отключают XML-RPC вместе с другими функциями. Это не всегда плохо, но потом сложнее понять, что именно сломало интеграцию. Если нужна только одна настройка, лучше использовать точечное решение.
Заблокировали не там, где нужно
Если вы закрыли доступ в .htaccess, а сайт работает на Nginx, правило просто не сработает. Сначала проверьте стек сервера, потом вносите блокировку. На хостингах с прокси-схемой иногда нужно смотреть ещё и на уровень панели управления.
Что ещё стоит проверить после отключения
Если вы чистите сайт от лишних технических точек входа, не ограничивайтесь только XML-RPC. Посмотрите, нет ли у вас:
- лишних открытых endpoint'ов в REST API;
- дублирующихся архивов и служебных страниц;
- неиспользуемых плагинов, которые всё равно держат свои маршруты;
- старых правил безопасности, которые конфликтуют друг с другом.
На проектах, где важны SEO и техническая чистота, удобно собирать такие настройки в одном месте, чтобы не искать их по теме, плагинам и серверу. Это снижает шанс, что одна мелкая опция будет потеряна после обновления.
Если нужен именно технический набор для чистки WordPress без ручного разбрасывания по файлам, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.
В итоге логика простая: сначала проверьте, нужен ли вам XML-RPC вообще, затем выберите способ отключения по уровню контроля — WordPress, плагин или сервер — и обязательно подтвердите результат тестом. Тогда вы уберёте лишний вход для атак, не ломая рабочие интеграции.