XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу и странным обращениям к /xmlrpc.php. На обычном сайте этот механизм нередко не нужен вообще, но отключать его вслепую тоже не стоит: некоторые внешние сервисы и старые приложения до сих пор используют XML-RPC для публикации и синхронизации.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его без побочных эффектов и как проверить результат.
Когда XML-RPC действительно можно отключать
Если вы не публикуете записи через старые мобильные клиенты, не используете внешние сервисы, которым нужен удалённый доступ к WordPress по XML-RPC, и не видите в логах регулярные обращения к xmlrpc.php от легитимных источников, отключение обычно безопасно. Для большинства современных сайтов админка, REST API и прямой вход в WordPress закрывают все реальные сценарии.
Но есть исключения. XML-RPC может быть нужен, если у вас:
- старое приложение для публикации или синхронизации контента;
- интеграция с сервисом, который не умеет работать через REST API;
- удалённая публикация через сторонний софт, который явно использует XML-RPC;
- наследуемая схема с Jetpack или похожими инструментами, где часть функций завязана на этот канал.
Диагностика: как понять, используется ли xmlrpc.php
Сначала проверьте, есть ли реальные обращения к файлу. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите запросы к /xmlrpc.php и смотрите, кто их делает: это может быть бот, а может быть ваш сервис.
Что смотреть в логах
Для Nginx достаточно выборки по имени файла. Примерно так:
grep 'xmlrpc.php' /var/log/nginx/access.log | tail -n 50Если логов много, полезно посмотреть не только сам факт обращения, но и частоту. Серии POST-запросов к xmlrpc.php с одинаковых IP часто указывают на попытки перебора, а не на нормальную интеграцию.
Проверка из браузера и по HTTP-ответу
Откройте https://ваш-домен.ru/xmlrpc.php. Если файл доступен, WordPress обычно отвечает текстом про XML-RPC server accepting POST requests only. Это не означает, что всё в порядке — только то, что endpoint существует. После отключения вы должны получить 403, 404 или другой запретительный ответ в зависимости от способа блокировки.
Как отключить XML-RPC: сравнение подходов
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Через код в теме или mu-plugin | Контроль, без лишних плагинов | Нужно не забыть о поддержке после смены темы | Если есть доступ к коду сайта |
| Через security-плагин | Быстро, удобно для админов без доступа к PHP | Зависимость от настроек плагина | Если уже используете плагин безопасности |
| Через веб-сервер | Режет запрос раньше WordPress | Нужно править конфиг сервера | Если нужен жёсткий запрет на уровне инфраструктуры |
Пошаговое решение через код
Самый предсказуемый вариант — отключить XML-RPC через фильтр xmlrpc_enabled. Такой код можно положить в functions.php дочерней темы, но лучше использовать mu-plugin, чтобы настройка не пропала при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите дополнительно закрыть сам файл от прямых обращений, можно вернуть 403 при попытке открыть xmlrpc.php. Это уже уровень веб-сервера или отдельного правила, но в WordPress тоже можно подстраховаться:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Этот вариант не заменяет серверную блокировку, но помогает, если файл всё ещё доступен и запрос дошёл до WordPress.
Если нужен более жёсткий вариант на сервере
Для Nginx можно закрыть доступ к файлу на уровне location. Это полезно, когда вы хотите остановить обращения до загрузки WordPress:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через прокси или CDN, проверьте, что блокировка не обходится на другом уровне маршрутизации.
Как не сломать нужные интеграции
Перед отключением составьте короткий список сервисов, которые могут ходить в WordPress извне. Это не бюрократия, а нормальная проверка. Если у вас есть автопостинг, внешняя CRM, старый клиент для публикации или интеграция с мобильным приложением, убедитесь, что они не завязаны на XML-RPC.
- проверьте настройки интеграций в админке;
- посмотрите документацию сервиса: есть ли там XML-RPC или REST API;
- сделайте тестовую публикацию или синхронизацию на staging;
- после отключения проверьте журналы ошибок и логи доступа;
- если сервис старый, ищите замену на REST API или webhook.
Если вы используете плагины, которые умеют отключать XML-RPC вместе с другими настройками безопасности, проверьте, не блокируют ли они лишнее. В некоторых конфигурациях вместе с XML-RPC случайно режут pingback или REST-запросы, и это уже влияет на работу сайта.
Проверка результата после внедрения
После отключения нужно проверить не только страницу /xmlrpc.php, но и поведение сайта в целом. Минимальный набор проверок такой:
- открыть
/xmlrpc.phpв браузере и убедиться, что доступ закрыт; - сделать запрос через
curlи посмотреть код ответа; - проверить, не выросло ли число ошибок в логах;
- протестировать все внешние интеграции, которые могли использовать XML-RPC;
- убедиться, что REST API и обычная авторизация работают как раньше.
Пример проверки через curl:
curl -I https://example.com/xmlrpc.phpЕсли всё отключено корректно, вы увидите 403, 404 или другой запретительный ответ. Если приходит 200 с текстом XML-RPC, значит блокировка не сработала или сработала не на том уровне.
Частые ошибки и как их исправить
Отключили в коде, но файл всё ещё отвечает
Так бывает, если правило добавили не туда или кэш/прокси отдаёт старый ответ. Проверьте, что код реально загружен: в functions.php дочерней темы, в активном mu-plugin или в нужном плагине. После этого очистите серверный и CDN-кэш.
Сломалась внешняя публикация
Значит, один из сервисов действительно использовал XML-RPC. Не возвращайте всё назад автоматически. Сначала найдите конкретную интеграцию и проверьте, есть ли у неё REST API или другой способ подключения. Если нет — оставьте XML-RPC включённым только на время миграции и ограничьте доступ по IP, если это возможно.
Плагин безопасности отключил больше, чем нужно
Некоторые плагины безопасности блокируют не только XML-RPC, но и полезные запросы, если включить агрессивные настройки. После изменения параметров обязательно проверяйте вход в админку, отправку форм, работу редактора и интеграции с внешними сервисами.
Блокировка на сервере не сработала из-за CDN
Если перед сайтом стоит CDN или reverse proxy, запросы могут доходить не напрямую до origin. В таком случае правило нужно проверить и на уровне прокси, и на уровне origin-сервера. Иначе вы увидите ложное ощущение защиты.
Практика безопасности и производительности
Отключение XML-RPC не делает сайт «защищённым полностью», но убирает один из популярных векторов перебора и лишнюю точку входа. Это особенно полезно, если на сайте нет необходимости в удалённой публикации. Дополнительно стоит проверить:
- ограничение попыток входа;
- актуальность ядра, тем и плагинов;
- наличие двухфакторной аутентификации для админов;
- корректные права на файлы;
- отсутствие лишних публичных endpoint'ов в старых плагинах.
Если вы предпочитаете закрывать технические дубли и чистить сайт без набора разрозненных плагинов, посмотрите в сторону инструментов, которые помогают централизованно управлять SEO- и security-настройками, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с таким плагином всё равно проверяйте, что именно он отключает в вашей конфигурации.
Если нужен короткий рабочий план, он такой: сначала найдите реальные обращения к xmlrpc.php, потом проверьте внешние интеграции, затем отключите XML-RPC кодом или на сервере и только после этого перепроверьте логи и HTTP-ответы. В этой задаче важнее не сам факт блокировки, а отсутствие побочных эффектов.