XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, удалённая публикация или сторонний сервис, который всё ещё ходит в xmlrpc.php. Если задача не в абстрактной «безопасности», а в контролируемом отключении лишнего входа, действовать нужно по схеме: сначала понять, кто реально использует XML-RPC, потом отключить его так, чтобы не сломать нужные интеграции.
Ниже — практический сценарий для сайта, где вы хотите убрать лишнюю поверхность атаки и при этом не потерять рабочие подключения.
Когда XML-RPC действительно можно отключать
Если сайт редактируется только из админки WordPress, а внешние сервисы не публикуют записи и не синхронизируют данные через XML-RPC, этот интерфейс обычно не нужен. Но есть типовые исключения:
- мобильное приложение WordPress;
- старые клиенты для удалённой публикации;
- Jetpack и похожие сервисы, если они используют XML-RPC для части функций;
- внешние системы автопостинга и мониторинга;
- интеграции, которые работают не через REST API, а через старый XML-RPC endpoint.
Если вы не уверены, не отключайте его «вслепую». Сначала проверьте логи доступа и список интеграций.
Диагностика: кто обращается к xmlrpc.php
Самый полезный шаг — посмотреть, есть ли реальные запросы к /xmlrpc.php. На уровне веб-сервера это видно быстро. Для Nginx можно временно отфильтровать access log:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, принцип тот же — ищите обращения к xmlrpc.php в access log. Важно смотреть не только факт запросов, но и IP, user-agent и частоту. Если запросы идут от знакомого сервиса, это уже повод не рубить доступ сразу.
Что проверить в WordPress-админке
- используется ли мобильное приложение WordPress;
- подключён ли Jetpack и какие модули активны;
- есть ли плагины автопостинга, кросспостинга или синхронизации;
- настроены ли внешние редакторы и публикация по API;
- есть ли старые интеграции, которые давно забыли, но они всё ещё работают.
Если сайт небольшой и всё редактирование идёт вручную, чаще всего XML-RPC можно отключать без последствий. Но проверка всё равно нужна: на практике ломается не сам WordPress, а одна забытая интеграция.
Как отключить XML-RPC: сравнение подходов
Есть три рабочих варианта. Выбор зависит от того, хотите ли вы просто закрыть endpoint или сделать это на уровне приложения.
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Блокирует запросы к xmlrpc.php | Быстро, без правки кода | Добавляет зависимость, не всегда прозрачно |
| Код в теме или mu-plugin | Отключает XML-RPC на уровне WordPress | Контролируемо, без лишних плагинов | Нужен доступ к файлам |
| Правило веб-сервера | Отсекает запросы до WordPress | Минимальная нагрузка | Нужно аккуратно не задеть нужные сервисы |
Если нужен предсказуемый вариант без тяжёлых решений, обычно достаточно кода в mu-plugin или небольшого сниппета. Если доступ к серверу есть, блокировка на уровне Nginx/Apache ещё лучше, потому что WordPress даже не стартует на таких запросах.
Пошаговое решение через код
Самый безопасный путь для большинства сайтов — отключить XML-RPC через фильтр. Добавьте код в functions.php дочерней темы или, лучше, в mu-plugin, чтобы он не зависел от темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC интерфейс WordPress. Если кто-то попытается обратиться к xmlrpc.php, WordPress не будет обслуживать такие запросы как рабочие.
Если нужно не отключить, а заблокировать доступ жёстче
Иногда удобнее сразу возвращать 403 на уровне WordPress. Это полезно, если вы хотите явно видеть, что доступ запрещён, и не оставлять поведение на усмотрение ядра.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Но на практике первый вариант обычно проще и чище. Второй имеет смысл, если вы отлаживаете поведение или хотите более явный ответ для логов и внешних систем.
Блокировка на уровне Nginx или Apache
Если вы управляете сервером, можно закрыть xmlrpc.php ещё до загрузки WordPress. Это снижает лишнюю нагрузку и уменьшает риск перебора запросов.
Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой блок не должен ломать обычную работу сайта, если вы точно не используете XML-RPC. Если есть сомнения, сначала проверьте логи и только потом включайте правило.
Apache
<Files "xmlrpc.php">
Require all denied
</Files>После изменения конфигурации не забудьте перезагрузить веб-сервер и проверить, что правило действительно применилось.
Как проверить, что решение сработало
Проверка должна быть не «страница открывается», а именно по endpoint’у XML-RPC.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере. - Проверьте ответ сервера: при блокировке это не должен быть обычный рабочий ответ XML-RPC.
- Посмотрите access log: запросы должны либо исчезнуть, либо получать отказ.
- Если есть внешний сервис, который раньше использовал XML-RPC, протестируйте его отдельно.
Для быстрой проверки можно отправить простой POST-запрос:
curl -i -X POST https://example.com/xmlrpc.phpЕсли вы отключили XML-RPC корректно, ответ не должен выглядеть как рабочий канал для удалённой публикации.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина обычно в том, что Jetpack всё ещё использует XML-RPC для части функций на конкретной установке. Решение простое: либо вернуть доступ, либо перевести нужную интеграцию на другой сценарий, если он поддерживается. Не отключайте endpoint, пока не проверили реальные зависимости.
Сломали мобильное приложение WordPress
Это ожидаемо, если вы действительно пользовались публикацией через приложение. Если мобильный вход нужен, XML-RPC нельзя рубить без замены. В таком случае лучше ограничить доступ по IP или оставить endpoint включённым, но усилить защиту входа и мониторинг.
Добавили код в тему, а после обновления он пропал
Это классическая ошибка. Для таких задач лучше использовать mu-plugin или отдельный мини-плагин. Тогда отключение не исчезнет после смены темы.
Закрыли xmlrpc.php, но атаки в логах остались
Это нормально: сканеры продолжают стучаться в популярные endpoint’ы. Важно, чтобы запросы не доходили до WordPress и не создавали лишнюю нагрузку. Если запросов много, блокировка на уровне веб-сервера предпочтительнее.
Практические советы по безопасности и производительности
Отключение XML-RPC — не замена нормальной защите сайта. Если цель именно снизить риск, проверьте ещё несколько вещей:
- ограничьте попытки входа в админку;
- включите двухфакторную аутентификацию для администраторов, если это поддерживается;
- обновляйте ядро, темы и плагины;
- не держите лишние интеграции «на всякий случай»;
- следите за access log и 403/401-ошибками, если сайт часто сканируют.
Если вы используете плагин для чистки и отключения лишнего, посмотрите на Clearfy Pro: у него есть инструменты для отключения части лишнего функционала и технической оптимизации. Но даже в этом случае сначала проверьте зависимости, а уже потом выключайте endpoint.
Когда XML-RPC лучше не трогать
Есть ситуации, где отключение принесёт больше проблем, чем пользы. Например, если сайт живёт на внешней публикации, интеграциях старого типа или в связке с сервисами, которые вы не можете быстро заменить. В таких случаях лучше не делать резких движений: сначала инвентаризация интеграций, потом тест на staging, и только после этого — изменения на продакшене.
Если нужен именно безопасный сценарий, а не «выключить всё подряд», подход должен быть таким: проверить, кто использует endpoint, отключить его кодом или на сервере, затем подтвердить результат по логам и тестовому запросу. Это быстрее, чем потом откатывать поломанные интеграции.