XML-RPC в WordPress до сих пор часто остается включенным по умолчанию, хотя на большинстве сайтов он не нужен. Проблема в том, что его отключают «на всякий случай», а потом внезапно ломают мобильную публикацию, внешние редакторы, интеграции с Jetpack или старые сценарии удаленного доступа. Поэтому правильный подход здесь не «выключить всё», а сначала понять, используется ли endpoint /xmlrpc.php вообще.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешние клиенты для публикации, не подключен к сервисам, которым нужен XML-RPC, и вы не видите запросов к xmlrpc.php в логах, отключение имеет смысл. Это не универсальная мера безопасности, а точечное снижение поверхности атаки. На практике XML-RPC чаще всего оставляют включенным по привычке, хотя админка, REST API и обычная авторизация уже закрывают большинство рабочих сценариев.
Отключать endpoint стоит особенно внимательно, если на сайте нет:
- Jetpack или других сервисов, которые завязаны на XML-RPC;
- мобильных приложений для публикации через старый XML-RPC;
- интеграций с внешними CMS или скриптами, использующими
system.multicallилиmetaWeblog.newPost; - старых автоматизаций, которые отправляют пинги или обновляют записи удаленно.
Диагностика: используется ли xmlrpc.php сейчас
Перед изменениями проверьте, есть ли реальные обращения к endpoint. Самый простой способ — посмотреть access log веб-сервера и найти запросы к /xmlrpc.php. Если логов нет под рукой, можно временно включить мониторинг на уровне сервера или проверить через инструменты аналитики и WAF, если они фиксируют URL запросов.
Полезно также проверить, не завязан ли сайт на Jetpack. Если в админке есть активное соединение с WordPress.com, отключение XML-RPC может повлиять на синхронизацию статистики, публикации и некоторых удаленных функций. В этом случае сначала отключают только лишние методы или ограничивают доступ по IP, а не рубят endpoint полностью.
Что искать в логах
- частые POST-запросы к
/xmlrpc.php; - серии запросов с одинакового IP;
- ошибки 401, 403 или 405 после попыток обращения;
- подозрительные вызовы
system.multicall.
Пошаговое решение: три рабочих способа
Выбор зависит от того, где вам удобнее контролировать доступ: в коде, в плагине или на сервере. Если нужен быстрый и проверяемый вариант для типового сайта, чаще всего достаточно кода в functions.php дочерней темы или в небольшом mu-plugin.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в WordPress | Нужен контроль внутри сайта | Срабатывает только после загрузки WordPress |
| Плагин безопасности | Нужно отключить без правки темы | Лишняя зависимость от плагина |
| Правило на сервере | Нужно отсечь запросы до PHP | Требует доступа к конфигу сервера |
Способ 1. Отключить XML-RPC через код
Если вы хотите просто запретить доступ к endpoint, используйте фильтр xmlrpc_enabled. Это безопаснее, чем удалять файл или править ядро. Код можно добавить в functions.php дочерней темы или в отдельный mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC интерфейс, но не удаляет файл xmlrpc.php. Для большинства задач этого достаточно. Если сайт использует только обычную авторизацию в админке и REST API, ничего критичного не произойдет.
Способ 2. Заблокировать доступ к xmlrpc.php на сервере
Если у вас есть доступ к конфигурации веб-сервера, лучше отсечь запросы раньше, чем они дойдут до WordPress. Для Apache можно использовать правило в .htaccess, для Nginx — отдельный location. Это полезно на нагруженных сайтах, где важно не тратить PHP-ресурсы на заведомо лишние запросы.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика обычно выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если сайт работает через нестандартный стек или прокси, сначала проверьте, где именно отрабатывает правило, чтобы не заблокировать лишнее. После изменения конфигурации обязательно сделайте reload сервера, а не просто сохраните файл.
Способ 3. Ограничить XML-RPC через плагин
Если не хочется лезть в код, можно использовать плагин безопасности, который умеет отключать XML-RPC или ограничивать доступ к нему. Это удобнее для редактора или администратора без доступа к серверу, но в долгую такой способ добавляет еще один слой зависимости. Если у вас уже стоит плагин для чистки и SEO-оптимизации, например Clearfy Pro, проверьте, нет ли там отдельной опции для отключения XML-RPC и других лишних функций WordPress: https://wpshop.ru/plugins/clearfy.
Как не сломать Jetpack, мобильную публикацию и внешние интеграции
Главная ошибка — отключить XML-RPC без проверки зависимостей. Если у вас есть подключение к WordPress.com, мобильное приложение для публикации или внешний сервис, который отправляет записи через XML-RPC, он перестанет работать сразу после блокировки. Поэтому перед изменением полезно пройтись по списку интеграций и понять, кто именно обращается к сайту.
Если вы не уверены, временно ограничьте доступ по IP или включите журналирование запросов к xmlrpc.php. Так вы увидите, есть ли реальные клиенты, и сможете принять решение без гадания. Для сайтов с редкими удаленными публикациями иногда достаточно не полного отключения, а блокировки только самых опасных методов, например system.multicall. Но это уже более тонкая настройка и требует тестирования.
Проверка результата после внедрения
После отключения проверьте не только главную страницу, но и сам endpoint. Откройте /xmlrpc.php в браузере или через curl. Если блокировка настроена правильно, вы должны получить отказ в доступе на уровне сервера или сообщение о том, что XML-RPC отключен, в зависимости от способа.
curl -I https://example.com/xmlrpc.phpЧто считать нормальным результатом:
- сервер возвращает
403 Forbiddenили404 Not Foundпри серверной блокировке; - WordPress не принимает XML-RPC вызовы, если отключение сделано через фильтр;
- админка, REST API и обычная авторизация продолжают работать;
- Jetpack и внешние сервисы не показывают ошибок, если они не завязаны на XML-RPC.
Если вы используете мониторинг, проверьте, что после изменения не выросло число 5xx-ошибок и не появились новые записи в error log. Иногда проблема не в самом XML-RPC, а в кривом правиле на сервере, которое зацепило соседние location или директивы.
Частые ошибки и как их исправить
Отключили XML-RPC в коде, но endpoint все еще отвечает
Так бывает, если код добавили не туда или тема не активна. Проверьте, что правило лежит в дочерней теме, mu-plugin или в активной теме. Для быстрой проверки можно временно включить логирование ошибок PHP и убедиться, что файл действительно загружается.
Сломался Jetpack или мобильное приложение
Значит, XML-RPC использовался реально. Верните доступ и проверьте интеграции. Иногда достаточно не полного отключения, а ограничения по IP или замены старого сценария на REST API, если сервис это поддерживает.
На сервере поставили deny, а WordPress все равно обрабатывает запрос
Это обычно означает, что правило не попало в нужный server block или .htaccess не читается из-за конфигурации Apache. Проверьте, что сайт действительно работает через тот веб-сервер, для которого вы пишете правило, и что после изменения был применен reload/restart.
Появились ошибки 500
Чаще всего причина в синтаксисе конфигурации или в том, что правило вставили в неподходящее место. Откатите изменение, проверьте конфиг через nginx -t или аналогичную проверку для Apache, затем внесите правку заново.
Практические советы по безопасности и производительности
Если цель — не просто отключить один endpoint, а уменьшить поверхность атаки, смотрите шире. На сайте часто остаются включенными и другие лишние вещи: эмодзи-скрипты, oEmbed для внешних запросов, REST-эндпоинты, которые не нужны публично, и старые ревизии. Но отключать их стоит только после проверки, потому что часть функций может использоваться темой или плагинами.
- не правьте ядро WordPress вручную;
- используйте дочернюю тему или mu-plugin для кода;
- сначала тестируйте на staging-копии;
- после изменений проверяйте логи сервера;
- не отключайте интеграции, если не знаете, кто их использует;
- для серверной блокировки держите резервный доступ к конфигу.
Если на сайте уже есть плагин для технической чистки и SEO-настроек, можно централизовать часть таких правок в одном месте, но не смешивайте в один комок все подряд. Чем меньше «магии» в админке, тем проще потом понять, почему сайт перестал принимать внешние запросы.
В итоге рабочая схема простая: сначала выясняете, нужен ли XML-RPC, затем выбираете уровень блокировки, после этого проверяете endpoint и логи. Такой порядок экономит время и не превращает безопасность в источник случайных поломок.