Если на сайте не используются старые мобильные клиенты WordPress, внешние сервисы публикации и pingback, файл xmlrpc.php чаще всего только добавляет поверхность атаки. Но отключать его «в лоб» не стоит: на части сайтов через него до сих пор работают интеграции, а некоторые хостинги и плагины завязаны на специфическое поведение XML-RPC.
Ниже — рабочий сценарий: сначала быстро понять, нужен ли xmlrpc.php именно вам, потом отключить его на уровне WordPress или веб-сервера, а затем проверить, что ничего лишнего не отвалилось.
Когда xmlrpc.php действительно стоит отключать
Проблема обычно не в самом файле, а в том, что он доступен извне и может использоваться для перебора паролей, pingback-спама и лишних запросов к сайту. Если вы не пользуетесь внешней публикацией, приложениями для старых версий WordPress и не принимаете pingback с других сайтов, держать XML-RPC открытым смысла мало.
Но есть и обратная сторона: некоторые интеграции до сих пор используют XML-RPC как запасной канал. Поэтому сначала проверьте фактическое использование.
Быстрая диагностика
- Посмотрите логи веб-сервера на запросы к
/xmlrpc.php. - Проверьте, нет ли у вас мобильных приложений или внешних сервисов, которые публикуют записи через WordPress API старого типа.
- Убедитесь, что сайт не использует pingback как часть старого workflow.
Если запросы к xmlrpc.php идут массово и вы не знаете, откуда они, это уже повод отключать его хотя бы на уровне сервера.
Как отключить xmlrpc.php через PHP
Самый аккуратный способ — запретить доступ из WordPress, не трогая конфигурацию сервера. Это удобно, если у вас нет прямого доступа к .htaccess или nginx-конфигу, либо нужно быстро проверить эффект.
Добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Для постоянного решения mu-plugin надежнее: он не зависит от темы.
<?php
add_filter('xmlrpc_enabled', '__return_false');
Этот фильтр отключает XML-RPC на уровне WordPress. В ответ на запросы к xmlrpc.php сайт обычно будет возвращать ошибку доступа или пустой ответ в зависимости от окружения.
Если нужно не просто отключить функциональность, а явно блокировать сам endpoint, можно добавить более жесткую проверку:
<?php
add_filter('xmlrpc_methods', function ($methods) {
return array();
});
Такой вариант менее универсален, чем xmlrpc_enabled, и обычно нужен только в специфических сценариях. Для большинства сайтов достаточно первого фильтра.
Как закрыть xmlrpc.php на уровне .htaccess
Если сайт работает на Apache или LiteSpeed с поддержкой .htaccess, блокировка на уровне веб-сервера снимает нагрузку раньше, чем запрос дойдет до WordPress. Это полезно, когда идет брутфорс или массовые обращения к endpoint.
Добавьте правило в корневой .htaccess выше стандартного блока WordPress:
<Files xmlrpc.php>
Require all denied
</Files>
На старых конфигурациях Apache 2.2 иногда встречается синтаксис через Deny from all, но на современных серверах лучше использовать Require all denied.
Если у вас nginx, аналогичное правило обычно добавляют в конфиг сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
После правки конфигурации не забудьте проверить и перезагрузить веб-сервер, иначе правило не вступит в силу.
Что выбрать: код, сервер или плагин
Если нужен именно технический контроль, код или серверное правило предпочтительнее. Плагин удобен для админов без доступа к конфигам, но добавляет еще один слой логики и не всегда блокирует запрос раньше WordPress.
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Быстро, просто, без правок сервера | Запрос все равно доходит до WordPress | Нет доступа к конфигам, нужен быстрый фикс |
.htaccess / nginx | Блокирует раньше, меньше лишней нагрузки | Нужен доступ к серверу | Есть подозрение на брутфорс или спам |
| Плагин безопасности | Удобно для неразработчика | Лишняя зависимость, не всегда прозрачная логика | Когда нужен интерфейс и централизованные настройки |
Если у вас уже стоит плагин безопасности, проверьте, не отключает ли он XML-RPC сам. Дублировать одно и то же правило в нескольких местах не нужно: потом сложнее понять, почему endpoint ведет себя не так, как ожидается.
Пошаговое решение без поломки сайта
- Проверьте, используется ли XML-RPC в реальных интеграциях.
- Сделайте резервную копию файлов и, если возможно, базы.
- Сначала включите блокировку через
xmlrpc_enabledили серверное правило на тестовом окне. - Проверьте доступ к
/xmlrpc.phpиз браузера и черезcurl. - Посмотрите логи ошибок и логи доступа в течение нескольких часов после изменения.
Для проверки через командную строку удобно использовать такой запрос:
curl -i https://example.com/xmlrpc.phpЕсли блокировка работает, вы не должны получать нормальный ответ XML-RPC. В идеале endpoint должен возвращать отказ в доступе на уровне сервера или WordPress должен явно отключать функциональность.
Как проверить результат после внедрения
Проверка нужна не только на уровне ответа страницы. Важно убедиться, что отключение не задело другие части сайта.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере и убедитесь, что endpoint не отвечает как рабочий сервис. - Проверьте логи на предмет ошибок, связанных с XML-RPC, в течение 24 часов после изменения.
- Если у вас есть внешние сервисы публикации, попробуйте выполнить тестовый запрос из них.
- Убедитесь, что обычная авторизация в админке, REST API и публикация записей работают как раньше.
Если после отключения вы заметили, что какой-то сервис перестал публиковать записи, значит, он действительно использовал XML-RPC. В таком случае решение нужно пересмотреть, а не просто «включить обратно все подряд».
Частые ошибки и как их исправить
Отключили XML-RPC, но endpoint все равно отвечает
Чаще всего это значит, что код добавили не туда: в неактивную тему, в файл, который не загружается, или в плагин, который отключен. Для постоянного решения лучше использовать mu-plugin или серверное правило.
Сломали внешнюю публикацию или мобильное приложение
Значит, XML-RPC был нужен. Верните доступ только для конкретного сценария или переходите на REST API, если интеграция это поддерживает. Не оставляйте endpoint открытым «на всякий случай».
Добавили правило в .htaccess, но оно не работает
Проверьте, что сайт действительно работает на Apache/LiteSpeed и что модуль mod_authz_core поддерживает синтаксис Require all denied. На nginx этот файл вообще не влияет.
Поставили плагин и забыли, где именно отключение
Это типичная проблема при поддержке сайта. Через месяц никто не помнит, что блокирует endpoint: плагин, тема или сервер. Для технически важных ограничений лучше держать решение в одном месте и документировать его в репозитории или заметках проекта.
Что еще стоит проверить рядом с xmlrpc.php
Если вы уже чистите поверхность атаки, имеет смысл посмотреть и на другие точки входа: устаревшие админские учетные записи, слабые пароли, открытый REST API для лишних ролей, а также логи повторяющихся запросов к wp-login.php. Отключение XML-RPC не заменяет базовую защиту, но хорошо снижает шум и убирает один из популярных векторов атак.
Для сайтов, где важна именно техническая гигиена, полезно держать под рукой инструменты, которые помогают чистить лишние настройки и дубли в WordPress. Например, Clearfy Pro уместен как вспомогательный набор для SEO и технической чистки, если нужен централизованный контроль без ручного разбрасывания по нескольким плагинам: Clearfy Pro.
Главная идея простая: сначала выясняете, нужен ли XML-RPC, потом блокируете его там, где это надежнее для вашего стека, и только после этого проверяете реальные интеграции. Такой порядок экономит время и снижает шанс сломать рабочий сценарий ради формальной безопасности.