XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации, старые интеграции или сервисы автопостинга. На живом сайте это почти всегда вопрос не «включать или выключать», а «какие именно сценарии вам ещё нужны». Если оставить XML-RPC открытым без необходимости, вы получаете лишнюю поверхность атаки и шум в логах. Если отключить его грубо, можно сломать рабочие процессы редакции.
Ниже — практический сценарий: как понять, нужен ли вам XML-RPC, как отключить его безопасно, чем заменить в современных интеграциях и как проверить, что после изменения ничего не отвалилось.
Когда XML-RPC реально нужен, а когда его можно убрать
XML-RPC — старый механизм удалённого доступа к WordPress. Он до сих пор встречается в некоторых клиентах и сервисах, но в большинстве новых интеграций уже используется REST API. Поэтому первый шаг — не править код, а проверить, есть ли у вас зависимые сценарии.
Сценарии, где отключение обычно безопасно
- сайт редактируется только через админку WordPress;
- нет мобильного приложения WordPress для публикации;
- нет внешних сервисов, которые отправляют записи через XML-RPC;
- нет старых плагинов синхронизации, завязанных именно на
xmlrpc.php; - вы не используете pingback/trackback и не хотите держать их открытыми.
Сценарии, где сначала нужна проверка
- редакторы публикуют материалы из стороннего клиента;
- подключены сервисы автопостинга или репостинга;
- есть интеграция с внешней CMS или ERP старого поколения;
- на сайте давно не обновляли плагины и часть логики могла остаться на XML-RPC;
- вы не уверены, кто именно обращается к
/xmlrpc.phpв логах.
Если сайт давно переведён на REST API и внешних клиентов нет, XML-RPC обычно можно отключать. Но лучше делать это после короткой диагностики, а не по принципу «поставил плагин и забыл».
Диагностика: кто обращается к xmlrpc.php
Перед отключением посмотрите, есть ли реальные запросы к xmlrpc.php. Это можно сделать по логам веб-сервера, по журналам безопасности или временно через простой логирующий сниппет. Если у вас есть доступ к access.log, это самый честный источник: он покажет IP, частоту запросов и код ответа.
Пример поиска в логах Nginx:
grep "xmlrpc.php" /var/log/nginx/access.logЕсли вы видите только редкие сканирующие запросы с кодами 404 или 403, это один сценарий. Если там есть регулярные обращения от знакомых сервисов или ваших офисных IP — это уже повод не рубить доступ сразу.
Для быстрой проверки на самом сайте можно временно добавить логирование в functions.php дочерней темы или в мини-плагин. Это не постоянное решение, а способ понять, кто и как стучится в endpoint.
add_action('xmlrpc_call', function ($method) {
error_log('XML-RPC method called: ' . $method);
});Этот код не отключает XML-RPC, а только пишет в error log имя метода. После тестового периода его нужно убрать, чтобы не засорять логи.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три рабочих подхода: через плагин, через код и через веб-сервер. На практике я бы выбирал код или серверную блокировку, если вы понимаете, что делаете. Плагин удобен, но добавляет ещё один слой зависимости.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правки кода | Ещё одна зависимость, не всегда нужен | Если сайт ведёт неразработчик |
| Код в WordPress | Прозрачно, легко откатить | Нужно не ошибиться с местом вставки | Если есть доступ к теме или mu-plugin |
| Nginx/Apache | Режет запрос до PHP | Нужен доступ к серверу | Если хотите минимизировать нагрузку |
Вариант 1: отключение через код
Самый понятный способ — отключить XML-RPC фильтром. Добавьте код в functions.php дочерней темы или, что лучше, в небольшой mu-plugin.
<?php
add_filter('xmlrpc_enabled', '__return_false');Это отключит XML-RPC на уровне WordPress. Запросы к /xmlrpc.php могут продолжать приходить, но WordPress будет отвечать отказом.
Вариант 2: блокировка на уровне Nginx
Если у вас Nginx, можно отсечь запросы раньше, чем они попадут в PHP. Это полезно, когда на сайт идёт много мусорных обращений и вы хотите снизить нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой блок лучше применять только если вы уверены, что XML-RPC больше не нужен. Иначе вы отрежете не только атаки, но и легитимные интеграции.
Вариант 3: блокировка через Apache
Для Apache обычно используют правила в .htaccess. Это рабочий вариант для хостингов, где нет доступа к конфигу виртуального хоста.
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через старую конфигурацию Apache 2.2, синтаксис может отличаться, но на современных серверах нужен именно Require all denied.
Что делать, если XML-RPC нужен только для части функций
Иногда отключать всё целиком невыгодно. Например, редактору нужен внешний клиент, но pingback и trackback вам не нужны. В таком случае имеет смысл не рубить endpoint полностью, а ограничить отдельные механики. Это уже более тонкая настройка, и она требует тестов.
Если проблема именно в pingback-атаках или лишних уведомлениях, можно отключить pingback отдельно. Это не равно полной блокировке XML-RPC, но часто решает практическую задачу.
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['pingback.ping']);
return $methods;
});Такой подход полезен, когда вы хотите сохранить совместимость с частью внешних клиентов, но убрать наиболее бесполезные и шумные методы.
Проверка результата после внедрения
После отключения важно не ограничиться тем, что страница /xmlrpc.php «как будто не открывается». Проверка должна быть функциональной.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере: для отключённого XML-RPC ожидается отказ или пустой ответ, в зависимости от способа блокировки. - Проверьте публикацию через внешний клиент, если он у вас есть.
- Посмотрите access.log и error.log: нет ли повторяющихся ошибок после блокировки.
- Проверьте, не сломались ли сервисы автопостинга, если они используются.
- Убедитесь, что REST API продолжает отвечать на
/wp-json/.
Для REST API можно быстро проверить ответ так:
curl -I https://example.com/wp-json/Если сайт отдаёт 200 или корректный редирект на HTTPS, значит базовая API-доступность не нарушена. Это не проверка XML-RPC, но хороший индикатор, что вы не сломали общую сетевую конфигурацию.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать мобильный клиент
Значит, у вас был реальный потребитель endpoint. Верните доступ и проверьте, можно ли перевести этот сценарий на REST API или на обычную авторизацию через админку. Если клиент старый, возможно, проще заменить его, чем держать открытым устаревший протокол.
Поставили плагин, но запросы всё равно идут
Некоторые плагины только блокируют часть методов или добавляют фильтр на уровне WordPress, но не режут запрос на сервере. В логах вы всё равно увидите обращения к xmlrpc.php. Это не ошибка, если цель была именно отключить функциональность, но не убрать сам URL из доступа. Если нужна жёсткая блокировка, делайте её на уровне Nginx или Apache.
Сломали интеграцию, о которой никто не знал
Это типичная проблема на старых сайтах. Перед отключением проверьте не только документацию, но и историю плагинов, cron-задачи, внешние вебхуки и старые инструкции для редакции. Если сайт обслуживает несколько людей, лучше коротко предупредить команду и дать окно на тест.
Добавили код в родительскую тему
После обновления темы настройка исчезнет. Для таких изменений используйте дочернюю тему или mu-plugin. Это особенно важно для сайтов, которые регулярно обновляются и где нельзя рассчитывать на ручную правку после каждого апдейта.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, его отключение — не единственная мера. На сайте с регулярными атаками лучше смотреть шире: ограничить частоту запросов, проверить актуальность ядра, тем и плагинов, убрать лишние внешние точки входа. В некоторых случаях полезно дополнительно закрыть wp-login.php по IP или через двухфакторную аутентификацию, но это уже отдельная задача.
Если вы используете набор плагинов для технической чистки и SEO, вроде Clearfy Pro, проверьте, не дублирует ли он уже часть нужной вам логики. Но не ставьте инструмент только ради одной функции, если задача решается штатно и прозрачно. Чем меньше лишних слоёв, тем проще поддержка после обновлений WordPress.
Для производительности важен не сам факт отключения XML-RPC, а снижение ненужных обращений к PHP. Если на сайт идёт много мусорных запросов, серверная блокировка обычно полезнее, чем обработка запроса WordPress-ом и последующий отказ.
Мини-чек-лист перед отключением
- Проверил, кто реально использует XML-RPC.
- Убедился, что нет старых интеграций и клиентов.
- Выбрал способ блокировки: код, сервер или плагин.
- Сделал бэкап конфигурации и, если нужно, сайта.
- Проверил REST API и рабочие сценарии публикации.
- Посмотрел логи после изменения.
Если задача сводится к «убрать лишнюю поверхность атаки и не сломать редакцию», отключение XML-RPC — нормальное техническое решение. Но на старом сайте его нельзя делать вслепую: сначала диагностика, потом блокировка, потом проверка по логам и реальным сценариям.