HoneybadgerBot: скорее всего, ваша же команда следит за аптаймом

HoneybadgerBot стоит отдельного правила в антиботе: это не «ещё один hit», а повторяемый паттерн автоматизации в категории «Прочие краулеры и сервисы» — и, судя по названию, за этим токеном с высокой вероятностью стоит известный сервис мониторинга приложений, а не анонимный скрипт.

Что такое HoneybadgerBot

Почему это, вероятно, не «обход сайта», а узкий пинг

Если гипотеза о Honeybadger.io верна, у HoneybadgerBot принципиально иной характер поведения, чем у типичного краулера: инструменты uptime-мониторинга делают регулярные, но узкие запросы — проверяют доступность конкретной страницы или эндпоинта каждые несколько минут, а не сканируют сайт целиком.

• Какие зоны чаще трогает: одну-две заранее заданные точки мониторинга (главная страница, health-check эндпоинт), а не широкий набор URL
• Что ищет: подтверждение, что сайт отвечает, с какой задержкой и в порядке ли SSL-сертификат
• Чем отличается от массового краулера: регулярность вместо глубины — визиты происходят часто, но по очень узкому кругу адресов

Если в логах видно, что honeybadgerbot действительно обходит пагинацию и карточки товаров широко, а не бьёт по одной-двум точкам с равными интервалами — это повод усомниться в исходной гипотезе и присмотреться к поведению отдельно, не принимая совпадение имени за доказательство.

Зачем HoneybadgerBot приходит на сайт

Как и у большинства developer-инструментов такого типа (в этом смысле HoneybadgerBot напоминает уже разобранный ранее Bugsnag), наиболее вероятный сценарий — кто-то из вашей же команды разработки настроил мониторинг доступности сайта через Honeybadger, и бот просто выполняет свою прямую задачу: следит, чтобы сайт не упал незаметно. Типичный кейс: ночью RPS слегка растёт, конверсий нет. В access.log виден honeybadgerbot на одной-двух конкретных точках с равномерными интервалами. Прежде чем что-либо ограничивать, разумно уточнить у DevOps/разработки, не настроен ли у них Uptime Check через этот сервис.

Нагрузка и риски

Отдельной строки в публичной сводке top-bot TrafficVeil у honeybadgerbot может не быть, но в категории «Прочие краулеры и сервисы» такие агенты дают характерный фон: фоновый шум в аналитике, расход CPU/bandwidth и искажение статистики «живого» трафика. Для узкого uptime-пинга этот фон обычно минимален — если нагрузка ощутима, вероятно, речь о более широком мониторинге, чем просто проверка доступности. Смотрите не только абсолютный RPS, но и качество хитов: глубина обхода, повторы одних и тех же URL, отсутствие cookie/сессий и концентрация на служебных или листовых страницах.

Как найти HoneybadgerBot в логах

# Базовый поиск
grep -i "honeybadgerbot" /var/log/nginx/access.log

# Топ URL, которые вычитывает бот
grep -i "honeybadgerbot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA
grep -i "honeybadgerbot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность
grep -i "honeybadgerbot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Верификация

Подделать User-Agent может любой скрипт. Официального списка IP нет, поэтому для решения allow/deny смотрите связку: UA + ASN/IP + частоту + набор URL — особенно обращайте внимание на то, узкий это круг адресов (в пользу гипотезы про мониторинг) или широкий (повод сомневаться).

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

robots.txt для HoneybadgerBot

# Жёсткий запрет
User-agent: honeybadgerbot
Disallow: /

# Разрешить всё
User-agent: honeybadgerbot
Allow: /

# Компромисс: закрыть служебные разделы, оставить публичку
User-agent: honeybadgerbot
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

Важно: Disallow/403 для honeybadgerbot, если пользы нет. Если это действительно ваш собственный инструмент мониторинга доступности, блокировка лишит команду разработки уведомлений о падении сайта — прежде чем запрещать, уточните у коллег.

Блокировка вручную и через TrafficVeil

Nginx

if ($http_user_agent ~* "honeybadgerbot") {
    return 403;
}

limit_req_zone $binary_remote_addr zone=honeybadgerbot:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "honeybadgerbot") {
        limit_req zone=honeybadgerbot burst=20 nodelay;
    }
}

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} honeybadgerbot [NC]
RewriteRule ^ - [F,L]

TrafficVeil

• Найдите honeybadgerbot / HoneybadgerBot в ботах домена или в /system/bots
• Команда использует Honeybadger для uptime-мониторинга — оставляйте allow, блокировка отключит проверки доступности
• Сервис не используется — можно ставить запрет без риска для функциональности
• После изменения сверьте логи: хиты honeybadgerbot должны уйти в блок/лимит, а поисковики Google/Yandex остаться без изменений

Рекомендации: что делать с HoneybadgerBot

• Уточните у DevOps/разработки, не настроен ли мониторинг через Honeybadger, прежде чем блокировать — как и с Bugsnag, это, вероятно, ваш же инструмент
• Если пользы нет — Disallow/403 для honeybadgerbot
• Если нагрузка мешает, но сервис нужен — rate-limit как промежуточный шаг
• Не режьте слишком широко User-agent: *, чтобы случайно не закрыть Googlebot/YandexBot