XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, внешние публикации и старые мобильные клиенты. Проблема в том, что это не просто лишний файл xmlrpc.php, а отдельный канал удалённого доступа, который может быть нужен конкретным интеграциям. Поэтому правильный вопрос звучит не «как выключить», а «что именно у меня использует XML-RPC и чем это заменить».
Если на сайте нет старых приложений, удалённой публикации и интеграций, которые завязаны на XML-RPC, его можно отключить без потерь. Но сначала стоит проверить, не используется ли он косвенно. Ниже — рабочая схема: диагностика, варианты отключения, проверка результата и типовые ошибки.
Когда XML-RPC действительно стоит отключать
XML-RPC имеет смысл отключать, если сайт не использует удалённую публикацию, старые мобильные приложения WordPress и сторонние сервисы, которым нужен этот протокол. На практике его часто оставляют включённым просто потому, что он есть по умолчанию. Это не всегда критично, но лишняя поверхность атаки и лишние запросы к xmlrpc.php точно не помогают.
Особенно осторожно нужно быть, если на сайте уже есть:
- подключённый Jetpack;
- мобильное приложение WordPress для публикации;
- интеграция с внешним сервисом, который отправляет посты через XML-RPC;
- старый плагин автопостинга или синхронизации.
Что ломается чаще всего
Самая частая ошибка — отключить XML-RPC на уровне сервера и потом искать проблему в плагинах. Внешне это выглядит как «не публикуются записи», «Jetpack не подключается» или «мобильное приложение не авторизуется». Если вы не уверены, сначала проверьте логи интеграций и список подключённых сервисов, а уже потом режьте доступ.
Диагностика: используется ли xmlrpc.php на вашем сайте
Перед изменениями проверьте, есть ли обращения к /xmlrpc.php. Это можно сделать по логам веб-сервера, в аналитике безопасности или через быстрый запрос снаружи. Если серверный лог доступен, ищите строки с этим путём и смотрите, откуда идут запросы и с какой частотой.
Минимальный чек-лист диагностики:
- проверить логи Nginx или Apache на обращения к
xmlrpc.php; - посмотреть, подключён ли Jetpack и какие модули он использует;
- проверить, есть ли внешние сервисы автопубликации;
- убедиться, что никто не использует старое мобильное приложение WordPress для публикации;
- сделать тестовый запрос к
xmlrpc.phpпосле отключения на staging.
Если у вас есть доступ к командной строке, можно быстро проверить ответ сервера:
curl -I https://example.com/xmlrpc.phpНормальный ответ до отключения обычно будет не 404, а что-то вроде 405 или 200 с текстом о том, что XML-RPC сервер принимает только POST-запросы. После блокировки поведение должно измениться в зависимости от способа отключения: либо 403, либо 404, либо пустой ответ от правила на уровне сервера.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, нужен ли вам полный запрет или достаточно ограничить доступ. Для большинства сайтов достаточно отключить XML-RPC на уровне WordPress. Если нужен жёсткий запрет, лучше добавить правило на сервере.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Хук в WordPress | Нужен быстрый и обратимый вариант | Легко откатить, не требует доступа к серверу | Запрос всё равно доходит до WordPress |
| Правило в Nginx/Apache | Нужен жёсткий запрет | Режет трафик раньше PHP | Нужно править конфиг сервера |
| Плагин безопасности | Нужен интерфейс без кода | Удобно для админов | Добавляет ещё один слой логики |
Вариант 1: отключение через functions.php или mu-plugin
Если вы управляете кодом сайта, самый предсказуемый способ — убрать поддержку XML-RPC через фильтр xmlrpc_enabled. Лучше не класть это в тему, если тема может меняться; безопаснее использовать mu-plugin.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код отключает сам механизм XML-RPC внутри WordPress. Это удобно, если вам нужно быстро проверить влияние на интеграции и при необходимости вернуть всё назад одной правкой.
Вариант 2: блокировка на уровне Nginx
Если вы хотите не отдавать xmlrpc.php вообще, добавьте отдельное правило в конфиг Nginx. Это полезно, когда на сайт идёт много мусорных запросов и вы хотите отсечь их до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После правки конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. Для Nginx это обычно делается через nginx -t и затем reload. Если у вас нет доступа к серверу, этот вариант пропускайте и используйте хук или плагин.
Вариант 3: блокировка в Apache через .htaccess
На Apache можно закрыть файл через .htaccess. Это не самый изящный вариант, но он работает там, где нет доступа к основному конфигу.
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает на старой версии Apache, вместо Require all denied иногда встречается синтаксис с Deny from all. Но если у вас современный стек, лучше использовать актуальный вариант.
Как отключить XML-RPC через плагин
Если нужен интерфейс без правки кода, используйте плагин безопасности, который умеет отключать XML-RPC. Важно не ставить несколько плагинов с одинаковой функцией одновременно: тогда вы получите конфликт правил и ложные срабатывания в диагностике. Если у вас уже установлен комплексный плагин для чистки и SEO-настроек, например Clearfy Pro, проверьте, есть ли в нём отдельная опция для XML-RPC и отключения лишних сервисов. Это удобнее, чем держать несколько узких плагинов ради одной настройки.
При выборе плагина смотрите не на обещания, а на конкретику:
- есть ли отдельный переключатель XML-RPC;
- можно ли исключить Jetpack или другие интеграции;
- не добавляет ли плагин лишние редиректы и блокировки;
- есть ли понятный способ отката.
Проверка результата после внедрения
После отключения нужно проверить не только сам xmlrpc.php, но и связанные сценарии. Иначе можно решить, что всё работает, а потом получить жалобу от редактора или сервиса автопостинга.
Что проверить вручную
- открывается ли
https://ваш-домен/xmlrpc.phpи какой код ответа возвращается; - работает ли вход в админку и публикация записей из панели WordPress;
- не потерял ли связь Jetpack, если он используется;
- не сломалась ли отправка контента из внешнего сервиса;
- нет ли ошибок в логах PHP и веб-сервера после изменения.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/xmlrpc.php
curl -s https://example.com/xmlrpc.php | headЕсли вы блокировали файл на уровне сервера, ожидайте 403 или 404. Если отключали через WordPress-хук, ответ может зависеть от окружения, но сам XML-RPC должен перестать принимать рабочие запросы.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Jetpack в некоторых сценариях использует XML-RPC для связи с сайтом. Если он нужен, не рубите доступ полностью. Либо оставьте XML-RPC включённым, либо проверьте, можно ли ограничиться серверным правилом только для части запросов — но это уже зависит от конкретной интеграции и обычно требует теста на staging.
Сломали внешнюю публикацию из мобильного приложения
Если редакторы публикуют через старое приложение WordPress, отключение XML-RPC сразу это остановит. Решение простое: либо вернуть доступ, либо перевести команду на публикацию через админку и современный рабочий процесс. Перед изменением лучше предупредить всех, кто реально пользуется этим каналом.
Поставили два плагина, которые блокируют одно и то же
Такое часто происходит после установки «плагина безопасности» поверх уже существующего решения. В итоге один плагин блокирует запрос, второй пишет об ошибке, а причина неочевидна. Оставьте один источник правды: либо код, либо сервер, либо один плагин.
Проверили только главную страницу и успокоились
XML-RPC не влияет на фронтенд напрямую. Поэтому сайт может выглядеть нормально, хотя интеграции уже сломаны. Проверяйте именно сценарии, связанные с удалённой публикацией и внешними сервисами.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC само по себе не заменяет базовую защиту. Если цель — уменьшить шум и поверхность атаки, параллельно проверьте:
- ограничение частоты запросов к
wp-login.php; - наличие двухфакторной аутентификации для админов;
- актуальность ядра, тем и плагинов;
- отсутствие лишних REST-эндпоинтов от неиспользуемых плагинов;
- наличие нормальных бэкапов перед изменениями на сервере.
Если сайт часто получает мусорные обращения к xmlrpc.php, блокировка на уровне веб-сервера обычно полезнее для производительности, чем отключение только в WordPress. PHP просто не будет тратить ресурсы на обработку запроса.
Если нужен быстрый и обратимый вариант без правки кода, можно использовать плагин. Если нужен контроль над лишними сервисами и дублями настроек, удобнее держать это в одном инструменте, а не распылять по нескольким расширениям. Главное — после любого изменения проверить реальные сценарии, а не только URL файла.