XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестало работать мобильное приложение, внешняя публикация или интеграция с сервисом, который использует старый протокол. На практике задача не в том, чтобы просто закрыть xmlrpc.php, а в том, чтобы понять, нужен ли он вообще, и отключить его так, чтобы не задеть рабочие сценарии.
Ниже — разбор без лишней теории: как диагностировать зависимость от XML-RPC, чем его отключать, как проверить результат и какие ошибки встречаются чаще всего.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешнюю публикацию через старые клиенты, мобильное приложение WordPress, Jetpack в режиме, завязанном на XML-RPC, или сторонние сервисы, которые до сих пор ходят в xmlrpc.php, этот интерфейс обычно только увеличивает поверхность атаки. Его часто используют для перебора паролей и pingback-спама. Но отключение должно быть осознанным: сначала проверьте, есть ли реальные обращения к этому файлу.
Быстрая диагностика
Самый простой способ — посмотреть логи веб-сервера или статистику запросов. Если в access log регулярно встречается /xmlrpc.php, это уже сигнал, что файл не просто «висит в системе», а кто-то его дергает. Если у вас есть доступ к консоли, можно быстро отфильтровать обращения:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Если логов нет, проверьте, не используете ли вы:
- мобильное приложение WordPress для публикации;
- Jetpack и его старые сценарии подключения;
- сервисы автопостинга, которые не умеют работать через REST API;
- внешние редакторы и CMS-агрегаторы, настроенные на XML-RPC.
Если хоть один из этих пунктов актуален, отключать протокол «в лоб» нельзя — сначала нужно заменить интеграцию или убедиться, что она не зависит от него.
Чем отключать: плагин, код или сервер
Есть три рабочих подхода. Выбор зависит от того, где вы хотите держать контроль: в коде темы/плагина, в админке или на уровне веб-сервера.
| Способ | Когда подходит | Минусы |
|---|---|---|
Код через functions.php или mu-plugin | Нужен предсказуемый контроль без лишних плагинов | Нужно не забыть про обновления темы и порядок загрузки |
| Плагин безопасности | Нужно быстро закрыть XML-RPC без правки кода | Добавляет еще один слой логики и зависимость от плагина |
| Правило на сервере | Нужно отрезать доступ до WordPress еще до PHP | Требует доступа к конфигу Nginx/Apache и аккуратности |
Если у вас управляемый сайт и вы не хотите плодить плагины, чаще всего удобнее использовать небольшой mu-plugin. Если нужен быстрый результат без разработки — подойдет плагин. Если сайт под атакой и вы хотите снизить нагрузку до запуска PHP, лучше блокировать запросы на уровне сервера.
Отключение XML-RPC через код
Самый понятный вариант — вернуть false в фильтре xmlrpc_enabled. Это отключает сам механизм XML-RPC, но не ломает остальной WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если вы добавляете это в functions.php, помните: при смене темы правило исчезнет. Для постоянной защиты лучше создать mu-plugin, чтобы он не зависел от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если каталога mu-plugins нет, создайте его вручную. Такой вариант хорош тем, что не требует активации в админке и не теряется после обновления темы.
Что делать с pingback и trackback
Даже если XML-RPC отключен, имеет смысл отдельно убрать pingback-логику, если она вам не нужна. Это снижает шум и убирает лишние точки входа в комментариях и метаданных. В админке можно отключить уведомления о ссылках, а на уровне кода — не использовать pingback-функциональность в шаблонах и настройках обсуждения.
Если сайт старый, проверьте, не включены ли trackback/pingback для уже опубликованных записей. Это не всегда связано с XML-RPC напрямую, но часто идет рядом и создает ложное ощущение, что «все защищено», хотя часть поверхности атаки остается.
Отключение через плагин безопасности
Если код трогать не хочется, можно использовать плагин, который умеет отключать XML-RPC. Важно не искать «магический» плагин только ради одной опции: лучше брать решение, где это одна из штатных функций, а не отдельная сомнительная надстройка. Например, в Clearfy Pro есть инструменты для технической чистки WordPress и отключения лишних функций; если у вас уже стоит такой плагин, это может быть удобнее, чем добавлять еще один узкоспециализированный.
Но плагин — это компромисс. Он удобен, пока вы контролируете его обновления и понимаете, что именно он меняет. После установки обязательно проверьте, не выключил ли он что-то лишнее: некоторые плагины безопасности любят объединять несколько настроек в один переключатель.
Блокировка XML-RPC на сервере
Если задача — не просто отключить функцию, а уменьшить нагрузку от массовых запросов, блокировка на уровне Nginx или Apache сработает раньше, чем WordPress вообще начнет выполнять PHP-код.
Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой блок лучше добавлять в конфигурацию сайта, а не в общий шаблон без проверки. После правки конфигурации не забудьте проверить синтаксис и перезагрузить Nginx.
nginx -t
systemctl reload nginxApache
<Files "xmlrpc.php">
Require all denied
</Files>Для Apache важно, где именно лежит правило: в виртуальном хосте, в .htaccess или в отдельном include-файле. Если у вас включены ограничения на запись в .htaccess, править лучше конфиг виртуального хоста.
Проверка результата после внедрения
После отключения не ограничивайтесь открытием главной страницы. Нужно проверить именно точку входа, которую вы закрывали.
- Откройте
/xmlrpc.phpв браузере — в идеале должен быть отказ в доступе или пустой ответ без признаков работы XML-RPC. - Проверьте логи: обращений к
xmlrpc.phpпосле внедрения должно стать либо ноль, либо они должны завершаться отказом до PHP. - Если использовали код, убедитесь, что сайт не выдает ошибок на фронтенде и в админке.
- Если у вас есть интеграция с внешним сервисом, протестируйте ее отдельно: публикация, обновление записи, синхронизация медиа или комментариев.
Дополнительно можно проверить ответ командой curl:
curl -I https://example.com/xmlrpc.phpЕсли блокировка сделана на сервере, вы увидите отказ на уровне HTTP. Если отключение идет через WordPress, ответ может отличаться в зависимости от конфигурации, но сам XML-RPC должен быть недоступен для рабочих сценариев.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать интеграция
Значит, вы не проверили зависимость заранее. Решение простое: либо вернуть XML-RPC, либо перевести интеграцию на REST API, если сервис это поддерживает. Не пытайтесь «починить» проблему, открывая доступ всем подряд.
Добавили код в тему и забыли про обновление
Если правило лежит в functions.php, оно исчезнет при смене темы. Для системной настройки используйте mu-plugin или отдельный мини-плагин.
Заблокировали xmlrpc.php на сервере, но атаки продолжаются
Это нормально: сканеры будут продолжать стучаться, но уже не будут нагружать WordPress. Проверьте, что запросы действительно режутся до PHP, и при необходимости добавьте rate limiting на уровне сервера или CDN.
Сломали мобильное приложение WordPress
Мобильное приложение и некоторые внешние клиенты могут использовать XML-RPC в старых сценариях. Если это ваш рабочий инструмент, не отключайте протокол без замены процесса публикации.
Что еще стоит сделать для безопасности и производительности
Отключение XML-RPC полезно, но не заменяет базовую гигиену. Если вы уже занимаетесь технической чисткой сайта, проверьте еще несколько вещей:
- ограничьте число попыток входа в админку;
- уберите неиспользуемые плагины и темы;
- проверьте, не открыт ли REST API для лишних публичных данных;
- включите нормальный кеш страниц и объектов, если сайт его поддерживает;
- следите за логами 404 и подозрительными POST-запросами.
Если вам нужен набор технических отключений и чистка лишнего функционала без ручного перебора десятка настроек, удобно держать это в одном инструменте, а не разносить по нескольким плагинам. Но даже в этом случае проверка после изменений обязательна: WordPress редко ломается сразу, чаще проблема проявляется в конкретной интеграции или сценарии публикации.
Практический критерий простой: если после отключения XML-RPC сайт работает как раньше, внешние интеграции не отвалились, а запросы к xmlrpc.php больше не проходят, задача решена. Если что-то перестало работать — не ищите обходные пути, а сначала выясните, кто именно использовал этот протокол и можно ли заменить его на REST API или другой поддерживаемый способ связи.