XML-RPC в WordPress часто держат включённым «на всякий случай», хотя на практике он нужен далеко не всем. Проблема в том, что этот интерфейс исторически использовался для удалённой публикации, некоторых мобильных клиентов и внешних сервисов. Если вы не знаете, кто именно его использует, отключать его вслепую нельзя: можно сломать синхронизацию, публикацию через сторонний клиент или интеграцию с сервисом, который до сих пор ходит в xmlrpc.php.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его безопасно, чем отличается блокировка на уровне WordPress и веб-сервера, и как проверить результат без гаданий по логам.
Когда XML-RPC действительно стоит отключать
Если сайт управляется из админки, а внешних клиентов и старых интеграций нет, XML-RPC обычно не нужен. На практике его отключают ради снижения шума в логах, уменьшения поверхности атаки и устранения лишних запросов к xmlrpc.php. Но сначала полезно проверить, не используется ли он косвенно.
Что может зависеть от XML-RPC
Чаще всего это:
- старые мобильные приложения WordPress;
- внешние редакторы и публикационные клиенты;
- сервисы автопостинга и мониторинга;
- некоторые устаревшие интеграции с CMS и CRM;
- плагины, которые отправляют запросы через XML-RPC вместо REST API.
Если у вас обычный корпоративный сайт, блог или лендинг, и публикация идёт только через админку, отключение обычно безопасно. Если же есть интеграции, сначала проверьте их документацию и логи.
Диагностика: как понять, используется ли xmlrpc.php
Самый практичный способ — посмотреть логи веб-сервера и статистику запросов. Если xmlrpc.php регулярно вызывается не ботами, а реальными сервисами, это сигнал не рубить с плеча.
Что искать в логах
В access log обратите внимание на частые POST-запросы к /xmlrpc.php. Если там только массовые попытки подбора паролей, это уже аргумент в пользу отключения. Если же видны запросы с понятным user-agent или с IP ваших сервисов, сначала разберитесь, кто их отправляет.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам может отличаться, но логика та же: ищите повторяющиеся POST-запросы и сопоставляйте их с временем активности сайта и внешних сервисов.
Проверка снаружи
Можно быстро проверить, отвечает ли endpoint. Сам по себе ответ не доказывает, что его кто-то использует, но помогает понять текущее состояние.
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 200 OK или 405 Method Not Allowed, файл доступен. Если вы уже отключили XML-RPC корректно, чаще увидите 403 или другой запрет на уровне приложения или веб-сервера.
Как отключить XML-RPC: сравнение подходов
Есть три нормальных варианта: через код, через сервер и через плагин безопасности. Выбор зависит от того, как у вас устроен проект и кто будет поддерживать решение дальше.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Прозрачно, легко контролировать в Git | Нужно не забыть про обновления темы | Для проектов с нормальным процессом разработки |
| Правило на сервере | Быстро и жёстко блокирует запросы | Нужно доступ к конфигу Nginx/Apache | Если нужен именно запрет на уровне инфраструктуры |
| Плагин безопасности | Можно включить без кода | Лишняя зависимость, иногда больше функций, чем нужно | Если уже используете такой плагин и не хотите править код |
Пошаговое решение через код
Самый предсказуемый вариант — отключить XML-RPC фильтром. Лучше делать это не в теме, а в mu-plugin или в небольшом кастомном плагине, чтобы решение не исчезло после смены темы.
Вариант 1: полностью отключить XML-RPC
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот код отключает сам механизм XML-RPC на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, WordPress не будет обрабатывать такие запросы как рабочие.
Вариант 2: заблокировать доступ к файлу на уровне веб-сервера
Если нужен жёсткий запрет, можно закрыть xmlrpc.php в конфигурации сервера. Для Nginx это обычно выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой подход хорош, когда вы хотите остановить запросы ещё до загрузки WordPress. Это полезно для сайтов, которые регулярно ловят брутфорс по XML-RPC и не используют его вообще.
Вариант 3: отключить только опасные методы
Иногда полный запрет не подходит, потому что какой-то внешний клиент всё же нужен. Тогда можно ограничить методы XML-RPC фильтром xmlrpc_methods. Это уже более тонкая настройка, но её стоит применять только если вы понимаете, какие методы реально используются.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Чаще всего первым делом убирают pingback-методы. Они редко нужны на современных сайтах, но могут быть источником лишнего трафика и попыток злоупотребления.
Проверка результата после внедрения
После отключения не ограничивайтесь тем, что «ошибок в админке не видно». Нужно проверить и внешний ответ, и отсутствие побочных эффектов.
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт или обработка отключена. - Проверьте логи веб-сервера: новые запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Если у вас есть мобильное приложение, внешний редактор или автопостинг, протестируйте публикацию вручную.
- Проверьте, не завязаны ли на XML-RPC резервные копии, мониторинг или интеграции сторонних сервисов.
Хороший практический тест — отправить запрос, который раньше проходил, и посмотреть, что он теперь получает в ответ. Если интеграция сломалась, это будет видно сразу, а не через неделю по жалобе редактора.
Пример тестового запроса
curl -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'Если XML-RPC отключён корректно, ответ не должен выглядеть как рабочий список методов WordPress.
Частые ошибки и как их исправить
Отключили в теме, а потом сменили тему
Это типичная ошибка. Решение исчезает вместе с темой, и через пару месяцев XML-RPC снова открыт. Для таких задач используйте mu-plugin или отдельный мини-плагин.
Заблокировали файл на сервере, но забыли про интеграции
Если внешняя система публиковала записи через XML-RPC, она начнёт падать без понятного сообщения для редактора. Сначала проверьте логи и список интеграций, потом режьте доступ.
Смешали XML-RPC и REST API
Это разные механизмы. Отключение XML-RPC не ломает REST API и наоборот. Если у вас современная интеграция, она, скорее всего, должна работать через REST, а не через XML-RPC.
Поставили плагин, который делает слишком много
Некоторые security-плагины отключают не только XML-RPC, но и другие функции, которые вам нужны. Перед включением проверьте, что именно меняется в конфигурации, и не оставляйте лишние опции активными без необходимости.
Безопасность и производительность: что ещё имеет смысл сделать
Если цель — уменьшить поверхность атаки, одного отключения XML-RPC иногда мало. Имеет смысл посмотреть и на другие точки входа: слабые пароли, устаревшие плагины, открытый wp-login.php без ограничений, отсутствие 2FA для админов.
Для проектов, где важна техническая чистота, полезно держать такие изменения в коде и в конфигурации сервера, а не в ручных настройках в админке. Так проще повторять окружения и не терять защиту после обновлений.
Если вы уже используете набор для технической чистки сайта, вроде Clearfy Pro, проверьте, не дублирует ли он вашу ручную настройку. Лишние перекрывающиеся правила иногда создают путаницу при отладке. В таких задачах лучше одно понятное место, где видно, что именно отключено, чем несколько слоёв «защиты» без документации.
Что должно измениться после отключения
После корректного внедрения вы должны увидеть три вещи: xmlrpc.php перестаёт быть рабочей точкой входа, в логах уменьшается мусорный трафик, а нужные вам сценарии публикации и редактирования продолжают работать. Если хотя бы один из этих пунктов не выполняется, значит, решение выбрано не до конца верно.
На практике лучший порядок такой: сначала выяснить, кто использует XML-RPC, затем отключить его через код или сервер, потом проверить реальные интеграции. Это занимает немного больше времени, чем просто поставить галочку в плагине, но зато не превращает безопасность в лотерею.