XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильные приложения, внешние публикации, старые интеграции и некоторые сервисы автопостинга. Проблема не в самом отключении, а в том, что его делают без проверки зависимостей.
Ниже — практический сценарий: как понять, нужен ли вам XML-RPC, как отключить его без лишнего риска и как убедиться, что ничего не сломалось.
Когда XML-RPC действительно можно отключить
Если сайт управляется только через wp-admin, а внешние сервисы не публикуют записи и не синхронизируют контент через XML-RPC, этот интерфейс обычно не нужен. На современных сайтах его часто заменяют REST API, прямой доступ к админке и интеграции через вебхуки.
Но есть важная оговорка: XML-RPC иногда используют неочевидные сценарии. Например, старые мобильные клиенты WordPress, внешние редакторы, сервисы публикации по расписанию и отдельные плагины для кросспостинга. Поэтому сначала проверяем зависимости, а уже потом отключаем.
Что ломается чаще всего
- публикация из сторонних приложений, которые работают через
xmlrpc.php; - удалённое создание и редактирование записей;
- некоторые сервисы автопостинга и синхронизации;
- старые интеграции, где REST API не был настроен.
Диагностика: как понять, используется ли XML-RPC
Самый простой способ — посмотреть логи и проверить, есть ли обращения к /xmlrpc.php. Если запросы идут регулярно, отключать интерфейс без анализа не стоит.
Если у вас есть доступ к серверным логам, ищите такие строки:
grep "xmlrpc.php" /var/log/nginx/access.logНа уровне WordPress можно проверить, не завязаны ли плагины на удалённую публикацию. Если в проекте есть интеграции с внешними редакторами, планировщиками постинга или мобильными клиентами, сначала тестируйте на staging-копии.
Ещё один практический признак: если в логах видны многочисленные POST-запросы к xmlrpc.php с ошибками авторизации, это не означает, что XML-RPC используется легитимно. Часто это просто брутфорс. В таком случае отключение оправдано, но всё равно лучше убедиться, что нужных интеграций нет.
Пошаговое решение: как отключить XML-RPC безопасно
Есть два рабочих подхода: через код в теме/плагине и на уровне веб-сервера. Для WordPress-проекта обычно удобнее начать с кода, потому что это проще откатить и проверить.
Вариант 1: отключить XML-RPC через фильтр WordPress
Добавьте код в mu-plugin или в небольшой собственный плагин. Так решение не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC на уровне WordPress. При обращении к xmlrpc.php сайт будет отвечать отказом, а не выполнять запросы.
Вариант 2: заблокировать доступ на уровне Nginx
Если вы хотите отрезать запросы ещё до загрузки WordPress, можно добавить правило в конфигурацию Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Это снижает нагрузку на PHP и уменьшает шум в логах. Но перед применением проверьте, что у вас нет сервисов, которым нужен именно этот endpoint.
Вариант 3: блокировка в Apache
Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через Apache с включённым mod_authz_core, этого обычно достаточно. После изменения конфигурации обязательно проверьте, что файл xmlrpc.php действительно недоступен извне.
Как проверить результат после внедрения
Проверка должна быть не формальной, а прикладной. Недостаточно просто открыть главную страницу и убедиться, что она работает.
- Откройте
/xmlrpc.phpв браузере или черезcurlи проверьте, что доступ закрыт. - Проверьте публикацию из всех внешних сервисов, которые вы используете.
- Посмотрите access log: новых легитимных запросов к
xmlrpc.phpбыть не должно. - Убедитесь, что REST API и обычный вход в админку работают штатно.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/xmlrpc.phpЕсли блокировка настроена корректно, вы увидите отказ в доступе на уровне сервера или неуспешный ответ WordPress. Главное — не должно быть успешного выполнения XML-RPC-запросов.
Сравнение подходов: код, сервер, плагин
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Просто откатить, работает внутри WordPress | WordPress всё равно загружается | Если нужен быстрый и безопасный старт |
| Nginx/Apache | Режет запросы до PHP, меньше нагрузки | Нужен доступ к конфигу сервера | Если вы контролируете сервер и хотите жёсткую блокировку |
| Плагин безопасности | Удобно для админов без доступа к коду | Добавляет зависимость от плагина | Если проект уже живёт на security-плагине |
Если у вас уже стоит набор для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не отключает ли он XML-RPC в составе других настроек. В таких случаях важно не дублировать блокировку в нескольких местах без необходимости.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про внешние сервисы
Это самая частая проблема. Сначала составьте список сервисов, которые публикуют или редактируют контент. Если что-то завязано на XML-RPC, переведите интеграцию на REST API или другой способ обмена данными.
Сделали блокировку в двух местах сразу
Например, добавили фильтр в WordPress и одновременно закрыли endpoint на сервере. Потом сложно понять, что именно ломает интеграцию. Для диагностики сначала оставляйте один способ блокировки, а второй подключайте только если он действительно нужен.
Проверили только главную страницу
XML-RPC может быть отключён, а сайт при этом будет полностью доступен. Но это не проверка результата. Тестируйте именно /xmlrpc.php и реальные сценарии публикации.
Использовали старый security-плагин без понимания настроек
Некоторые плагины безопасности умеют отключать XML-RPC вместе с другими функциями. Если после установки что-то перестало работать, ищите не только XML-RPC, но и ограничения REST API, авторизации и внешних запросов.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из лишних входов для атак и уменьшает шум от брутфорса. Если у вас нет причин держать этот интерфейс открытым, его лучше закрыть.
При этом не стоит путать безопасность с универсальной блокировкой всего подряд. Если проект использует внешние интеграции, сначала переведите их на поддерживаемый способ обмена данными, а потом отключайте старый канал.
Для проектов, где важна техническая чистота и минимизация лишних точек входа, удобно держать такие настройки централизованно: в mu-plugin, в конфиге сервера или в одном проверенном security-решении. Так проще сопровождать сайт и не ловить конфликты после обновлений.
Если нужно, следующий шаг после отключения XML-RPC — проверить, не открыты ли лишние служебные endpoints, и отдельно посмотреть на REST API, wp-cron.php и публичные формы авторизации. Но это уже отдельная задача, и её лучше разбирать по логам, а не «на глаз».