StatusCake маскируется под браузер — и это не спуфинг, а норма

Если фильтровать access.log по statuscake, часто всплывает целый пласт машинных хитов — это и есть StatusCake. StatusCake — британский сервис мониторинга сайтов: проверяет доступность и скорость ответа, тестирует SSL-сертификаты и сроки действия доменов, отправляет email/SMS/Slack-алерты при простое или деградации. Сервис предлагает бесплатный и платные тарифы и часто сравнивается с UptimeRobot как более функциональная альтернатива (многошаговое тестирование форм, разнообразные типы проверок — HTTP, TCP, DNS).

Что такое StatusCake

Почему это не просто лёгкий пинг

В отличие от многих простых uptime-мониторов, которые ограничиваются коротким HEAD- или GET-запросом, StatusCake умеет выполнять полноценное браузерное тестирование: имитировать реальное поведение пользователя, включая рендеринг страницы, обнаружение JS-ошибок, проверку SSL и замер реальной скорости загрузки. Это значит, что при частых или комплексных проверках нагрузка на сервер может быть заметнее, чем от простого «пингующего» монитора — особенно если задействовано тестирование многошаговых сценариев (например, форм или процесса оформления заказа).

Если сайт стоит за антибот-защитой

Практический нюанс, особенно актуальный при использовании WAF или сервисов вроде Incapsula/Imperva: агрессивная защита от ботов может ложно блокировать легитимные проверки StatusCake или подсовывать им challenge-страницы вместо реального контента, что приводит к ложным срабатываниям «сайт недоступен». Сама компания в своей базе знаний прямо рекомендует владельцам сайтов заранее добавлять точную строку UA StatusCake в исключения на стороне защиты — иначе мониторинг будет давать неверные алерты не из-за реальных проблем сайта, а из-за самой защиты.

Сначала уточните у команды

Как и для большинства сервисов мониторинга доступности, действует общее правило: прежде чем банить, стоит спросить DevOps/SRE-команду (свою или клиента), не настроен ли под этим именем реальный health-check. Появление StatusCake в логах почти всегда означает, что кто-то сознательно поставил конкретный URL на отслеживание, а не что сайт стал целью постороннего обхода.

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

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

Типичный кейс: маркетинг видит всплеск хитов в Метрике/GA, но сессии пустые. Причина — StatusCake. Правильная реакция — не «выключить сайт», а точечно запретить UA/политику бота, предварительно убедившись, что мониторинг действительно не нужен.

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

Отдельной строки в публичной сводке top-bot TrafficVeil у statuscake может не быть, но в категории «Мониторинг доступности» такие агенты дают характерный фон: частые probe-запросы засоряют логи; чужой мониторинг может ходить чаще, чем нужно вашему SLA. Смотрите не только абсолютный RPS, но и качество хитов: глубина обхода, повторы одних и тех же URL, отсутствие cookie/сессий и концентрация на служебных или листовых страницах.

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

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

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

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

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

Верификация

Подделать User-Agent может любой скрипт. Для решения allow/deny смотрите связку: UA + ASN/IP + частоту + набор URL.

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

robots.txt для StatusCake

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

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

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

Важно: учитывая противоречивые данные о фактическом соблюдении robots.txt, для гарантированного результата переходите к nginx/Apache или запрету в TrafficVeil, а не полагайтесь только на файл.

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

Nginx

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

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

Apache (.htaccess)

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

TrafficVeil

• Найдите statuscake / StatusCake в ботах домена или в /system/bots
• Для нежелательного сценария — категория «запретить»; для мягкого — rate-limit
• Allow только при явной пользе от StatusCake — то есть если это реальный мониторинг вашего или клиентского сайта
• После изменения сверьте логи: хиты StatusCake должны уйти в блок/лимит, а нужные поисковики остаться

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

• Если это не ваш checker — смело ограничивайте
• Если ваш — внесите IP/UA в allowlist TrafficVeil, а также проверьте, что WAF/антибот-защита не блокирует его случайно ложными срабатываниями
• Если нагрузка мешает из-за полноценного браузерного тестирования — сначала rate-limit, затем полный запрет
• Не режьте слишком широко User-agent: *, чтобы случайно не закрыть Googlebot/YandexBot

С кем не путать StatusCake

Стратегия allow/deny для StatusCake