XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или интеграция с сервисом, который до сих пор ходит не через REST API, а через xmlrpc.php. Поэтому правильный подход здесь не в том, чтобы просто закрыть файл, а в том, чтобы сначала понять, кто именно его использует.
Если сайт не принимает удалённую публикацию и не синхронизируется со сторонними приложениями, XML-RPC обычно можно отключить. Но делать это лучше после диагностики и с понятным способом отката.
Когда XML-RPC реально мешает
На практике XML-RPC оставляют включённым по привычке, хотя он нужен далеко не всем. Чаще всего его отключают из-за лишней поверхности атаки: через xmlrpc.php пытаются подбирать пароли, проверять доступность сайта или запускать массовые запросы. Это не единственная уязвимая точка WordPress, но если вы не используете удалённую публикацию, смысла держать её открытой немного.
Есть и обратная ситуация: сайт ломается после «жёсткого» запрета, потому что кто-то из редакторов публикует через мобильное приложение WordPress, старый десктопный клиент или внешний сервис автопостинга. В этом случае отключение нужно делать точечно, а не вслепую.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями посмотрите логи веб-сервера. Если у вас Nginx или Apache с доступом к access log, найдите обращения к /xmlrpc.php. Это самый быстрый способ понять, есть ли живые запросы.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, проверьте хотя бы поведение сайта после отключения на тестовой копии. Важно не гадать, а увидеть, что именно перестаёт работать: публикация, обновление черновиков, подключение внешнего клиента или вообще ничего.
Что должно насторожить
- в логах есть регулярные POST-запросы к
xmlrpc.phpс разных IP; - в админке никто не использует удалённую публикацию;
- интеграции с внешними сервисами уже переведены на REST API или webhooks;
- сайт получает много мусорных запросов, а нагрузка растёт без видимой причины.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, как устроен сайт. Если нужен быстрый и обратимый способ, проще использовать плагин или правило на уровне сервера. Если вы ведёте проект как разработчик, чаще удобнее закрыть доступ кодом в теме или mu-plugin.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужно быстро и без правок кода | Легко включить/выключить, не требует деплоя | Добавляет зависимость от плагина |
| Код в mu-plugin | Нужен стабильный контроль на уровне проекта | Не зависит от темы, переживает смену шаблона | Нужен доступ к файлам |
| Правило на сервере | Нужно отрезать запросы до PHP | Минимальная нагрузка | Сложнее тестировать и откатывать |
Вариант 1: отключение через код
Самый предсказуемый способ — запретить XML-RPC фильтром xmlrpc_enabled. Код лучше положить в mu-plugins, чтобы он не зависел от активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если у вас нет каталога mu-plugins, создайте wp-content/mu-plugins/ и положите туда файл, например disable-xmlrpc.php. WordPress подхватит его автоматически.
Вариант 2: запрет через .htaccess
Для Apache можно отрезать доступ к файлу на уровне веб-сервера. Это полезно, если вы хотите не просто отключить функциональность, а вообще не отдавать ответ на запросы к xmlrpc.php.
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант не подходит для Nginx в таком виде, потому что там используется другая конфигурация. На Nginx правило обычно добавляют в server block.
Вариант 3: запрет на Nginx
Если сайт работает на Nginx, проще всего закрыть доступ к файлу отдельным location-блоком. Это снижает лишнюю нагрузку и не даёт запросу дойти до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если у вас за Nginx стоит ещё и CDN или WAF, проверьте, не кэширует ли он старые ответы на этот путь. Иначе можно получить ложное ощущение, что всё закрыто, хотя запросы продолжают доходить до origin.
Что делать, если XML-RPC всё-таки нужен
Иногда отключать его нельзя: например, у редакции есть старое приложение, которое ещё не перевели на REST API, или внешний сервис умеет работать только через XML-RPC. В таком случае не стоит держать открытым всё подряд. Лучше ограничить доступ по IP, если это возможно, и отдельно проверить учётные записи с правами публикации.
Ещё один практичный шаг — убрать лишние возможности для перебора паролей на уровне защиты входа и лимитов запросов. XML-RPC сам по себе не решает проблему авторизации, он лишь даёт ещё один канал, который нужно контролировать.
Проверка результата после внедрения
После отключения проверьте не только сам файл, но и реальные сценарии. Откройте /xmlrpc.php в браузере или выполните запрос через curl. Если доступ закрыт, вы должны увидеть отказ на уровне сервера или пустой/ошибочный ответ, а не обычную страницу WordPress.
curl -I https://example.com/xmlrpc.phpДальше проверьте админку и публикацию:
- создание и обновление записей в редакторе;
- работу мобильного приложения, если оно используется;
- интеграции с внешними сервисами автопостинга;
- отсутствие ошибок в логах после тестовой публикации.
Если всё работает, значит XML-RPC вам действительно не нужен. Если что-то сломалось, откатите изменение и ищите конкретный клиент или сервис, который зависит от этого канала.
Частые ошибки и как их исправить
Отключили XML-RPC в теме
Это плохая идея. При смене темы защита исчезнет. Для таких настроек используйте mu-plugin или конфигурацию веб-сервера.
Закрыли файл, но забыли про интеграции
Если сторонний сервис продолжает слать запросы, он начнёт падать без понятной причины. Сначала найдите источник запросов в логах, потом меняйте способ интеграции.
Сломали мобильную публикацию
WordPress-приложение и некоторые старые клиенты до сих пор используют XML-RPC. Если редакторы работают через них, переводите процесс на REST API или оставляйте доступ только для нужных IP.
Проверили только браузером
Открыть xmlrpc.php в браузере недостаточно. Нужен тест POST-запроса и проверка логов, иначе можно не заметить, что сервер всё ещё принимает обращения.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC не заменяет нормальную защиту входа. Если на сайте есть брутфорс, проверьте лимиты попыток входа, двухфакторную аутентификацию для админов и актуальность плагинов. Если сайт часто получает мусорные запросы, имеет смысл посмотреть и на остальные технические точки: wp-login.php, REST API, публичные архивы и индексацию служебных страниц.
Для проектов, где важна чистка технического мусора и контроль дублей, иногда удобнее держать под рукой отдельный набор настроек безопасности и SEO-оптимизации. Например, Clearfy Pro от WPShop закрывает часть типовых задач по чистке сайта и техническим настройкам: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, что именно вам нужно отключить, а не включайте всё подряд.
Короткий чек-лист перед отключением
- проверить логи на обращения к
xmlrpc.php; - понять, используются ли мобильные клиенты или внешняя публикация;
- выбрать способ отключения: mu-plugin, сервер или плагин;
- сделать тест на staging-копии;
- после внедрения проверить публикацию, логины и интеграции;
- зафиксировать способ отката.
Если нужен минимально рискованный сценарий, начните с тестовой среды и отключайте XML-RPC только после того, как убедились, что ни один рабочий процесс на нём не завязан. Это тот случай, когда аккуратная диагностика экономит больше времени, чем быстрый запрет «в лоб».