XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, попыткам брутфорса и странным обращениям к xmlrpc.php в логах. При этом отключать его вслепую тоже не стоит: если сайт использует старое мобильное приложение WordPress, Jetpack или внешнюю публикацию через XML-RPC, часть сценариев перестанет работать.
Ниже — рабочий разбор: как понять, нужен ли вам XML-RPC, как отключить его без лишних побочных эффектов и как проверить, что всё действительно сработало.
Когда XML-RPC стоит отключать
Если сайт не использует удалённую публикацию, pingback'и и старые интеграции, XML-RPC обычно не нужен. На практике его отключают ради уменьшения поверхности атаки и чтобы убрать постоянные обращения к /xmlrpc.php от сканеров и ботов.
Но есть важная оговорка: если у вас подключён Jetpack, старое мобильное приложение WordPress или какой-то внешний сервис публикации, сначала проверьте, не завязан ли он на XML-RPC. Иначе после отключения получите не «усиление безопасности», а сломанный рабочий процесс.
Что обычно видно в логах
Типичный признак — регулярные POST-запросы к xmlrpc.php, иногда с ошибками авторизации или с попытками метода system.multicall. Это не всегда атака, но почти всегда лишний шум. Если таких запросов много, имеет смысл хотя бы ограничить доступ, а не оставлять файл открытым без необходимости.
Диагностика: нужен ли XML-RPC именно вам
Перед изменениями проверьте, какие функции реально используются. Это быстрее, чем потом искать, почему перестала публиковаться запись из внешнего клиента.
- Есть ли Jetpack и включена ли синхронизация через WordPress.com.
- Используется ли мобильное приложение WordPress для публикации.
- Есть ли внешние сервисы, которые отправляют записи через XML-RPC.
- Нужны ли pingback'и и trackback'и на сайте.
Если ничего из этого не используется, XML-RPC можно отключать. Если используется только часть функций, иногда достаточно не полного отключения, а точечной блокировки pingback'ов и ограничений на уровне сервера.
Как отключить XML-RPC: три рабочих подхода
Есть несколько способов, и выбор зависит от того, где вы хотите контролировать поведение: в коде, через плагин или на уровне веб-сервера.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или MU-плагине | Нужен точный контроль | Прозрачно, без лишних зависимостей | Нужно следить за обновлениями и местом размещения |
| Плагин безопасности | Если уже используете security-плагин | Быстро включить, без правок кода | Лишняя зависимость, иногда больше настроек, чем нужно |
| Правило на сервере | Есть доступ к nginx/Apache | Режет запросы раньше WordPress | Нужно аккуратно тестировать, чтобы не задеть нужные сценарии |
Вариант 1: отключить XML-RPC через код
Самый понятный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой MU-плагин. Так настройка не потеряется при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC-интерфейс. Если вам нужно оставить его включённым, но убрать pingback'и, можно точечно отключить соответствующий метод:
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );Такой подход полезен, если вы не хотите ломать стороннюю интеграцию целиком, но хотите убрать один из самых бесполезных и шумных сценариев.
Вариант 2: ограничить доступ на уровне сервера
Если у вас nginx, можно заблокировать обращения к xmlrpc.php до передачи в PHP. Это особенно полезно, когда боты создают лишнюю нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный вариант хорош тем, что запросы не доходят до WordPress. Но если вы позже вспомните про нужную интеграцию, придётся возвращать доступ уже на уровне конфигурации.
Вариант 3: использовать плагин безопасности
Если у вас уже стоит плагин для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, нет ли там отдельной опции для отключения XML-RPC или ограничения лишних WordPress-функций. Это удобно, когда вы хотите собрать такие настройки в одном месте и не размазывать их по теме и серверу. Но не стоит ставить отдельный плагин только ради одной галочки, если задача решается кодом или конфигом сервера.
Пошаговое решение без лишнего риска
- Проверьте, используется ли XML-RPC в реальных сценариях: Jetpack, мобильное приложение, внешняя публикация.
- Если нужен только частичный контроль, отключите pingback'и, а не весь интерфейс.
- Если XML-RPC не нужен совсем, добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );в MU-плагин или дочернюю тему. - При наличии доступа к серверу добавьте блокировку на уровне nginx или Apache.
- После изменений протестируйте доступ к
/xmlrpc.phpи проверьте логи.
Если вы вносите изменения в код, не правьте родительскую тему напрямую. Для таких задач лучше использовать MU-плагин: он не зависит от активной темы и не исчезнет после обновления.
Как проверить, что отключение сработало
Самый простой тест — открыть /xmlrpc.php в браузере. Если XML-RPC отключён на уровне WordPress, вы обычно увидите сообщение о том, что XML-RPC server accepts POST requests only. Это не всегда означает, что всё выключено: браузер делает GET-запрос, а реальные проверки нужно проводить POST-запросом.
Практичнее проверить через curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли доступ заблокирован корректно, сервер должен вернуть отказ или не дать обработать запрос как XML-RPC. Дополнительно посмотрите access- и error-логи веб-сервера: обращений к xmlrpc.php после блокировки быть не должно, либо они должны завершаться отказом до PHP.
Если у вас был подключён Jetpack или внешний клиент, сделайте контрольную публикацию или синхронизацию. Это самый честный тест: не по статусу файла, а по фактическому рабочему сценарию.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Это происходит, когда сначала ставят жёсткий запрет, а потом вспоминают про интеграции. Решение простое: либо вернуть доступ, либо перенести нужную функцию на другой способ связи, если он поддерживается вашим стеком.
Поставили плагин, который делает больше, чем нужно
Некоторые security-плагины отключают сразу несколько функций WordPress, и после этого сложно понять, что именно сломалось. Если задача только в XML-RPC, лучше использовать точечный код или серверное правило.
Оставили правило в дочерней теме
Если потом смените тему, защита исчезнет. Для технических ограничений безопаснее MU-плагин или конфигурация сервера.
Заблокировали файл, но не проверили логи
Иногда кажется, что всё работает, но на деле сайт продолжает получать массу запросов, просто теперь они уходят в ошибки. Проверка логов покажет, уменьшилась ли нагрузка и нет ли побочных эффектов.
Что ещё имеет смысл отключить рядом с XML-RPC
Если вы уже занимаетесь чисткой технического слоя, посмотрите на соседние лишние функции: pingback'и, trackback'и, REST-эндпоинты, которые не используются, и автогенерацию некоторых служебных запросов. Но здесь важно не «выключить всё подряд», а понять, что реально задействовано сайтом и плагинами.
Для сайтов с регулярной технической чисткой удобнее держать такие настройки в одном месте, чтобы не искать их по теме, плагинам и серверным конфигам. Это снижает риск случайно вернуть уязвимость после очередного обновления.
Практические советы по безопасности и производительности
- Если XML-RPC не нужен, отключайте его раньше, чем начнёте бороться с ботами на уровне PHP.
- Не храните такие ограничения в родительской теме.
- После изменений проверьте не только страницу, но и логи веб-сервера.
- Если нужен только один внешний сценарий, не блокируйте всё без разбора.
- Не ставьте отдельный плагин ради одной функции, если задача решается кодом или конфигом.
В реальной эксплуатации лучший вариант обычно не самый «красивый», а тот, который проще сопровождать. Для XML-RPC это почти всегда либо короткий фильтр в MU-плагине, либо серверная блокировка, если интеграции не нужны вообще.