Как отключить XML-RPC в WordPress без поломки сайта

XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестали работать мобильные клиенты, старые интеграции или удалённая публикация. Сам по себе файл xmlrpc.php не нужен большинству сайтов, но решение должно быть осознанным: сначала проверяем, используется ли он вообще, потом выбираем способ блокировки и только после этого закрываем доступ.

Когда XML-RPC действительно стоит отключать

Если сайт не использует внешнюю публикацию, Jetpack-часть функций, старые приложения для управления контентом или интеграции, завязанные на XML-RPC, его можно закрыть. На практике это чаще всего нужно для снижения поверхности атаки: через xmlrpc.php нередко пытаются перебор паролей и отправку массовых запросов.

Но отключение не должно быть автоматическим. Если у вас:

• подключён Jetpack и он использует удалённые функции;
• есть мобильное приложение или сторонний клиент для публикации;
• работает интеграция с внешней системой через XML-RPC;
• используется старый плагин синхронизации контента;

то сначала проверьте, какие именно запросы идут на xmlrpc.php. Иначе можно отключить не только лишний доступ, но и рабочий сценарий.

Диагностика: как понять, используется ли xmlrpc.php

Самый простой способ — посмотреть логи веб-сервера. Если в access log есть регулярные обращения к /xmlrpc.php с кодами 200, 401 или 403, значит файл либо кто-то сканирует, либо он реально задействован. Для проверки можно временно добавить логирование на уровне сервера или открыть статистику в панели хостинга.

Ещё один практичный тест — вручную отправить запрос и посмотреть ответ. Если XML-RPC включён, WordPress обычно отвечает на системный метод system.listMethods. Если закрыт — вы увидите ошибку доступа или пустой ответ в зависимости от способа блокировки.

curl -i https://example.com/xmlrpc.php

Если в ответе есть признаки WordPress или HTTP-статус 200, файл доступен. Это ещё не доказывает, что он нужен вашему сайту, но показывает, что закрывать его есть смысл.

Как отключить XML-RPC: сравнение подходов

Вариант 1: отключение через код

Если нужно именно отключить XML-RPC на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Это безопаснее, чем править основную тему, потому что изменение не потеряется при обновлении.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант полностью выключает XML-RPC в WordPress. Если потом выяснится, что какая-то интеграция всё-таки нужна, фильтр можно убрать без правок сервера.

Вариант 2: блокировка на уровне nginx

Если у вас nginx и задача — не пускать запросы даже до WordPress, можно закрыть xmlrpc.php в конфигурации сайта. Это полезно, когда на сайт идёт много мусорных запросов и вы хотите снять лишнюю нагрузку.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

После изменения конфигурации проверьте, что файл действительно отдаёт 403 Forbidden. Если у вас несколько сайтов на одном сервере, не переносите этот блок вслепую: сначала убедитесь, что он добавлен именно в нужный server block.

Вариант 3: блокировка в .htaccess для Apache

На Apache можно закрыть доступ через .htaccess. Это не самый изящный способ, но он работает там, где нет доступа к конфигу виртуального хоста.

<Files xmlrpc.php>
    Require all denied
</Files>

Если сервер старый и использует синтаксис Apache 2.2, может понадобиться другой вариант правил. Но на современных установках лучше ориентироваться на Require all denied.

Пошаговое решение без сюрпризов

1. Проверьте логи и убедитесь, что через xmlrpc.php не идёт нужный трафик.
2. Выберите способ блокировки: код, сервер или плагин.
3. Сделайте изменение на staging, если сайт рабочий и с интеграциями.
4. После внедрения проверьте HTTP-ответ на /xmlrpc.php.
5. Откройте админку и протестируйте публикацию, комментарии и внешние сервисы, если они есть.

Если нужен быстрый и управляемый вариант, кодовый фильтр обычно удобнее всего. Если важнее отсечь запросы до PHP, лучше блокировать на сервере.

Как проверить, что решение сработало

Проверка должна быть не «на глаз», а по факту ответа сервера. Самый простой способ — повторить запрос после внедрения и посмотреть код ответа.

curl -I https://example.com/xmlrpc.php

Ожидаемый результат зависит от способа блокировки:

• при отключении через xmlrpc_enabled часто будет ошибка WordPress или отказ в доступе;
• при блокировке на nginx или Apache — 403;
• если файл всё ещё доступен, вы увидите 200 или ответ WordPress.

Дополнительно проверьте журнал веб-сервера через 10–15 минут после изменения. Если запросы продолжают приходить, но уже получают 403, значит блокировка работает и мусорный трафик не доходит до WordPress.

Частые ошибки и как их исправить

Отключили XML-RPC и сломали интеграцию

Это типичная ситуация, когда не проверили зависимости. Если после отключения перестала работать публикация из внешнего клиента или Jetpack, верните доступ и ищите конкретный сценарий, который использует XML-RPC. Иногда достаточно ограничить не весь файл, а только доступ по IP или закрыть его на уровне WAF.

Правило добавили не туда

Если код вставлен в родительскую тему, он может исчезнуть после обновления. Если правило в .htaccess не сработало, проверьте, что сервер вообще использует Apache и что AllowOverride разрешает чтение этого файла.

Проверили только главную страницу

XML-RPC живёт отдельно от обычных страниц сайта. То, что главная открывается нормально, ничего не говорит о доступности xmlrpc.php. Проверять нужно именно его.

Смешали отключение и блокировку

Иногда ставят и фильтр WordPress, и серверное правило, а потом не могут понять, где именно произошёл отказ. Для диагностики лучше сначала выбрать один способ, убедиться в результате, а уже потом при необходимости усилить защиту вторым уровнем.

Что учесть для безопасности и производительности

Если цель — уменьшить нагрузку от брутфорса и сканеров, серверная блокировка обычно эффективнее, потому что запросы не доходят до PHP. Если важнее оставить возможность быстрого отката, начните с фильтра в WordPress. Для сайтов с агрессивным мусорным трафиком можно сочетать блокировку xmlrpc.php с ограничением частоты запросов на уровне nginx или WAF.

Для админской гигиены полезно периодически смотреть access log не только на xmlrpc.php, но и на другие часто атакуемые точки: /wp-login.php, /wp-admin/, /wp-json/. Это помогает не лечить один симптом, а видеть общую картину по сайту.

Если вам нужно не просто закрыть XML-RPC, а навести порядок в технических дублях, индексации и лишних функциях сайта, похожие задачи удобно закрывать через набор точечных настроек и чистку лишнего кода. В таких сценариях часто помогает Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpmentor.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xmlrpc-v-wordpress-bez-lomki-sayta