AccessStatus: вероятно, ваш мониторинг доступности

AccessStatus — по независимой классификации это монитор HTTP-статусов: бот регулярно проверяет, отвечает ли конкретная страница, и с каким кодом — доступна, редиректит или отдаёт ошибку. Это та же категория, что у UptimeRobot, Better Uptime Bot и SentryUptimeBot — сервисов, которые сайт обычно подключает сам, чтобы получать уведомления о падениях.

1. Что такое AccessStatus на самом деле

По независимым каталогам ботов AccessStatus описывается однотипно с другими известными аптайм-мониторами: он проверяет HTTP-статус страниц, чтобы определить, активен ли URL, редиректит ли он или возвращает ошибку — классическая задача uptime-мониторинга. В отличие от Chirp (сервис Binary Canary, разобранный в этой энциклопедии отдельно), для AccessStatus не удалось найти отдельной, узнаваемой компании с собственным сайтом или продуктовой страницей — только устойчивую, повторяющуюся функциональную классификацию.

Практический вывод из этого: сама природа задачи (проверка доступности конкретного URL) делает крайне маловероятным сценарий, при котором кто-то посторонний целенаправленно мониторит чужой сайт без всякой причины — аптайм-мониторинг почти всегда результат того, что владелец сайта, его агентство или хостинг-провайдер сами подключили такой сервис.

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

9. Стратегия allow/deny для AccessStatus