XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильные приложения, внешние публикации или старые интеграции. Проблема не в самом XML-RPC, а в том, что его нередко выключают без проверки зависимостей. Если на сайте нет внешних клиентов, которые используют xmlrpc.php, отключение действительно имеет смысл: меньше поверхность атаки, меньше лишних запросов. Но делать это нужно осознанно.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без побочных эффектов и как проверить, что ничего не сломалось.
Когда XML-RPC реально нужен
XML-RPC — это старый интерфейс WordPress для удалённого доступа. Его до сих пор используют некоторые приложения и сервисы, но в большинстве современных проектов он не нужен. Перед отключением проверьте, есть ли у вас хотя бы один из таких сценариев:
- публикация через старые десктопные клиенты;
- мобильные приложения, которые работают не через REST API, а через XML-RPC;
- внешние сервисы автопостинга или синхронизации контента;
- старые интеграции с CMS, CRM или скриптами, где в настройках явно указан
xmlrpc.php; - плагины, которые используют методы XML-RPC для удалённых операций.
Если ничего из этого нет, отключение обычно безопасно. Но сначала стоит подтвердить это проверкой, а не предположением.
Диагностика: как понять, используется ли xmlrpc.php
Самый практичный способ — посмотреть логи веб-сервера и статистику запросов. Ищите обращения к /xmlrpc.php. Если запросы идут только от ботов и сканеров, это не аргумент в пользу сохранения XML-RPC. Если же видны обращения от ваших приложений или внешних сервисов, сначала перенастройте их.
Что проверить в первую очередь
- access log Nginx или Apache за последние 7–30 дней;
- настройки мобильных приложений и сторонних клиентов;
- плагины автопостинга, синхронизации и публикации по API;
- вебхуки и интеграции, если они завязаны на старые endpoints;
- нет ли в коде темы или плагинов прямых обращений к
xmlrpc.php.
Если доступа к логам нет, можно временно заблокировать XML-RPC и посмотреть на ошибки в админке, почте и внешних сервисах. Но это уже тест в боевых условиях, а не лучший первый шаг.
Как отключить XML-RPC в WordPress
Есть три нормальных подхода: через код, через веб-сервер и через плагин безопасности. Для большинства проектов проще и прозрачнее отключать на уровне WordPress-кода. Это удобно, если вы контролируете тему или кастомный плагин.
Вариант 1: отключить через фильтр
Добавьте код в functions.php дочерней темы или, лучше, в свой небольшой плагин:
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый прямой способ: WordPress перестанет обрабатывать XML-RPC-запросы штатно. Для большинства сайтов этого достаточно.
Вариант 2: вернуть 403 на уровне WordPress
Если нужно не просто отключить функциональность, а явно закрыть endpoint, можно использовать init и проверку запроса:
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Такой вариант полезен, если вы хотите видеть явный отказ в ответе. Но для обычной эксплуатации фильтра xmlrpc_enabled обычно достаточно.
Вариант 3: закрыть на уровне сервера
Если вы уверены, что XML-RPC не нужен вообще, можно заблокировать доступ к xmlrpc.php на уровне Nginx или Apache. Это снижает нагрузку ещё до загрузки WordPress.
Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный уровень полезен, если сайт часто получает брутфорс по xmlrpc.php. Но если у вас есть зависимые интеграции, сначала проверьте их, иначе вы просто отрежете рабочий канал.
Сравнение подходов: код, сервер, плагин
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Просто, прозрачно, легко откатить | WordPress всё равно загружается | Если нужен быстрый и безопасный способ |
| Блокировка на сервере | Режет запрос до PHP, меньше нагрузка | Нужно править конфиг сервера | Если XML-RPC точно не нужен |
| Плагин безопасности | Удобно для админов без доступа к коду | Лишняя зависимость, возможны конфликты | Если сайт уже управляется через security-плагин |
Если у вас уже стоит плагин вроде Clearfy Pro и вы используете его как набор точечных оптимизаций, проверьте, не дублирует ли он эту настройку. Но не включайте несколько способов одновременно без необходимости: потом сложнее понять, что именно блокирует endpoint.
Пошаговое решение без поломки интеграций
- Проверьте логи и список внешних клиентов.
- Убедитесь, что никто не использует
xmlrpc.phpдля публикации или синхронизации. - Сначала отключите XML-RPC фильтром
xmlrpc_enabled. - Протестируйте сайт и внешние сервисы.
- Если всё работает, при необходимости перенесите блокировку на серверный уровень.
Такой порядок важен: сначала мягкое отключение, потом жёсткое. Это снижает риск внезапно сломать старую интеграцию, о которой уже никто не помнит.
Как проверить, что отключение сработало
Проверка должна быть не формальной, а практической. После внедрения откройте в браузере /xmlrpc.php. В зависимости от способа блокировки вы увидите либо отказ в доступе, либо сообщение о том, что XML-RPC отключён. Главное — не должен открываться рабочий endpoint.
Дополнительно проверьте:
- не приходят ли ошибки от мобильного приложения WordPress;
- не перестали ли работать внешние сервисы автопостинга;
- не появились ли записи о неудачных попытках публикации в логах;
- не выросло ли число 403/405 в access log после блокировки.
Если у вас есть мониторинг, посмотрите, не изменилось ли число ошибок авторизации или неудачных запросов к сайту. Иногда после отключения XML-RPC всплывают старые интеграции, которые долгое время работали «в тени».
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали мобильное приложение
Значит, приложение действительно использовало XML-RPC, а не REST API. Решение — либо вернуть доступ, либо перевести интеграцию на REST API, если приложение и сервис это поддерживают.
Закрыли endpoint в .htaccess, но он всё равно отвечает
На некоторых конфигурациях правило может не применяться, если сайт работает не через Apache или если правила перезаписываются другим конфигом. Проверьте, какой веб-сервер реально обслуживает сайт, и при необходимости перенесите блокировку на уровень Nginx.
Использовали несколько способов сразу и не понимают, что ломает запрос
Если одновременно включены фильтр, серверная блокировка и security-плагин, диагностика становится бессмысленной. Оставьте один способ, проверьте результат, потом при необходимости усиливайте защиту.
Отключили XML-RPC без проверки логов
Это типичная ошибка на старых сайтах. Сначала посмотрите, кто обращается к endpoint, и только потом меняйте конфигурацию. Иначе можно потерять рабочий канал публикации и долго искать причину.
Что делать вместо XML-RPC
Для новых интеграций лучше использовать REST API WordPress. Он современнее, удобнее для авторизации и лучше документирован. Если вы пишете свой плагин или внешний сервис, не привязывайтесь к XML-RPC без крайней необходимости.
Если задача — только удалённая публикация или чтение данных, REST API обычно закрывает её без старого технического долга. Для админских сценариев можно использовать отдельные токены, application passwords или собственную авторизацию, в зависимости от архитектуры проекта.
Практические советы по безопасности и производительности
- если XML-RPC не нужен, лучше закрыть его на сервере, а не только на уровне WordPress;
- не ставьте несколько security-плагинов ради одной функции блокировки;
- после отключения проверьте логи на предмет повторяющихся попыток доступа;
- если сайт под атакой, блокировка XML-RPC — только одна из мер, а не полная защита;
- не забывайте, что REST API тоже требует контроля доступа, если на сайте есть приватные данные.
Если вам нужно не только отключить XML-RPC, но и убрать лишние технические поверхности в WordPress, имеет смысл смотреть на более широкий набор оптимизаций. Но каждую из них лучше включать отдельно и проверять результат, а не собирать всё в один большой «ускоритель».