XML-RPC в WordPress до сих пор встречается на старых установках, но на большинстве сайтов он не нужен. Если вы не используете мобильное приложение WordPress, внешние публикации или специфичные интеграции, открытый xmlrpc.php чаще добавляет лишнюю поверхность атаки, чем пользу. На практике задача обычно сводится к двум вопросам: как отключить доступ и как убедиться, что файл действительно недоступен извне.
Когда XML-RPC стоит отключать
Сначала полезно понять, есть ли у сайта реальная зависимость от XML-RPC. Если вы не уверены, проверьте сценарии использования:
- мобильное приложение WordPress для публикации и редактирования;
- Jetpack и похожие сервисы, которые могут использовать XML-RPC для части функций;
- внешние клиенты для публикации записей;
- старые интеграции, которые отправляют запросы через
xmlrpc.php.
Если ничего из этого не используется, отключение обычно безопасно. Но если сайт уже завязан на сторонний сервис, сначала проверьте его документацию и логи запросов, иначе можно сломать публикацию или синхронизацию.
Диагностика: открыт ли xmlrpc.php сейчас
Перед изменениями проверьте текущий статус. Самый простой способ — открыть /xmlrpc.php в браузере или отправить HEAD-запрос через curl. На живом сайте ответ может отличаться в зависимости от хостинга и правил безопасности, но сам файл не должен принимать рабочие XML-RPC-запросы.
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает 200 OK, это ещё не означает, что XML-RPC полностью рабочий, но файл доступен. Если видите 403 или 404, это хороший признак. Для более точной проверки можно отправить тестовый XML-RPC запрос:
curl -s https://example.com/xmlrpc.php -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'Если в ответе приходит список методов, XML-RPC работает. Если сервер возвращает ошибку доступа, блокировку или пустой ответ с кодом запрета, значит защита уже срабатывает.
Как отключить XML-RPC: рабочие варианты
Есть три практичных пути: через плагин безопасности, через код в теме или mu-plugin, и на уровне веб-сервера. Выбор зависит от того, где у вас удобнее управлять правилами.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро, без правки кода | Дополнительная зависимость, иногда лишняя нагрузка |
Код в functions.php или mu-plugin | Контроль в репозитории, предсказуемое поведение | Нужно аккуратно обновлять тему |
| Правило на сервере | Блокировка до загрузки WordPress | Требует доступа к конфигу Apache/Nginx |
Вариант 1: отключить через код
Если нужен прозрачный и переносимый способ, добавьте фильтр в functions.php дочерней темы или в отдельный mu-plugin. Этот вариант отключает сам XML-RPC интерфейс на уровне WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Для более жёсткой блокировки можно дополнительно запретить доступ к файлу через xmlrpc_methods, но в большинстве случаев достаточно фильтра выше. Если на сайте есть старые интеграции, сначала тестируйте на staging.
Вариант 2: блокировка через .htaccess
На Apache можно закрыть доступ к xmlrpc.php до запуска WordPress. Это полезно, если атаки идут массово и вы хотите отрезать их на уровне веб-сервера.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache 2.2 встречается синтаксис Deny from all, но на актуальных серверах лучше использовать Require all denied. Если сайт работает на Nginx, аналогичное правило обычно добавляют в конфиг сервера, а не в .htaccess.
Вариант 3: плагин безопасности
Если у вас уже стоит плагин вроде Clearfy Pro, проверьте, есть ли в нём отдельная настройка отключения XML-RPC. Это удобнее, чем держать отдельный код, если вы управляете несколькими сайтами и хотите единый интерфейс настроек. Но не стоит ставить тяжёлый плагин только ради одной галочки: если задача точечная, код или правило сервера обычно чище.
Пошаговое решение без лишних зависимостей
- Проверьте, использует ли сайт мобильное приложение WordPress, Jetpack или внешнюю публикацию.
- Сделайте копию сайта или включите staging.
- Добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );в дочернюю тему или mu-plugin. - Очистите кэш, если он есть на уровне плагина, сервера или CDN.
- Проверьте
/xmlrpc.phpчерез браузер иcurl. - Посмотрите логи ошибок и access log на предмет запросов к этому файлу.
Если после отключения сайт перестал отправлять публикации во внешний сервис, значит зависимость была реальной. В этом случае не возвращайте XML-RPC «на всякий случай» — лучше найти альтернативный способ интеграции, например REST API или нативный API самого сервиса.
Как проверить результат после внедрения
Проверка должна быть не формальной, а прикладной. Сначала убедитесь, что файл не отвечает на XML-RPC методы, затем проверьте, не сломались ли связанные сценарии.
- Браузер: откройте
https://example.com/xmlrpc.php. Ожидаемый результат — запрет доступа, ошибка или пустая служебная страница без рабочего интерфейса. - curl: повторите тестовый запрос
system.listMethodsи проверьте, что методы не возвращаются. - Логи: посмотрите, исчезли ли регулярные обращения к
xmlrpc.phpв access log. - Функциональность: проверьте, не используются ли мобильные публикации, удалённое редактирование и сторонние интеграции.
Если у вас включён кэш на уровне CDN, иногда старый ответ продолжает отдаваться из кэша. В таком случае очистите кэш не только в WordPress, но и на стороне CDN или reverse proxy.
Частые ошибки и как их исправить
Отключили XML-RPC, но файл всё ещё отвечает
Чаще всего причина в том, что правило добавили не туда: в родительскую тему, которая обновляется, или в файл, который не загружается на всех запросах. Надёжнее использовать дочернюю тему или mu-plugin. Ещё одна причина — серверный кэш, который продолжает отдавать старый ответ.
Сломалась синхронизация с внешним сервисом
Это означает, что сервис действительно использовал XML-RPC. Не пытайтесь лечить это возвратом открытого доступа для всех. Проверьте, есть ли у сервиса REST API, OAuth или другой официальный способ интеграции. Если нет — оцените, нужен ли вам вообще этот сервис.
В логах остались массовые запросы
Отключение в WordPress не всегда останавливает шум на уровне веб-сервера. Если атаки продолжаются, добавьте блокировку в конфиг Apache/Nginx или настройте WAF. Это особенно полезно на сайтах с постоянным бот-трафиком.
Поставили плагин только ради одной функции
Это частая ошибка на небольших проектах. Если задача точечная, код в mu-plugin проще сопровождать и легче откатить. Плагин имеет смысл, когда вы уже используете его для других задач и не хотите размазывать настройки по нескольким местам.
Безопасность и производительность: что ещё учесть
Отключение XML-RPC не делает сайт автоматически безопасным, но убирает один из лишних входов. На практике это полезно в связке с другими мерами: ограничением попыток входа, актуальными обновлениями ядра и плагинов, а также нормальной политикой резервных копий.
Если вы ведёте несколько сайтов, удобно держать такие отключения в mu-plugin: тогда правило не потеряется при смене темы. Для сайтов с жёсткими требованиями к безопасности лучше закрывать xmlrpc.php ещё и на уровне сервера, чтобы запросы не доходили до PHP вообще.
Если вам нужен более широкий набор технических отключений и чистки WordPress, посмотрите Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но для задачи с XML-RPC отдельный код часто остаётся самым прозрачным решением.