Если в логах регулярно всплывает xmlrpc.php, а сайт не использует Jetpack, старые мобильные клиенты или внешние сервисы публикации, этот файл обычно только создаёт лишнюю поверхность атаки. Но отключать его «в лоб» через случайный код из интернета не стоит: важно понимать, какой ответ должен отдавать сервер — 403 или 404, и не сломать то, что ещё зависит от XML-RPC.
Ниже — рабочая схема: сначала быстро диагностируем, нужен ли вам xmlrpc.php, потом отключаем его на уровне сервера или WordPress, затем проверяем ответ и смотрим, не остались ли обходные пути.
Когда xmlrpc.php действительно можно отключать
Файл xmlrpc.php нужен не всем. На современных сайтах его чаще всего используют только в старых сценариях:
- Jetpack и некоторые его функции;
- публикация через внешние клиенты и устаревшие мобильные приложения;
- удалённые вызовы API, которые были написаны давно и до сих пор ходят через XML-RPC;
- pingback и trackback, если они не отключены отдельно.
Если у вас обычный сайт на WordPress без таких интеграций, отключение обычно безопасно. Но если сайт подключён к стороннему сервису публикации, сначала проверьте, не использует ли он XML-RPC вместо REST API.
Диагностика: что сейчас делает xmlrpc.php
Перед изменениями посмотрите, как файл отвечает сейчас. Это поможет понять, где именно его лучше блокировать.
curl -I https://example.com/xmlrpc.phpНормальные варианты ответа до блокировки:
200или405— файл доступен, сервер его видит;403— уже есть ограничение на уровне сервера или WAF;404— файл скрыт или перенаправлен;500— есть проблема в правилах или в обработчике.
Если у вас включён доступ к логам, полезно проверить, кто именно стучится в этот файл. Часто это не реальный пользователь, а брутфорс-сканеры.
Что важно проверить до отключения
- используется ли Jetpack;
- есть ли внешняя публикация через старые приложения;
- не завязаны ли интеграции на XML-RPC по документации стороннего сервиса;
- не стоит ли уже отдельная защита на уровне Cloudflare, nginx, Apache или ModSecurity.
Как отключить xmlrpc.php: сравнение подходов
| Способ | Что даёт | Минус |
|---|---|---|
| Правило на сервере | Блокирует запрос до загрузки WordPress | Нужно править конфиг nginx/Apache или .htaccess |
| Фильтр в WordPress | Проще внедрить в теме или мини-плагине | WordPress всё равно загрузится |
| WAF/Cloudflare | Снимает нагрузку ещё раньше | Не всегда удобно для точечной настройки |
Если есть доступ к серверу, лучше блокировать на уровне веб-сервера. Если доступа нет, используйте фильтр в WordPress как запасной вариант.
Пошаговое решение на сервере
Вариант для Apache через .htaccess
Если сайт работает на Apache, добавьте правило выше стандартного блока WordPress:
<Files xmlrpc.php>
Require all denied
</Files>Это вернёт 403 Forbidden. Для большинства сайтов этого достаточно. Такой вариант лучше, чем попытка «ломать» файл через редирект на главную: редирект создаёт лишний шум и не решает задачу безопасности.
Вариант для nginx
На nginx блокировка делается в конфиге сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите nginx штатной командой, принятой в вашей системе. Не вносите это правило в случайный include-файл без понимания порядка обработки location.
Если нужен именно 404
Иногда хотят не 403, а 404, чтобы файл выглядел отсутствующим. Это допустимо, если вы сознательно скрываете наличие endpoint’а. На уровне сервера это делается аккуратно не всегда одинаково, поэтому чаще используют 403 как более прямой и понятный ответ. Для безопасности разница небольшая: важнее, чтобы WordPress не обрабатывал запросы к XML-RPC.
Запасной вариант в WordPress: мини-плагин или mu-plugin
Если серверные правила менять неудобно, можно добавить фильтр. Это не лучший первый выбор, но рабочий и предсказуемый способ.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код можно положить в обычный плагин или в mu-plugins, если нужно, чтобы он не выключался случайно из админки. Но помните: WordPress всё равно загрузится, а значит, защита слабее, чем на уровне nginx или Apache.
Проверка результата после внедрения
После изменения правил проверьте не только HTTP-код, но и поведение сайта в реальных сценариях.
- выполните
curl -I https://example.com/xmlrpc.phpи убедитесь, что ответ стал403или404; - откройте
https://example.com/xmlrpc.phpв браузере и проверьте, что нет формы входа, XML-ответа или ошибки PHP; - посмотрите access log: запросы к файлу должны либо блокироваться, либо не доходить до WordPress;
- если используется Jetpack, проверьте его состояние в админке;
- если есть внешняя публикация, протестируйте её на тестовом посте.
Если после блокировки сайт начал отдавать 500, значит, правило вставлено не туда или конфликтует с другими директивами. В таком случае сначала откатите изменение и проверьте порядок include-файлов и синтаксис конфигурации.
Частые ошибки и как их исправить
Ставят редирект вместо блокировки
Редирект на главную или на 404-страницу выглядит «красиво», но не решает задачу. Бот всё равно получает ответ, а сервер тратит ресурсы на лишнюю обработку. Для защиты лучше использовать прямой отказ.
Отключают xmlrpc.php, не проверив Jetpack
После блокировки Jetpack может потерять связь с сайтом. Если он нужен, сначала отключите только те функции, которые реально используют XML-RPC, или перенесите интеграцию на другой механизм.
Правило добавляют ниже общих rewrite-правил
В .htaccess порядок важен. Если блокировка стоит ниже правил WordPress, запрос может сначала попасть в переписывание и дать неожиданный результат. Правило для xmlrpc.php должно быть выше блока # BEGIN WordPress.
Путают отключение XML-RPC с отключением REST API
Это разные механизмы. Если вы закрыли xmlrpc.php, REST API продолжит работать. И наоборот. Не смешивайте эти задачи в одной правке, если не понимаете последствия.
Практические советы по безопасности и производительности
Если цель — не только убрать лишний endpoint, но и снизить шум в логах, полезно сделать ещё несколько вещей:
- отключить pingback и trackback, если они не нужны;
- проверить, не открыт ли
xmlrpc.phpчерез CDN или WAF-исключения; - не хранить блокировку только в теме — при смене темы она исчезнет;
- если сайт большой, блокировать на уровне сервера, чтобы не тратить PHP-процесс на пустые запросы.
Для сайтов, где нужно регулярно чистить технические дубли, служебные страницы и лишние настройки SEO, иногда удобнее держать это в одном наборе инструментов. Например, Clearfy Pro от WPShop закрывает часть типовых технических задач без ручного правления каждого файла, но серверные правила всё равно остаются самым надёжным вариантом для xmlrpc.php.
Если вы работаете с несколькими сайтами, заведите короткий чек-лист для каждого:
- есть ли Jetpack;
- используются ли старые мобильные клиенты;
- какой ответ отдаёт
/xmlrpc.phpсейчас; - где именно стоит блокировка — сервер, WAF или WordPress;
- проверен ли лог после внедрения.
В итоге задача сводится к простому правилу: блокируйте xmlrpc.php там, где это можно сделать раньше и надёжнее, а потом обязательно проверьте, что нужные интеграции не завязаны на этот endpoint. Тогда вы уберёте лишнюю поверхность атаки без случайных поломок.