XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: на сайте появляются лишние запросы к /xmlrpc.php, в логах растёт шум, а иногда через этот endpoint пытаются подбирать пароли или дергать pingback-методы. Но отключать его вслепую нельзя: у части сайтов через XML-RPC всё ещё работают Jetpack, мобильное приложение WordPress и некоторые внешние сервисы.
Ниже — рабочий разбор: как понять, нужен ли вам XML-RPC, как отключить его через сервер или плагин, чем отличаются подходы и как проверить, что после изменений ничего не отвалилось.
Когда XML-RPC действительно стоит отключать
Сначала полезно понять, что именно вы хотите убрать. XML-RPC — это не «ещё один лишний файл», а отдельный интерфейс для удалённого доступа к сайту. Если вы не публикуете записи из мобильного приложения, не используете Jetpack для удалённой связи и не подключали сторонние сервисы, endpoint обычно можно закрыть без последствий.
Типичные признаки, что XML-RPC не нужен
- в логах сервера регулярно встречаются запросы к
/xmlrpc.php; - на сайте не используется Jetpack или его функции удалённой публикации;
- редакторы заходят в админку только через браузер;
- нет внешних интеграций, которые отправляют посты через XML-RPC;
- мобильное приложение WordPress не используется для публикации.
Когда отключать нельзя без проверки
Если сайт подключён к Jetpack, использует старые клиентские приложения или интеграции с публикацией через XML-RPC, отключение приведёт к ошибкам подключения. В этом случае сначала проверьте, чем именно пользуется команда, и только потом меняйте конфигурацию.
Диагностика: как понять, кто обращается к xmlrpc.php
Перед изменениями посмотрите, есть ли реальный трафик к endpoint. Это можно сделать по логам веб-сервера или через инструменты аналитики запросов. Важно не гадать, а увидеть, что именно происходит.
# Пример для nginx access.log
# Ищем обращения к xmlrpc.php
sudo grep "xmlrpc.php" /var/log/nginx/access.log
# Для Apache access.log
sudo grep "xmlrpc.php" /var/log/apache2/access.logЕсли запросы идут с одного и того же набора IP, это может быть автоматический перебор или сканирование. Если видите обращения от собственных сервисов, сначала проверьте, не ломает ли отключение рабочий сценарий.
Как отключить XML-RPC: сравнение способов
Есть три практических варианта: закрыть endpoint на уровне сервера, отключить его кодом в WordPress или использовать плагин. Выбор зависит от того, нужен ли вам полный запрет или более мягкая настройка.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| .htaccess / nginx | Нужен жёсткий запрет на уровне веб-сервера | Быстро, не зависит от темы и плагинов | Нужно аккуратно править конфиг, можно задеть другие правила |
| Код в functions.php или mu-plugin | Нужен контроль внутри WordPress | Гибко, легко откатить | Запрос всё равно доходит до WordPress |
| Плагин | Нужен простой способ без правки конфига | Удобно для админов без доступа к серверу | Лишняя зависимость от плагина |
Вариант 1: отключение через .htaccess
Если у вас Apache и сайт работает через .htaccess, можно запретить доступ к xmlrpc.php напрямую. Это самый жёсткий вариант: запросы будут отсекаться до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache 2.2 встречается вариант с Deny from all, но на современных серверах обычно нужен Require all denied. После правки не забудьте проверить, что файл .htaccess действительно читается сервером.
Вариант 2: отключение через код WordPress
Если вы не хотите трогать серверную конфигурацию, можно отключить XML-RPC через хук xmlrpc_enabled. Этот способ удобен, когда доступ к хостингу ограничен или сайт переносится между окружениями.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код лучше размещать в небольшом mu-plugin, а не в functions.php активной темы. Тогда он не пропадёт после смены темы и не смешается с оформлением.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Вариант 3: отключение через плагин
Если на сайте уже используется плагин для технической оптимизации, иногда проще включить нужную опцию там. Например, в Clearfy Pro есть инструменты для чистки и отключения лишних функций WordPress. Это удобно, когда вы хотите управлять такими настройками из одной панели, а не править код вручную.
Но принцип тот же: после включения опции нужно проверить, не используются ли интеграции, завязанные на XML-RPC.
Пошаговое решение без лишнего риска
Если нужен безопасный порядок действий, я бы делал так:
- Проверить логи на обращения к
xmlrpc.php. - Убедиться, что сайт не использует Jetpack и внешние публикации через XML-RPC.
- Выбрать способ отключения: сервер, код или плагин.
- Внести изменение сначала на staging, если он есть.
- Проверить ответ endpoint и работу связанных сервисов.
- Только потом переносить изменение на продакшен.
Если нужен мягкий сценарий
Иногда не хочется полностью закрывать endpoint, а нужно лишь убрать самые опасные методы. В таком случае лучше не писать самодельные фильтры наугад: можно случайно сломать легитимный запрос. На практике чаще выбирают либо полный запрет, либо точечное ограничение через серверные правила и проверку интеграций.
Как проверить, что отключение сработало
Самая простая проверка — открыть /xmlrpc.php в браузере или отправить запрос через curl. Если endpoint закрыт, вы должны увидеть отказ в доступе или другой явный ответ в зависимости от способа блокировки.
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали через .htaccess, часто будет 403 Forbidden. Если отключали через фильтр WordPress, ответ может отличаться, но важен сам факт, что удалённый вызов больше не работает.
Проверка связанных функций
- попробуйте войти в Jetpack, если он установлен;
- проверьте публикацию из мобильного приложения WordPress;
- посмотрите, не появились ли ошибки в логах после изменения;
- убедитесь, что обычная авторизация и админка работают как раньше.
Если что-то сломалось, откатите изменение и проверьте, какой сервис использовал XML-RPC. Обычно проблема не в WordPress как таковом, а в забытом внешнем подключении.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это самый частый сценарий. Решение простое: либо вернуть XML-RPC, либо отказаться от функций Jetpack, которые завязаны на удалённое соединение. Если Jetpack нужен только ради статистики или части модулей, проверьте, есть ли для них альтернативы без XML-RPC.
Добавили правило в .htaccess, но ничего не изменилось
Причина обычно в том, что сайт работает не на Apache, а на nginx, либо .htaccess вообще не читается сервером. В этом случае правило нужно переносить в конфигурацию nginx или использовать отключение через WordPress-код.
Сломали доступ к xmlrpc.php, но не проверили интеграции
Нельзя считать задачу выполненной только по факту закрытого endpoint. После изменения всегда проверяйте реальные сценарии: публикацию, синхронизацию, подключённые сервисы. Иначе проблема всплывёт позже, когда редактор попытается отправить материал из внешнего клиента.
Положили код в тему, а потом потеряли его при обновлении
Если отключение сделано в functions.php, оно исчезнет при смене темы. Для технических ограничений лучше использовать mu-plugin или отдельный маленький плагин. Это надёжнее и проще для сопровождения.
Что ещё стоит сделать для безопасности
Отключение XML-RPC уменьшает поверхность атаки, но не заменяет нормальную защиту входа. Если на сайте регулярно идут попытки подбора пароля, проверьте лимиты логина, двухфакторную аутентификацию для админов и актуальность обновлений ядра, темы и плагинов.
- обновляйте WordPress и плагины без задержек;
- не держите лишние учётные записи с правами администратора;
- используйте сложные пароли и 2FA, если это возможно;
- следите за логами 403 и 401, а не только за визуальным состоянием сайта.
Если вам нужен более широкий набор технических настроек — очистка лишних функций, отключение дублей и упрощение конфигурации — такие задачи обычно удобнее решать централизованно, а не набором разрозненных сниппетов.
Когда лучше не отключать XML-RPC полностью
Полный запрет не всегда лучший вариант. Если у команды есть рабочий сценарий публикации через мобильное приложение или внешний сервис, безопаснее сначала ограничить доступ на уровне IP, проверить журнал запросов и только потом принимать решение. В технической поддержке сайта это обычно экономит время: меньше откатов и меньше неожиданных поломок.
Если же XML-RPC не используется вообще, его отключение — нормальная и вполне оправданная мера. Главное здесь не сам факт блокировки, а аккуратная проверка зависимостей до и после изменения.