XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишний входной канал для перебора паролей, pingback-спама и старых интеграций, которые никто уже не использует. При этом отключать его вслепую тоже не стоит: у части сайтов через XML-RPC до сих пор работают мобильное приложение WordPress, внешние публикации и некоторые сервисы автопостинга.
Ниже — рабочая схема: как понять, нужен ли вам XML-RPC, как отключить его безопасно и как проверить, что REST API при этом остался доступен.
Когда XML-RPC действительно нужно отключать
Если сайт не использует старые внешние клиенты, а публикация идёт только из админки, через REST API или через современные плагины, XML-RPC чаще всего не нужен. Особенно это касается сайтов, которые регулярно видят попытки входа по /xmlrpc.php в логах или получают много запросов с system.multicall.
Но перед отключением стоит проверить несколько сценариев:
- используется ли мобильное приложение WordPress;
- есть ли внешние сервисы публикации, которые работают именно через XML-RPC;
- не завязан ли на XML-RPC старый плагин синхронизации;
- не нужен ли pingback/trackback, если вы их ещё не отключили отдельно.
Диагностика: как понять, что XML-RPC ещё используется
Самый практичный способ — посмотреть логи веб-сервера и запросы к /xmlrpc.php. Если видите только мусорные запросы и перебор методов, это хороший кандидат на отключение. Если есть осмысленные вызовы от ваших сервисов, сначала перенесите их на другой способ интеграции.
Проверка доступности endpoint
Снаружи XML-RPC обычно отвечает даже без авторизации. Быстрый тест можно сделать через curl:
curl -i https://example.com/xmlrpc.phpЕсли endpoint доступен, это ещё не проблема само по себе. Важнее понять, кто и зачем его дергает. Для этого смотрят access-логи и частоту запросов.
Проверка зависимых интеграций
Если у вас есть внешняя публикация, проверьте, не использует ли она XML-RPC. Для WordPress.com, Jetpack и большинства современных сценариев чаще нужен REST API, а не XML-RPC. Но старые клиенты и самописные интеграции могут быть исключением.
Пошаговое решение: как отключить XML-RPC
Есть три нормальных подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, где вам удобнее поддерживать правило.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро, без правки темы | Лишняя зависимость, нужен контроль обновлений |
| Код в mu-plugin | Прозрачно, работает независимо от темы | Нужно аккуратно внедрить и не забыть про тест |
| Правило на сервере | Режет запросы раньше WordPress | Зависит от конфигурации Nginx/Apache |
Вариант 1: отключить через код
Если нужен предсказуемый вариант без лишних плагинов, добавьте правило в mu-plugin или в собственный мини-плагин. Так оно не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно.
Вариант 2: заблокировать доступ на уровне сервера
Если цель — не только отключить функциональность, но и сократить лишние запросы до PHP, можно закрыть сам файл 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, а не к серверу, используйте кодовый вариант. Если есть доступ к конфигу веб-сервера, лучше закрыть запросы ещё до запуска PHP.
Вариант 3: плагин для точечной защиты
Иногда достаточно плагина, который отключает XML-RPC вместе с другими лишними функциями. Например, в Clearfy Pro есть набор настроек для чистки WordPress и отключения ненужных возможностей. Это удобно, если вы уже используете такой плагин как централизованную точку управления техническими опциями.
Как не сломать REST API и внешние подключения
Частая ошибка — смешивать XML-RPC и REST API. Это разные механизмы. Отключение xmlrpc.php не должно ломать REST API, который работает через /wp-json/.
После внедрения проверьте:
- открывается ли
/wp-json/в браузере; - возвращает ли REST API корректный JSON;
- работают ли формы, редактор блоков и интеграции, которые используют REST;
- не отвалились ли мобильные клиенты, если они у вас были.
Быстрый тест REST API:
curl -i https://example.com/wp-json/Если ответ приходит с кодом 200 и JSON-структурой, REST API доступен. Если вместо этого вы видите редирект на авторизацию, ошибку 403 или 500, проблема уже не в XML-RPC, а в правилах безопасности, кэше или конфигурации сервера.
Частые ошибки и как их исправить
Отключили XML-RPC, а мобильное приложение перестало публиковать
Значит, приложение или сторонний клиент действительно использовал XML-RPC. Решение простое: либо вернуть доступ, либо перевести процесс на REST API/другой инструмент публикации. Не стоит держать XML-RPC включённым только ради одного старого сценария, если его можно заменить.
Закрыли /xmlrpc.php, но запросы всё равно идут
Это нормально: боты продолжают стучаться в endpoint, даже если он отдаёт отказ. Важно, что запросы больше не доходят до логики WordPress. Если нагрузка заметна, лучше закрывать на уровне веб-сервера и дополнительно ограничивать подозрительные IP на стороне WAF или CDN.
После правки .htaccess сайт начал отдавать 500
Чаще всего проблема в синтаксисе или в том, что правило вставили не в то место. Сначала откатите последнее изменение, потом проверьте конфигурацию в тестовой среде. Для Apache лучше использовать минимальный блок и не смешивать его с чужими правилами без необходимости.
Отключили XML-RPC через плагин, но забыли про pingback
Это разные вещи, хотя часто идут рядом. Если у вас цель — убрать лишнюю поверхность атаки и спам, проверьте ещё и настройки pingback/trackback, а также комментарии и ссылки на внешние уведомления.
Проверка результата после внедрения
После отключения сделайте не только ручную проверку в браузере, но и короткий технический чек:
https://example.com/xmlrpc.phpдолжен возвращать отказ или пустой ответ в зависимости от способа блокировки;https://example.com/wp-json/должен открываться;- в логах не должно быть роста 500-ошибок после изменения;
- если есть мониторинг, проверьте, что не выросло число ошибок авторизации в сторонних сервисах.
Если вы закрывали endpoint на сервере, полезно убедиться, что PHP-FPM больше не получает эти запросы. Это видно по access-логам и по снижению лишней нагрузки на сайт.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из популярных каналов перебора и мусорных запросов. Это особенно полезно на сайтах с простыми паролями, слабой защитой входа и без дополнительного WAF.
Если задача шире, чем просто XML-RPC, имеет смысл параллельно:
- ограничить попытки входа в админку;
- проверить, не включены ли лишние публичные endpoints;
- убрать неиспользуемые плагины и темы;
- сократить количество редиректов и тяжёлых запросов к базе;
- держать актуальными ядро, плагины и PHP-версию.
Для сайтов, где важна именно техническая чистка WordPress, удобнее один раз настроить набор опций в инструменте вроде Clearfy Pro, чем разбрасывать мелкие правки по теме и отдельным сниппетам. Но даже в этом случае проверка после изменений остаётся обязательной: отключение лишнего функционала не должно задевать рабочие интеграции.
Если нужен короткий ориентир: сначала проверьте, кто реально использует XML-RPC, затем отключайте его кодом или на сервере, после этого тестируйте REST API и логи. Такой порядок снижает риск сломать рабочий сценарий и одновременно убирает ненужную поверхность атаки.