XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильное приложение, публикацию через внешние клиенты или старые интеграции. На практике вопрос не в том, нужен ли этот интерфейс вообще, а в том, какие именно запросы к нему у вас реально используются. Если сайт не принимает публикации извне и не синхронизируется со сторонними сервисами, XML-RPC действительно можно закрыть. Но делать это лучше после проверки, а не по привычке.
Когда XML-RPC мешает, а когда он нужен
XML-RPC — это отдельная точка входа по адресу /xmlrpc.php. Через неё WordPress исторически поддерживает удалённую публикацию, некоторые мобильные клиенты, старые интеграции и часть сервисов автоматизации. Одновременно этот же endpoint часто используют для перебора логинов и многократных запросов, поэтому он нередко становится лишней поверхностью атаки.
Отключать его имеет смысл, если у вас:
- нет публикации через внешние клиенты и мобильные приложения WordPress;
- не используется Jetpack или другой сервис, которому нужен XML-RPC;
- нет старых интеграций, завязанных именно на этот endpoint;
- в логах заметны массовые обращения к
xmlrpc.phpбез полезной нагрузки.
Оставлять его включённым стоит, если сайт реально синхронизируется со сторонними инструментами, а не просто «когда-то был подключён». В таких случаях лучше сначала понять, кто именно обращается к endpoint, и только потом принимать решение.
Диагностика: как понять, используется ли xmlrpc.php
Самая частая ошибка — отключить XML-RPC без проверки. Если сайт небольшой, это может пройти незаметно. Если есть интеграции, проблема всплывает позже: не публикуются записи из внешнего сервиса, не синхронизируются комментарии или падает подключение клиента.
Что проверить в первую очередь
- Логи веб-сервера: есть ли регулярные запросы к
/xmlrpc.php. - Настройки подключённых сервисов: Jetpack, мобильные клиенты, автоматизация публикаций.
- Сценарии для редакторов: кто-то публикует через сторонний инструмент или только из админки.
- Ответ endpoint: если открыть
/xmlrpc.phpв браузере, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не проверка безопасности, но признак того, что endpoint доступен.
Если у вас есть доступ к логам, полезно посмотреть частоту обращений. Важно не количество само по себе, а наличие успешных запросов от ваших сервисов. Массовые пустые POST-запросы — это уже повод закрывать endpoint или ограничивать доступ на уровне сервера.
Как отключить XML-RPC: три рабочих подхода
Выбор способа зависит от того, что у вас уже стоит: чистый WordPress, набор плагинов безопасности или доступ к конфигу веб-сервера. Ниже — практичные варианты без выдуманных решений.
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужен быстрый способ без правок кода | Добавляет ещё один плагин и зависимость от его настроек |
Фильтр в functions.php или mu-plugin | Есть доступ к теме или must-use плагинам | Нужно не забыть про обновления темы и перенос на staging |
| Правило на уровне сервера | Нужна жёсткая блокировка до WordPress | Требует доступа к конфигу Nginx/Apache и аккуратной проверки |
Вариант 1: отключение через код
Если нужен управляемый и прозрачный способ, проще всего использовать фильтр xmlrpc_enabled. Его можно добавить в functions.php дочерней темы или вынести в небольшой mu-plugin, чтобы не зависеть от темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Если у вас есть интеграции, сначала проверьте их на staging-копии, а уже потом переносите изменение на продакшн.
Вариант 2: блокировка через сервер
Если задача — не просто отключить функциональность, а уменьшить нагрузку и убрать endpoint ещё до загрузки WordPress, можно закрыть xmlrpc.php на уровне веб-сервера. Это особенно полезно, когда по логам видно много мусорных запросов.
Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка жёстче, чем фильтр WordPress. Это плюс, если вы точно уверены, что endpoint не нужен. Но если позже выяснится, что какой-то сервис всё же использовал XML-RPC, придётся возвращать доступ на уровне веб-сервера.
Вариант 3: плагин безопасности
Если у вас уже стоит плагин, который умеет отключать XML-RPC, можно использовать его настройки. Это удобно для админов без доступа к коду, но важно понимать, что плагин не должен быть единственной причиной, почему сайт защищён. Для критичных сайтов лучше иметь понятную серверную или кодовую настройку, а не полагаться на интерфейс плагина.
Пошаговое решение без лишнего риска
- Проверьте, есть ли у сайта реальные зависимости от XML-RPC.
- Сделайте изменение сначала на staging-копии.
- Отключите endpoint через фильтр
xmlrpc_enabledили на уровне сервера. - Проверьте доступ к
/xmlrpc.phpи работу внешних сервисов. - Если всё стабильно, перенесите настройку на продакшн.
Если сайт обслуживает несколько редакторов, предупредите их заранее. Иначе кто-то может обнаружить проблему уже после публикации материала через внешний клиент и потратить время на поиск причины.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Открыть URL в браузере недостаточно: endpoint может отвечать, но не принимать запросы. Лучше пройтись по нескольким сценариям.
- Откройте
/xmlrpc.php— при серверной блокировке должен быть отказ в доступе. - Если использовали фильтр, проверьте, что WordPress больше не принимает XML-RPC-запросы.
- Посмотрите логи веб-сервера: обращения к endpoint могут продолжаться, но успешных ответов быть не должно.
- Проверьте внешние сервисы, если они были подключены: публикация, синхронизация, мобильные клиенты.
Для быстрой проверки можно отправить тестовый POST-запрос. Если endpoint отключён корректно, вы увидите отказ или пустой ответ без нормальной обработки XML-RPC-метода.
curl -i -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если после отключения внешний сервис продолжает работать, значит он не использовал XML-RPC или у него есть другой канал подключения. Если же сервис сломался — вы нашли зависимость, которую нужно либо вернуть, либо заменить.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли Jetpack
Jetpack в ряде сценариев использует XML-RPC для связи с сайтом. Если после отключения перестали работать функции синхронизации или удалённого управления, проверьте, действительно ли этот сервис нужен. Если нужен — не блокируйте endpoint целиком, а ограничьте доступ более точечно.
Спрятали проблему плагином, но endpoint остался доступен
Некоторые плагины меняют поведение WordPress, но не закрывают endpoint на уровне сервера. Это не всегда плохо, но если цель — уменьшить нагрузку от мусорных запросов, лучше блокировать xmlrpc.php раньше, чем WordPress начнёт обрабатывать запрос.
Добавили код в активную тему и забыли про обновление
Если правка лежит в functions.php родительской темы, при обновлении или смене темы она может потеряться. Для таких настроек надёжнее использовать дочернюю тему или mu-plugin.
Закрыли endpoint без теста внешних интеграций
Это самая дорогая ошибка. Перед отключением проверьте, кто публикует, синхронизирует или подключается к сайту извне. Особенно это важно для сайтов, где контент заводят не только через админку WordPress.
Безопасность и производительность: что ещё имеет смысл сделать
Если вы уже занялись XML-RPC, полезно посмотреть и на соседние точки риска. На сайтах с постоянным потоком мусорных запросов часто выигрывает не одна точечная правка, а связка из нескольких небольших ограничений.
- Ограничьте доступ к
wp-login.php, если у вас есть понятный сценарий авторизации. - Проверьте, не открыты ли лишние REST-эндпоинты плагинов.
- Смотрите в логи не только на XML-RPC, но и на повторяющиеся 404 и 403 по служебным URL.
- Если сайт под нагрузкой, блокировка на уровне сервера обычно полезнее, чем обработка запроса внутри WordPress.
Для технической чистки и контроля дублей на сайте иногда удобнее использовать набор инструментов вроде Clearfy Pro, но сам принцип остаётся тем же: сначала понять, что реально используется, потом отключать лишнее. Автоматическое «закрыть всё подряд» почти всегда приводит к побочным эффектам.
Когда лучше не отключать XML-RPC полностью
Полное отключение не подходит, если у вас есть хотя бы один действующий сценарий, завязанный на этот интерфейс. В таком случае лучше:
- оставить XML-RPC включённым, но ограничить доступ по IP, если это возможно;
- закрыть только лишние методы через более точечную настройку;
- перевести интеграцию на другой способ подключения, если сервис это поддерживает.
Если вы не уверены, нужен ли endpoint, не принимайте решение по чужой рекомендации из интернета. Сначала проверьте свои логи и реальные подключения. Это быстрее, чем потом разбирать, почему перестала работать публикация из внешнего сервиса.