Файл xmlrpc.php до сих пор включён во многих установках WordPress, хотя в реальных проектах он часто не нужен. Его отключают не из-за моды, а чтобы сократить поверхность атаки, убрать лишние запросы и избавиться от шумных обращений ботов. Но отключать его вслепую нельзя: у части сайтов через XML-RPC работают мобильные клиенты, внешние публикации и старые интеграции.
Ниже — рабочий сценарий: как понять, нужен ли вам xmlrpc.php, как закрыть доступ без поломок и как быстро проверить результат.
Когда xmlrpc.php действительно можно отключать
Если сайт редактируется только через админку WordPress, а внешние сервисы не публикуют записи и не синхронизируют комментарии, XML-RPC обычно не нужен. На практике его оставляют включённым по инерции: «на всякий случай», хотя этот файл часто становится лишней точкой входа для перебора паролей и массовых запросов.
Перед изменениями проверьте, нет ли у вас зависимостей:
- мобильное приложение WordPress для публикации и редактирования;
- сторонние сервисы автопостинга;
- старые интеграции с десктопными редакторами;
- синхронизация комментариев или удалённые вызовы через XML-RPC;
- плагины, которые явно используют
xmlrpc.phpдля связи с внешним сервисом.
Быстрая диагностика
Самый простой тест — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в статистике безопасности. Если видите только ботов и сканеры, а легитимных запросов нет, отключение обычно безопасно.
Можно также проверить ответ вручную:
curl -I https://example.com/xmlrpc.phpЕсли файл доступен, сервер обычно вернёт ответ от WordPress или веб-сервера. Это ещё не означает, что он нужен, но подтверждает, что точка входа открыта.
Как отключить xmlrpc.php: три рабочих подхода
Ниже — варианты с разным уровнем жёсткости. Для большинства сайтов достаточно первого или второго. Третий вариант полезен, если нужен именно запрет на уровне сервера.
| Способ | Что делает | Когда выбирать | Минус |
|---|---|---|---|
| Фильтр в WordPress | Блокирует XML-RPC на уровне PHP | Если нужен быстрый и обратимый способ | Запрос всё равно доходит до WordPress |
Правило в .htaccess или nginx | Отсекает запросы до WordPress | Если нужен более жёсткий запрет | Нужно аккуратно править конфиг сервера |
| Плагин безопасности | Даёт переключатель в интерфейсе | Если админка уже используется для защиты | Добавляет зависимость от плагина |
Вариант 1. Отключить через код WordPress
Если у вас есть доступ к теме или небольшому must-use плагину, можно отключить XML-RPC через фильтр xmlrpc_enabled. Это простой и понятный способ, который легко откатить.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы, но для продакшена лучше вынести его в отдельный мини-плагин или mu-plugin, чтобы изменение темы не повлияло на защиту.
Вариант 2. Закрыть доступ на уровне сервера
Если задача — не просто отключить функциональность, а убрать сам доступ к файлу, используйте правила веб-сервера.
Для Apache в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx обычно добавляют отдельное правило в конфиг сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот вариант лучше защищает от лишнего трафика, потому что запросы не доходят до WordPress. Но перед применением убедитесь, что у вас есть доступ к настройкам сервера и вы понимаете, как откатить изменение.
Вариант 3. Использовать плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, есть ли в нём отдельная настройка для XML-RPC. Это удобно, когда нужно быстро включать и выключать защиту без правки файлов. Но не стоит ставить плагин только ради одной кнопки, если сайт и так перегружен расширениями.
Если вы уже используете комплексную чистку и защиту, например Clearfy Pro, имеет смысл проверить, не закрывает ли он лишние точки входа и не дублирует ли ваши ручные правила. Важно не включать одинаковые ограничения сразу в плагине, .htaccess и в коде, иначе потом будет сложно понять, что именно ломает интеграцию.
Пошаговое решение без риска для сайта
- Сначала проверьте логи и список интеграций, которые могут использовать XML-RPC.
- Сделайте резервную копию конфигурации сервера и файла
functions.php, если правите код вручную. - Выберите один способ отключения: код, сервер или плагин.
- Внесите изменение только в одном месте, не дублируйте правила.
- Проверьте доступ к сайту, авторизацию в админке и внешние сценарии публикации.
Если у вас staging-окружение, сначала повторите отключение там. Это особенно полезно, когда на сайте есть старые интеграции, о которых уже никто не помнит.
Как проверить, что решение сработало
После отключения откройте https://example.com/xmlrpc.php в браузере или проверьте через curl. Ожидаемое поведение зависит от способа блокировки: либо сервер отдаёт отказ в доступе, либо WordPress больше не принимает XML-RPC-запросы.
Дополнительно проверьте:
- вход в админку по обычной форме логина;
- создание и редактирование записей в редакторе;
- работу контактных форм и других AJAX-запросов, если они есть;
- внешние сервисы, которые могли публиковать контент;
- логи сервера на предмет повторяющихся ошибок по
xmlrpc.php.
Если после отключения сайт продолжает работать, а в логах исчезли обращения к XML-RPC, задача решена корректно.
Частые ошибки и как их исправить
Отключили не тот файл
Иногда администраторы закрывают весь доступ к корню сайта или добавляют слишком широкое правило в .htaccess. В результате ломается не XML-RPC, а нормальная работа сайта. Исправление простое: оставьте правило только для /xmlrpc.php, без лишних масок.
Сломали внешнюю публикацию
Если после отключения перестали работать мобильные приложения или автопостинг, значит, XML-RPC реально использовался. В этом случае либо верните доступ, либо переведите интеграцию на другой способ, если сервис его поддерживает.
Включили защиту в двух местах
Типичная ошибка — одновременно добавить фильтр в WordPress, правило в nginx и настройку в плагине безопасности. Потом трудно понять, где именно блокируется запрос. Для поддержки лучше оставить один основной механизм и один резервный, если он действительно нужен.
Забыли про кеш и CDN
Если перед сайтом стоит CDN или reverse proxy, старые ответы могут сохраняться в кеше. После изменения очистите кеш на стороне плагина, сервера и CDN, иначе проверка даст ложный результат.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет базовую защиту входа. Если на сайте слабые пароли и нет ограничения попыток авторизации, ботам всё равно будет чем заняться. Но убрать лишний публичный endpoint — разумный шаг, особенно на небольших проектах.
- держите только один способ отключения, чтобы не усложнять поддержку;
- не правьте
functions.phpна живом сайте без бэкапа; - после изменений проверьте логи ошибок сервера;
- если сайт активно интегрируется с внешними сервисами, сначала тестируйте на staging;
- не ставьте тяжёлый security-плагин только ради одной функции, если достаточно серверного правила.
Если задача шире и вы параллельно чистите сайт от лишних точек входа, имеет смысл смотреть на защиту комплексно: убрать неиспользуемые функции, отключить ненужные endpoints и не плодить дублирующие правила. Это обычно даёт более предсказуемый результат, чем набор разрозненных «усилителей безопасности».