XML-RPC в WordPress часто не нужен, но продолжает быть включённым на сайтах, где его никто не использует. Проблема не в самом файле xmlrpc.php, а в том, что он остаётся отдельной точкой входа для перебора паролей, pingback-атак и лишней нагрузки на сервер. Если вы не подключаете внешние клиенты, мобильные приложения или старые интеграции, этот канал можно отключить без потери функциональности.
Когда XML-RPC действительно стоит отключать
Сначала проверьте сценарий использования. Не все сайты могут просто взять и выключить XML-RPC. Он нужен, если вы:
- публикуете записи через старые десктопные клиенты;
- используете мобильное приложение WordPress для удалённой публикации;
- подключаете внешние сервисы, которые до сих пор работают через XML-RPC;
- не уверены, что на сайте нет старых интеграций, завязанных на
xmlrpc.php.
Если ничего из этого не используется, отключение обычно оправдано. На обычном контентном сайте это один из самых простых способов убрать лишнюю поверхность атаки.
Диагностика: как понять, что XML-RPC вам мешает
Проверка начинается с простого запроса к /xmlrpc.php. Если файл доступен, это ещё не проблема, но если в логах видны частые обращения, переборы или запросы к методу system.multicall, канал уже используется не по назначению.
Посмотрите access-логи веб-сервера или логи безопасности плагина. Типичные признаки:
- много POST-запросов к
xmlrpc.phpс разных IP; - ошибки авторизации без попыток входа через обычную форму;
- подозрительная активность pingback-запросов;
- рост нагрузки без заметного роста обычного трафика.
Если у вас есть доступ к серверу, можно быстро проверить сам факт ответа:
curl -I https://example.com/xmlrpc.phpОтвет 200 или 405 означает, что файл доступен. Это не доказывает атаку, но подтверждает, что точка входа открыта.
Как отключить XML-RPC без плагинов
Самый надёжный вариант — отключить обработку на уровне WordPress. Для этого достаточно добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin. Такой способ не ломает обновления ядра и не зависит от стороннего плагина.
Вариант через фильтр xmlrpc_enabled
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет принимать XML-RPC-запросы штатным способом. Для большинства сайтов этого достаточно.
Дополнительная блокировка через .htaccess
Если сервер работает на Apache, можно закрыть доступ к файлу на уровне веб-сервера. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика будет другой: блокировку обычно добавляют в конфигурацию виртуального хоста. Конкретный блок зависит от вашей схемы, но смысл тот же — не отдавать xmlrpc.php наружу.
Что выбрать: код, сервер или плагин
Если задача точечная, код или правило веб-сервера обычно лучше, чем отдельный плагин. Но на проектах, где уже стоит плагин для технической чистки и SEO-оптимизации, иногда удобнее закрыть XML-RPC вместе с другими служебными настройками. Например, в Clearfy Pro есть набор функций для технической оптимизации и удаления лишнего мусора; если вы уже используете такой инструмент, это может быть практичнее, чем добавлять ещё один отдельный плагин. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
| Подход | Плюсы | Минусы |
|---|---|---|
Фильтр xmlrpc_enabled | Просто, прозрачно, не зависит от плагинов | WordPress всё равно загружается до применения фильтра |
| Блокировка на сервере | Режет запросы раньше, экономит ресурсы | Нужно править конфиг Apache/Nginx |
| Плагин безопасности | Удобно, если уже используется | Лишняя зависимость и риск конфликта настроек |
Пошаговое решение без лишнего риска
- Проверьте, используется ли XML-RPC в ваших сценариях публикации и интеграций.
- Сделайте резервную копию файлов и базы, если меняете серверную конфигурацию.
- Добавьте фильтр
xmlrpc_enabledв дочернюю тему или mu-plugin. - Если есть доступ к конфигу веб-сервера, закройте
xmlrpc.phpна уровне Apache или Nginx. - Проверьте, не ломаются ли внешние сервисы и мобильные приложения.
- Посмотрите логи в течение нескольких дней: количество обращений к
xmlrpc.phpдолжно упасть до нуля или до заблокированных попыток.
Проверка результата после внедрения
После отключения откройте https://example.com/xmlrpc.php в браузере или проверьте через curl. Если блокировка сделана на уровне WordPress, вы обычно увидите сообщение о недоступности XML-RPC или пустой ответ в зависимости от способа отключения.
Проверка должна быть не только визуальной. Смотрите на три вещи:
- нет ли новых успешных запросов к
xmlrpc.phpв access-логах; - не появились ли ошибки у внешних интеграций;
- не выросла ли нагрузка на сайт из-за других причин, которые вы могли спутать с XML-RPC.
Если используете плагин безопасности, проверьте его журнал событий: там часто видно, что запросы начали блокироваться ещё до обработки WordPress.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали публикацию из мобильного приложения
Это значит, что вы не проверили сценарии использования заранее. Верните доступ, если приложение действительно нужно, или переведите рабочий процесс на обычную админку и REST API.
Добавили код в родительскую тему
После обновления темы настройка может исчезнуть. Для таких правок используйте дочернюю тему или mu-plugin.
Закрыли файл в .htaccess, но забыли про Nginx
Если сайт работает на Nginx, правило из Apache не сработает. Нужно править именно ту конфигурацию, которая реально обслуживает сайт.
Поставили плагин ради одной функции
Это не ошибка само по себе, но лишний плагин увеличивает поверхность конфликта. Если задача одна — отключить XML-RPC, лучше сделать это кодом или серверным правилом.
Что ещё стоит сделать вместе с отключением XML-RPC
Одна мера редко закрывает все проблемы безопасности. Если сайт регулярно получает переборы паролей, проверьте ещё и:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, темы и плагинов;
- наличие лишних админ-аккаунтов;
- логи на предмет повторяющихся запросов к служебным файлам.
Если вам нужен более широкий набор технических настроек без ручного редактирования десятка файлов, имеет смысл смотреть в сторону инструментов, которые закрывают сразу несколько типовых задач: отключение служебных функций, чистка дублей, техническая оптимизация и мелкие правки безопасности. Но для самой задачи отключения XML-RPC отдельный короткий код часто остаётся самым надёжным решением.
Мини-чек-лист перед выкладкой на прод
- Проверили, что XML-RPC не нужен для рабочих интеграций.
- Сделали бэкап перед правками.
- Добавили отключение в дочернюю тему или mu-plugin.
- При необходимости закрыли
xmlrpc.phpна уровне сервера. - Проверили доступ к сайту, мобильным приложениям и внешним сервисам.
- Посмотрели логи после внедрения.
Если после отключения всё работает как раньше, а обращения к xmlrpc.php исчезли, значит задача решена правильно: без лишнего шума, без поломок и без зависимости от случайных плагинов.