XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации, некоторые интеграции и старые сервисы автопостинга. Если задача не в полном отказе от удалённого доступа, а в контролируемом отключении лишнего функционала, лучше сначала понять, что именно использует xmlrpc.php, и только потом резать доступ.
Когда XML-RPC действительно можно отключать
Отключение имеет смысл, если сайт не использует старые внешние клиенты и интеграции, которым нужен XML-RPC. Для обычного блога, корпоративного сайта или лендинга этот интерфейс часто не нужен. Но если у вас есть публикация через сторонний редактор, синхронизация с сервисом или старое мобильное приложение WordPress, сначала проверьте зависимость.
Что обычно ломается первым
Чаще всего проблемы проявляются не сразу. Сайт открывается, админка работает, но перестают проходить удалённые запросы. Типичные симптомы:
- ошибка авторизации в стороннем приложении;
- не отправляются записи из внешнего редактора;
- интеграция с сервисом публикации возвращает 401 или 403;
- в логах появляются запросы к
/xmlrpc.phpс отказом в доступе.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями посмотрите, есть ли реальные обращения к файлу. Если доступ к логам веб-сервера есть, это самый надёжный способ. В access log ищите запросы к xmlrpc.php и смотрите user-agent, IP и частоту.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, можно временно включить просмотр на уровне сервера или использовать плагины мониторинга запросов, но для рабочей проверки лог веб-сервера полезнее: он показывает, кто именно стучится и как часто.
Быстрая проверка через браузер и curl
Откройте https://example.com/xmlrpc.php. Если интерфейс доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что его нужно оставлять включённым, но подтверждает, что файл доступен извне.
curl -I https://example.com/xmlrpc.phpПосле отключения ожидаемым результатом будет 403, 404 или другой отказ на уровне сервера/WordPress — в зависимости от выбранного способа блокировки.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, насколько жёстко вы хотите закрыть доступ. Если нужен быстрый и обратимый способ, подойдёт фильтр в теме или мини-плагине. Если нужен сетевой запрет, лучше блокировать на уровне веб-сервера. Плагин имеет смысл только тогда, когда вам нужен интерфейс управления без правки кода.
| Способ | Когда использовать | Плюс | Минус |
|---|---|---|---|
| Код в WordPress | Нужен быстрый и обратимый контроль | Просто откатить | Запрос всё равно доходит до WordPress |
| .htaccess / nginx | Нужно отсечь запросы раньше PHP | Лучше для производительности | Нужно аккуратно править конфиг |
| Плагин безопасности | Нет доступа к конфигам и нужен UI | Удобно для админов | Лишняя зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Если вы хотите оставить возможность быстро вернуть всё назад, добавьте фильтр в functions.php дочерней темы или в небольшой mu-plugin. Этот способ блокирует работу XML-RPC на уровне WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более точечный запрет, можно отключить только опасные методы, но для большинства сайтов это избыточно. Когда цель — убрать сам интерфейс, достаточно полного отключения.
Вариант 2: блокировка на уровне nginx
Если сайт работает на nginx, лучше отрезать доступ к xmlrpc.php до передачи запроса в PHP. Это снижает лишнюю нагрузку и не даёт скрипту отрабатывать вообще.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите nginx штатной командой вашей системы. Не вносите такие правила в случайный include-файл без понимания, как он подключается к сайту.
Вариант 3: блокировка через .htaccess
Для Apache и совместимых конфигураций можно закрыть файл через .htaccess. Это рабочий вариант, если у вас нет доступа к основному конфигу сервера.
<Files "xmlrpc.php">
Require all denied
</Files>Если сервер старый и использует Apache 2.2, синтаксис может отличаться, но на современных установках лучше ориентироваться на Require all denied.
Пошаговое решение без поломки интеграций
- Проверьте логи и убедитесь, что
xmlrpc.phpне используется нужными сервисами. - Если есть сомнения, сначала отключите XML-RPC на тестовой копии сайта.
- Выберите способ блокировки: код, nginx, Apache или плагин.
- После изменения проверьте ответ
/xmlrpc.phpчерез браузер иcurl. - Проверьте внешние сервисы, которые могли использовать удалённую публикацию или авторизацию.
Проверка результата после внедрения
Нельзя ограничиваться тем, что сайт «открылся без ошибки». Нужно проверить именно то, что вы отключали.
- Откройте
/xmlrpc.phpв браузере — доступ должен быть закрыт или не давать рабочий XML-RPC ответ. - Запустите
curl -I https://example.com/xmlrpc.phpи посмотрите код ответа. - Проверьте логи веб-сервера: новых успешных обращений к файлу быть не должно.
- Если есть внешние сервисы публикации, выполните тестовый вход или тестовую отправку записи.
Если после отключения сайт начал отдавать 500, значит правило добавлено не туда или с ошибкой синтаксиса. В таком случае первым делом откатите последнее изменение и проверьте конфиг сервера или PHP-файл на лишние символы.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать интеграция
Это означает, что сервис действительно использовал XML-RPC. Решение не в том, чтобы «оставить всё как было», а в том, чтобы заменить интеграцию на REST API или другой поддерживаемый способ. Если сервис устаревший, лучше мигрировать, чем держать открытый XML-RPC ради одного сценария.
Добавили код в тему, а после обновления он пропал
Так бывает, если правка внесена в родительскую тему. Для постоянных изменений используйте дочернюю тему или mu-plugin. Иначе при обновлении вы потеряете блокировку и снова откроете доступ.
Закрыли файл на сервере, но WordPress всё равно отвечает
Проверьте, не стоит ли перед сайтом CDN, reverse proxy или кеширующий слой с собственными правилами. Иногда запросы доходят не напрямую до origin, и вы видите старое поведение из-за кеша или отдельной конфигурации виртуального хоста.
Поставили плагин и забыли про него
Плагин для одной простой задачи — это рабочее, но не всегда лучшее решение. Если плагин давно не обновлялся или делает больше, чем нужно, он становится лишней точкой риска. Для точечного отключения XML-RPC код или серверное правило обычно чище.
Что проверить по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает лишнюю поверхность атаки. Это полезно, если у вас нет потребности в удалённом доступе. При этом не стоит смешивать эту задачу с защитой админки, ограничением логина или отключением pingbacks — это разные механизмы.
- Если нужен только запрет на pingbacks, не блокируйте весь XML-RPC без необходимости.
- Если сайт под нагрузкой, лучше закрывать доступ на уровне nginx или Apache, а не через PHP.
- Если в проекте есть несколько администраторов, зафиксируйте, какие внешние сервисы разрешены, чтобы блокировка не стала сюрпризом.
Для сайтов, где нужно одновременно чистить технический шум, отключать лишние функции и не лезть в код вручную, иногда удобнее использовать набор точечных настроек в плагинах вроде Clearfy Pro, но только если это действительно экономит время и не усложняет поддержку. Смысл не в плагине как таковом, а в том, чтобы не держать на сайте лишний функционал без причины.