Токен site24x7 в access.log почти никогда не бывает загадкой: это фирменный агент одноимённого сервиса мониторинга от Zoho (входит в линейку ManageEngine), причём с официально документированной строкой UA и публикуемым списком IP для алллистинга. Вопрос в логах обычно не «кто это», а «ваш ли это инструмент» — в каталоге TrafficVeil бот отмечен как легитимный, и решение allow/deny стоит принимать именно по этому критерию.
Что такое Site24x7
Site24x7 — далеко не только аптайм-чекер. По официальному описанию, это комплексный сервис мониторинга: помимо проверки доступности он выполняет Real User Monitoring, synthetic transaction monitoring (симуляция сложных пользовательских сценариев), проверяет API и работает с более чем 100 контрольных точек по всему миру. В стек также входят APM, серверный и облачный мониторинг — то есть тот же UA может стоять за самыми разными типами проверок, от простого health-check до сложного сценария прохождения по сайту.
| Параметр | Значение |
| Название | Site24x7 |
| User-Agent / паттерн | site24x7 (официальная строка: Mozilla/5.0 (compatible; Site24x7/1.0; +https://www.site24x7.com/)) |
| Оператор | Site24x7 (Zoho / ManageEngine) |
| Роль | Аптайм и производительность, Real User Monitoring, synthetic transaction monitoring, проверка API, APM/серверный/облачный мониторинг |
| Документация / ориентир | Официальная документация Site24x7, включая раздел с адресами для алллистинга исходящих подключений |
| Список IP | Публикуется официально в документации Site24x7 — актуальный список стоит сверять там же, а не полагаться на статичную копию |
| robots.txt | Крупный, давно работающий оператор — как правило соблюдает; для точечного контроля надёжнее опираться на UA + IP |
| Пометка TrafficVeil | Легитимный / Мониторинг доступности |
Зачем Site24x7 приходит на сайт
Как и любой сервис мониторинга, Site24x7 не «гуляет» по сайту в поисках контента — он проверяет конкретный набор URL, который явно указал пользователь сервиса при настройке проверки: обычно это главная, /health, /status или ключевая посадочная страница, а при synthetic transaction monitoring — целая цепочка страниц, имитирующая реальный пользовательский путь (например, от каталога до оформления заказа).
Типичный кейс из практики: ночью растёт RPS, конверсий при этом нет, а access.log забит запросами site24x7 на пагинации и карточках товаров. После настройки rate-limit или запрета через TrafficVeil origin остывает, а поисковые роботы Google и Yandex продолжают заходить без изменений — хороший быстрый способ убедиться, что правило сработало точечно, а не задело нужный трафик.
Нагрузка и риски
Отдельной строки в публичной сводке топ-ботов TrafficVeil у site24x7 может не быть, но у мониторинговых агентов в целом есть характерный фон: частые probe-запросы засоряют логи, а если сайт мониторит не только владелец, но и сторонний наблюдатель (партнёр, клиент, конкурент), совокупная частота проверок может превышать то, что реально нужно вашему SLA — особенно если задействован не просто health-check, а более тяжёлый synthetic transaction сценарий с проходом по нескольким страницам. Смотрите не только на абсолютный RPS, но и на:
- глубину обхода — простой health-check бьёт по 1-2 URL, synthetic transaction monitoring может затрагивать целую цепочку страниц;
- повторяемость одних и тех же адресов через стабильные интервалы;
- отсутствие cookie и признаков полноценной сессии.
Как найти Site24x7 в логах
Ищите конкретный токен site24x7, а не общее слово «bot».
# Базовый поиск
grep -i "site24x7" /var/log/nginx/access.log
# Топ URL, которые вычитывает бот
grep -i "site24x7" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA
grep -i "site24x7" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Суточная активность
grep -i "site24x7" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
Поскольку Site24x7 официально публикует список IP-адресов для алллистинга своих проверок, верификация здесь надёжнее, чем для многих других ботов: если UA заявляет site24x7, а IP не входит в опубликованный документацией диапазон, это весомый повод заподозрить спуфинг. Классическая связка whois/reverse DNS дополнительно подтверждает картину:
IP="1.2.3.4" whois -h whois.cymru.com " -v $IP" dig +short -x "$IP"
Правила robots.txt для Site24x7
# Жёсткий запрет User-agent: site24x7 Disallow: / # Разрешить всё User-agent: site24x7 Allow: / # Компромисс: закрыть деньги/кабинет, оставить публичную часть User-agent: site24x7 Disallow: /admin/ Disallow: /cart/ Disallow: /checkout/ Disallow: /account/ Disallow: /api/ Allow: /
Как давний и крупный оператор, Site24x7 обычно уважает директивы robots.txt. Но если настроен synthetic transaction monitoring с частым интервалом по нескольким страницам, одного файла может не хватить для контроля нагрузки — стоит сразу сочетать его с rate-limit на сервере или в TrafficVeil.
Блокировка вручную и через TrafficVeil
Nginx
if ($http_user_agent ~* "site24x7") {
return 403;
}
limit_req_zone $binary_remote_addr zone=site24x7:10m rate=10r/m;
location / {
if ($http_user_agent ~* "site24x7") {
limit_req zone=site24x7 burst=20 nodelay;
}
}
Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} site24x7 [NC]
RewriteRule ^ - [F,L]
TrafficVeil
- найдите site24x7 / Site24x7 в ботах домена или в
/system/bots; - если это чужой чекер — категория «запретить»; если нагрузка от своего же мониторинга просто слишком частая — rate-limit;
- allow оставляйте, если проверку настраивали именно вы или ваша команда, и по возможности сверьте IP с официальным списком Site24x7;
- после изменения сверьте логи: хиты Site24x7 должны уйти в блок/лимит, а нужные поисковики остаться нетронутыми.
С кем не путать Site24x7
| Бот / сосед | Кластер | UA | Комментарий |
| 360monitoring | Мониторинг доступности | 360monitoring | легитимный |
| Catchpoint | Мониторинг доступности | catchpoint | легитимный |
| Checkly | Мониторинг доступности | checkly | легитимный |
| EvoUptimeBot | Мониторинг доступности | evouptimebot | легитимный |
| FreshpingBot | Мониторинг доступности | freshpingbot | легитимный |
Стратегия allow/deny для Site24x7
| Ситуация | Действие |
| Проверку настраивала ваша команда | Allow + закрыть /admin /cart /api, сверить IP со списком в документации Site24x7 |
| Мониторинг чужой и пользы бизнесу не приносит | Disallow + запрет в TrafficVeil |
| Мониторинг нужен, но задействован тяжёлый synthetic-сценарий с высокой частотой | Rate-limit на nginx/TrafficVeil |
| Не удалось подтвердить, чей это checker | Deny по умолчанию, разрешать точечно после выяснения источника |
| Подозрение на подделку UA под Site24x7 | Сверить IP с официальным списком в документации, а не доверять только заголовку |
Если это не ваш checker — можно смело ограничивать, на SEO и видимость сайта в поиске это не повлияет. Если проверку настраивали именно вы — правильный шаг не запрет, а внесение подтверждённых IP из документации Site24x7 в allowlist TrafficVeil, чтобы мониторинг продолжал работать без искажений в общей статистике.