AccessStatus — по независимой классификации это монитор HTTP-статусов: бот регулярно проверяет, отвечает ли конкретная страница, и с каким кодом — доступна, редиректит или отдаёт ошибку. Это та же категория, что у UptimeRobot, Better Uptime Bot и SentryUptimeBot — сервисов, которые сайт обычно подключает сам, чтобы получать уведомления о падениях.
1. Что такое AccessStatus на самом деле
По независимым каталогам ботов AccessStatus описывается однотипно с другими известными аптайм-мониторами: он проверяет HTTP-статус страниц, чтобы определить, активен ли URL, редиректит ли он или возвращает ошибку — классическая задача uptime-мониторинга. В отличие от Chirp (сервис Binary Canary, разобранный в этой энциклопедии отдельно), для AccessStatus не удалось найти отдельной, узнаваемой компании с собственным сайтом или продуктовой страницей — только устойчивую, повторяющуюся функциональную классификацию.
Практический вывод из этого: сама природа задачи (проверка доступности конкретного URL) делает крайне маловероятным сценарий, при котором кто-то посторонний целенаправленно мониторит чужой сайт без всякой причины — аптайм-мониторинг почти всегда результат того, что владелец сайта, его агентство или хостинг-провайдер сами подключили такой сервис.
| Параметр | Значение |
| Название | AccessStatus |
| Оператор | Конкретная компания не установлена — независимые каталоги ботов классифицируют его как отдельный, самостоятельный uptime-монитор в общем ряду с UptimeRobot, Better Uptime, SentryUptimeBot |
| Роль | Проверка HTTP-статус-кодов страниц для uptime-мониторинга (доступность, редиректы, ошибки) |
| User-Agent / паттерн | accessstatus |
| Кто обычно инициирует | Сам владелец сайта, его агентство или хостинг-провайдер — стандартная модель для сервисов этого типа |
| Паттерн поведения | Регулярные проверки с интервалом, похожим на cron-расписание, ограниченные обычно одной-двумя страницами |
| robots.txt | Данных о соблюдении нет |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы |
2. Зачем AccessStatus приходит на сайт
- регулярная, обычно частая проверка, отвечает ли сайт и с каким статус-кодом — базовая задача аптайм-мониторинга;
- проверка конкретных URL на редиректы или ошибки — например, после деплоя или изменений на сайте;
- почти всегда это результат того, что кто-то сознательно подключил мониторинг именно этого сайта или конкретных его страниц.
Типичный кейс: в логах фиксируется регулярный, стабильный по частоте паттерн запросов к одной-двум страницам — главной или служебному health-check эндпоинту. Это ожидаемое поведение подключённого мониторинга, а не аномалия или посторонний обход.
3. Нагрузка и риски
Нагрузка минимальна по своей природе — сервисы такого типа запрашивают, как правило, одну-две страницы с регулярным интервалом, а не обходят сайт целиком. Прямого риска для контента нет — цель технической проверки статуса не связана со сбором данных.
Основной практический риск — не в самом боте, а в возможной путанице при смене владельца или подрядчика сайта: если подключение к сервису мониторинга осталось активным от предыдущего клиента, регулярные проверки могут восприниматься как непонятный фоновый шум.
4. Как найти AccessStatus в логах
# Базовый поиск
grep -i "accessstatus" /var/log/nginx/access.log
# Топ URL — ожидаемо одна-две страницы
grep -i "accessstatus" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA
grep -i "accessstatus" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Регулярность интервалов — характерный признак мониторинга
grep -i "accessstatus" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1,2 | sort | uniq -cВерификация. Строку UA подделать может любой скрипт. Официального списка IP-диапазонов не найдено — для решения allow/deny смотрите связку UA + IP/ASN + характерную регулярность интервалов и узкий набор запрашиваемых URL, типичный для аптайм-монитора:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"5. robots.txt для AccessStatus
# Жёсткий запрет — сломает мониторинг, если он используется сознательно
User-agent: accessstatus
Disallow: /
# Разрешить всё — рекомендуемый вариант по умолчанию
User-agent: accessstatus
Allow: /6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "accessstatus") {
return 403;
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} accessstatus [NC]
RewriteRule ^ - [F,L]TrafficVeil:
- прежде чем блокировать — уточните у команды/клиента, не подключён ли мониторинг доступности сознательно;
- если используется — allow, дополнительно ограничивать не требуется, нагрузка минимальна по природе сервиса;
- если сайт сменил владельца/подрядчика и подключение осталось от прежнего — правильнее отвязать мониторинг через сам сервис, а не только блокировать технически;
- после изменения сверьте логи и, если применимо, убедитесь, что нужный вам мониторинг продолжает работать.
7. Что делать: короткий алгоритм
- Первый шаг: выяснить, подключён ли сайт к сервису мониторинга доступности сознательно — это быстрее и надёжнее технической диагностики;
- Подключён и нужен — allow, не трогать;
- Подключение неактуально или осталось от прежнего владельца — отвязать через сам сервис, если получится его идентифицировать, либо блокировать при отсутствии такой возможности;
- Точно посторонний и нежелательный — Disallow + запрет в TrafficVeil, риска для контента при этом нет;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.
8. С кем не путать AccessStatus
| Бот / сосед | Кластер | Комментарий |
| Chirp | Прочие краулеры и сервисы (см. отдельную статью) | Тот же тип задачи (мониторинг доступности), но с установленным оператором — Binary Canary |
| UptimeRobot | Не в базе TrafficVeil, но стоит знать | Крупнейший и наиболее известный аптайм-монитор с открытой документацией — хороший ориентир по типу поведения |
| Better Uptime Bot | Не в базе TrafficVeil, но стоит знать | Аналог от Better Stack, та же классификация Developer Helper |
| SentryUptimeBot | Не в базе TrafficVeil, но стоит знать | Часть платформы Sentry — тоже cron-подобные проверки конкретных эндпоинтов |
9. Стратегия allow/deny для AccessStatus
| Ситуация | Действие |
| Мониторинг подключён сознательно и нужен | Allow — это собственная (или клиентская) инфраструктура мониторинга |
| Неясно, чьё это подключение | Уточнить у команды/клиента, прежде чем принимать решение |
| Подключение осталось от прежнего владельца/подрядчика | Отвязать через сервис мониторинга, если удастся его идентифицировать |
| Точно посторонний, мониторинг не нужен | Disallow + запрет в TrafficVeil |
| Подозрение на подделку UA | Проверять регулярность интервалов и узкий набор URL — нетипичное поведение для аптайм-монитора повод для дополнительной проверки IP/ASN |