XML-RPC в WordPress часто отключают по одной причине: через этот интерфейс удобно брутфорсить логины и дергать сайт внешними запросами, если защита настроена слабо. Но у отключения есть побочный эффект — можно неожиданно сломать Jetpack, старые приложения для публикации и некоторые внешние сервисы. Поэтому задача не в том, чтобы «просто закрыть файл», а в том, чтобы понять, нужен ли XML-RPC именно вашему сайту и как проверить, что после отключения ничего критичного не отвалилось.
Когда XML-RPC действительно стоит отключать
Если вы не используете внешние клиенты для публикации, не подключали Jetpack для синхронизации и не видите в логах частых обращений к /xmlrpc.php, отключение обычно оправдано. На практике это полезно для сайтов, где:
- идут подборы паролей через
xmlrpc.php; - в логах много запросов с кодом 200 или 403 к этому файлу;
- не используется мобильное приложение WordPress для публикации;
- нет интеграций, которым нужен XML-RPC pingback или remote publishing.
Если сайт старый, сначала проверьте, не завязаны ли на XML-RPC сторонние сервисы. Иначе можно получить не «усиление безопасности», а тихую поломку интеграции, которую заметят только после очередной публикации.
Диагностика: нужен ли вам XML-RPC сейчас
Самый практичный способ — посмотреть, обращается ли кто-то к xmlrpc.php и есть ли зависимые функции. Начните с логов веб-сервера или панели хостинга. Если доступа к логам нет, проверьте сайт вручную и через плагин безопасности, который умеет показывать блокировки и попытки входа.
Что проверить перед отключением
- используется ли Jetpack;
- подключено ли мобильное приложение WordPress;
- есть ли внешние сервисы автопостинга;
- используются ли старые интеграции с публикацией по XML-RPC;
- нет ли в логах регулярных обращений к
/xmlrpc.php.
Если вы не уверены, не отключайте файл сразу на продакшене. Сначала сделайте проверку на staging-копии или хотя бы подготовьте быстрый откат через конфиг веб-сервера.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных подхода: через плагин безопасности, через код и на уровне веб-сервера. Выбор зависит от того, кто обслуживает сайт и насколько вам нужен быстрый откат.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро, без правки файлов | Добавляет зависимость от плагина |
| Код в теме или mu-plugin | Прозрачно, легко контролировать | Нужно не забыть про обновления и место подключения |
| Блокировка на уровне сервера | Режет запросы раньше WordPress | Нужен доступ к конфигу Apache/Nginx |
Вариант 1: отключить XML-RPC через код
Если нужен управляемый вариант без лишнего плагина, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так код не потеряется при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам механизм XML-RPC на уровне WordPress. Если какой-то сервис продолжит стучаться в xmlrpc.php, он получит отказ, а не рабочий ответ.
Вариант 2: заблокировать файл на уровне сервера
Если у вас Apache и доступен .htaccess, можно закрыть прямой доступ к файлу. Это полезно, когда вы хотите отрезать запросы еще до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика другая: правило добавляют в конфиг сайта. Пример зависит от схемы хостинга, но смысл один — вернуть 403 для /xmlrpc.php до передачи запроса в PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если конфигом управляет хостинг, не правьте его вслепую. Сначала уточните, где именно лежит виртуальный хост и как у вас устроен reload конфигурации.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, это допустимо. Но не ставьте отдельный плагин только ради одной галочки, если ту же задачу можно решить кодом или серверным правилом. Чем меньше лишних плагинов, тем проще сопровождение.
Что может сломаться после отключения
Главный риск — не сам WordPress, а внешние сценарии. После отключения проверьте, не перестали ли работать:
- Jetpack-синхронизация;
- публикация из мобильного приложения WordPress;
- внешние сервисы автопостинга;
- интеграции, которые используют XML-RPC для удаленной публикации;
- pingback/trackback, если они еще где-то используются.
Если сайт корпоративный или редакционный, лучше заранее согласовать отключение с теми, кто публикует контент не из админки. Иначе проблема всплывет в самый неудобный момент — когда материал уже готов к выпуску.
Пошаговое решение без сюрпризов
- Проверьте логи и убедитесь, что
xmlrpc.phpреально используется или атакуется. - Сделайте резервную копию или подготовьте быстрый откат.
- Отключите XML-RPC через код, сервер или существующий security-плагин.
- Откройте сайт в браузере и проверьте, что обычная авторизация и публикация работают.
- Если есть Jetpack или внешние сервисы, протестируйте их отдельно.
- Посмотрите ответ на прямой запрос к
/xmlrpc.php: он должен быть запрещен или недоступен.
Как проверить, что решение сработало
Проверка должна быть не «страница открывается», а именно по точке входа XML-RPC. Самый простой тест — открыть https://ваш-домен.ru/xmlrpc.php. Если блокировка настроена правильно, вы не увидите рабочий интерфейс XML-RPC.
Дополнительно можно проверить через curl:
curl -I https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки: это может быть 403 Forbidden, 404 Not Found или иной отказ. Важно, чтобы файл не отвечал как рабочая точка XML-RPC.
После этого проверьте:
- вход в админку;
- создание и редактирование записей;
- работу Jetpack, если он установлен;
- публикацию через внешний сервис, если он у вас есть;
- логи сервера — нет ли повторяющихся ошибок на
xmlrpc.php.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Если после блокировки перестала работать синхронизация или статистика Jetpack, значит, этот сервис был завязан на XML-RPC. Решение простое: либо вернуть доступ, либо отказаться от конкретной функции, которая требует XML-RPC. Не пытайтесь «починить» это случайным набором исключений без понимания, что именно использует интеграция.
Закрыли файл в .htaccess, а сайт на Nginx
Правило для Apache на Nginx не сработает. Это частая ошибка при переносе сайта между хостингами. Проверьте, какой веб-сервер реально обслуживает домен, и применяйте соответствующий способ.
Поставили отдельный плагин ради одной функции
Если плагин нужен только для отключения XML-RPC, это лишняя зависимость. Лучше использовать код или серверную блокировку. Плагин имеет смысл только если он уже есть в вашем стеке и вы доверяете его настройкам.
Проверили только главную страницу
XML-RPC может быть закрыт, а сайт при этом внешне будет работать нормально. Это не значит, что проверка завершена. Тестируйте именно /xmlrpc.php и отдельно сценарии, которые могли зависеть от него.
Безопасность и производительность: что еще стоит сделать рядом
Отключение XML-RPC — не замена нормальной защите входа. Если атаки идут на логин, добавьте ограничение попыток входа, двухфакторную аутентификацию для админов и проверку прав пользователей. Если сайт часто сканируют, полезно также настроить базовую фильтрацию на уровне сервера или WAF.
Для сайтов, где важна чистота технической части, имеет смысл отдельно проверить лишние endpoints, дубли и мусорные запросы. Если вы уже используете набор инструментов для SEO и чистки сайта, например Clearfy Pro, его можно рассматривать как часть общей гигиены, но не как замену точечной серверной настройки.
Смысл простой: XML-RPC закрывают не ради галочки, а чтобы убрать конкретную точку атаки и не сломать рабочие интеграции. Если после внедрения вы проверили ответ /xmlrpc.php, протестировали внешние сервисы и посмотрели логи, значит, решение сделано правильно, а не формально.