XML-RPC в WordPress часто отключают по одной причине: через него удобно стучаться ботам, подбирать пароли и перегружать сайт лишними запросами. Но у этого механизма есть и легитимные сценарии — мобильное приложение WordPress, Jetpack, некоторые внешние публикации и старые интеграции. Поэтому задача не в том, чтобы просто «запретить всё», а в том, чтобы понять, используется ли XML-RPC у вас сейчас, и отключить его без побочных эффектов.
Когда XML-RPC действительно стоит отключать
Если вы не публикуете записи из мобильного приложения WordPress, не используете Jetpack для удалённых функций и не подключали старые сервисы через XML-RPC, этот интерфейс обычно можно закрыть. На практике он редко нужен современному сайту, а вот лишнюю поверхность атаки создаёт регулярно.
Особенно это заметно, если в логах сервера появляются запросы к /xmlrpc.php, а в панели безопасности — попытки system.multicall или перебора учётных данных. Это не всегда означает взлом, но почти всегда означает, что endpoint виден извне и его проверяют автоматические сканеры.
Что именно ломается при отключении
Чаще всего страдают не «обычные» страницы сайта, а внешние сценарии:
- мобильное приложение WordPress перестаёт публиковать записи;
- Jetpack может потерять часть функций подключения;
- старые сервисы автопостинга и интеграции больше не смогут отправлять контент;
- некоторые плагины для удалённой публикации начнут выдавать ошибки авторизации.
Если у вас нет таких сценариев, отключение обычно проходит безболезненно. Если есть — сначала проверьте, можно ли перевести интеграцию на REST API или другой современный способ подключения.
Диагностика: используется ли XML-RPC сейчас
Перед изменениями не полагайтесь на предположения. Проверьте три вещи: логи, плагины и внешние подключения.
- Откройте логи веб-сервера и посмотрите, есть ли обращения к
xmlrpc.php. - Проверьте, установлен ли Jetpack и какие функции он реально использует.
- Вспомните, есть ли у редакции мобильные приложения WordPress или сторонние сервисы публикации.
Если доступа к логам нет, можно хотя бы вручную проверить URL https://ваш-домен/xmlrpc.php. В норме файл может отвечать не так, как обычная страница, но сам факт доступности endpoint уже важен: его видят и могут атаковать.
Быстрая проверка через curl
С технической стороны удобнее всего проверить ответ сервера напрямую:
curl -I https://example.com/xmlrpc.phpЕсли вы уже отключили XML-RPC, сервер должен отвечать так, чтобы endpoint не работал как рабочий интерфейс WordPress. Но ориентируйтесь не только на код ответа, а на поведение сайта и наличие реальных интеграций.
Как отключить XML-RPC: три рабочих варианта
Есть три подхода: через код, через сервер и через плагин. Универсального варианта нет — выбирайте тот, который проще сопровождать в вашей конфигурации.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Контроль, без лишних зависимостей | Нужно аккуратно обновлять | Если есть доступ к коду и нужен предсказуемый результат |
| Правило на сервере | Блокирует запросы до WordPress | Зависит от nginx/Apache | Если хотите снизить нагрузку и закрыть endpoint раньше PHP |
| Плагин безопасности | Быстро включить | Лишняя зависимость, иногда избыточно | Если нет доступа к коду или нужен временный вариант |
Вариант 1: отключение через код
Самый понятный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, если нет особых требований к серверной блокировке.
Вариант 2: блокировка на уровне nginx
Если сайт работает на nginx, можно отрезать запросы к xmlrpc.php ещё до запуска PHP. Это полезно, когда endpoint активно сканируют и вы хотите уменьшить нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить nginx. Если у вас несколько сайтов на одном сервере, убедитесь, что правило добавлено именно в нужный виртуальный хост.
Вариант 3: блокировка на уровне Apache
Для Apache обычно используют правила в .htaccess или конфигурации виртуального хоста. Вариант зависит от того, разрешён ли AllowOverride.
<Files xmlrpc.php>
Require all denied
</Files>Этот способ тоже рабочий, но проверяйте, что правило действительно применяется. На некоторых хостингах .htaccess может быть ограничен, и тогда блокировка не сработает так, как ожидается.
Проверка результата после внедрения
После отключения важно не ограничиваться «страница вроде не открывается». Проверьте именно те сценарии, которые могут пострадать.
- Откройте
/xmlrpc.phpв браузере и убедитесь, что endpoint больше не выполняет функции WordPress API. - Проверьте публикацию из мобильного приложения, если оно используется.
- Посмотрите, не ругается ли Jetpack на потерю соединения.
- Сравните логи до и после: обращения к
xmlrpc.phpмогут продолжаться, но они должны упираться в блокировку.
Если у вас есть мониторинг ошибок, посмотрите и его. Иногда после отключения всплывают неочевидные интеграции, о которых давно забыли: старый сервис автопостинга, CRM-скрипт или плагин, который был установлен «на всякий случай».
Что считать успешным результатом
Решение можно считать корректным, если одновременно выполняются три условия: обычный сайт работает, нужные интеграции не сломались, а xmlrpc.php больше не доступен как рабочий вход для внешних запросов.
Частые ошибки и как их исправить
Самая распространённая ошибка — отключить XML-RPC через код, а потом обнаружить, что редакция не может публиковать из мобильного приложения. В этом случае нужно не «откатывать всё», а сначала определить, какой именно сценарий использует endpoint, и заменить его на REST API или другой способ интеграции.
Вторая ошибка — блокировать только на уровне WordPress, но оставлять endpoint открытым на сервере. Это не ломает сайт, но и не убирает лишние запросы: PHP всё равно будет получать попытки обращения, а нагрузка и шум в логах останутся.
Третья ошибка — ставить несколько плагинов безопасности, которые одновременно трогают XML-RPC. В результате сложно понять, что именно сломало подключение. Если уже есть плагин, который умеет отключать XML-RPC, не дублируйте это ещё и кодом без необходимости.
Если нужен временный, а не постоянный запрет
Иногда XML-RPC отключают на время атаки или тестов. В таком случае лучше фиксировать изменение в заметках команды или в системе управления конфигурацией, чтобы потом не забыть, почему интеграция перестала работать. Иначе через месяц кто-то снова начнёт искать «ошибку в WordPress», хотя проблема была в намеренно закрытом endpoint.
Практические советы по безопасности и производительности
Если цель — не просто убрать одну точку входа, а снизить шум на сайте, смотрите шире. XML-RPC часто отключают вместе с другими лишними публичными механизмами: неиспользуемыми REST-маршрутами, открытыми страницами авторов, лишними версиями API и мусорными редиректами. Но делать это нужно точечно, а не массово «наугад».
Для сайтов, где важна техническая чистота, удобно сначала собрать список того, что реально используется, а потом отключать по одному элементу и проверять результат. Если у вас уже есть набор задач по чистке и SEO-оптимизации, часть таких вещей можно закрывать через инструменты вроде Clearfy Pro, но только если вы понимаете, какие именно функции вам нужны и не включаете всё подряд.
И ещё один практический момент: если вы закрываете XML-RPC на уровне сервера, не забудьте обновить документацию для команды. Через полгода кто-то обязательно спросит, почему мобильное приложение не публикует запись, и без заметки это превращается в лишнюю диагностику.
В итоге рабочая схема выглядит просто: сначала проверяете реальные зависимости, потом отключаете XML-RPC тем способом, который лучше подходит вашей инфраструктуре, и только после этого подтверждаете, что сайт не потерял нужные функции.