Артём Савельев 
Мониторинг, который блокирует ваш собственный WAF
Подключили мониторинг — и он начал слать «сайт недоступен» на сайт, который прекрасно открывается у живых посетителей. Причина иногда не в мониторинге и не в сайте, а в собственной защите: WAF или антибот-система приняли автоматические проверки за подозрительный трафик и заблокировали их.
Почему WAF видит в мониторинге угрозу
С точки зрения защитной системы регулярные автоматические запросы с одних и тех же IP-адресов, с нетипичным User-Agent, без характерного для браузера поведения — это ровно то, на что настроены правила антибот-защиты. WAF не знает контекста «это наш собственный мониторинг» — он видит паттерн, похожий на сканер или бота, и реагирует по инструкции: капча, блокировка, ограничение частоты запросов.
Особенно часто это проявляется у сервисов вроде Cloudflare (в первую очередь в режиме усиленной защиты), Qrator или Ddos-Guard — они по умолчанию агрессивнее относятся к нераспознанному автоматическому трафику, чем базовые настройки хостинга.
Сайт числится недоступным в мониторинге, но живые посетители открывают его без проблем, и жалоб от реальных пользователей нет. Это почти всегда означает, что заблокирован не сайт, а конкретно источник проверок — стоит смотреть в эту сторону раньше, чем разбирать логи сервера в поисках несуществующей аварии.
Как решается на стороне защиты
Добавить IP-адреса мониторинга в белый список. Большинство WAF и CDN позволяют внести конкретные IP или диапазоны в исключения — тогда правила защиты просто не применяются к запросам с этих адресов.
Разрешить конкретный User-Agent, а не весь трафик целиком. Более узкое правило — не «отключить защиту для этого IP полностью», а «не блокировать запросы с определённой строкой User-Agent на определённые пути» — снижает риск случайно открыть более широкую дыру в защите, чем требовалось.
Держать список адресов монитора в whitelist вручную неудобно, если он время от времени меняется, — поэтому многие сервисы мониторинга публикуют актуальный список своих IP через API, чтобы его можно было подгружать автоматически, а не сверять руками при каждом обновлении.
Разные проверки — разные User-Agent
Полезная деталь: если у разных типов проверок (доступность, SEO, фиды) разные строки User-Agent по умолчанию, WAF можно настроить точечно — разрешить, например, только проверки доступности, а к остальным применять более строгие правила. Это удобнее, чем ставить один общий флаг «доверять всему трафику с этого сервиса».
Актуальный список IP-адресов Пруфена доступен через API в форматах TXT и JSON — можно подгрузить автоматически в CI/CD или напрямую в настройки WAF. У разных типов проверок — свой User-Agent по умолчанию, что позволяет настраивать исключения для WAF/CDN точечно, а не разрешать весь автоматический трафик разом.
Частые вопросы
Это касается только крупных сайтов с серьёзной защитой? Чаще всего да — базовые настройки хостинга редко блокируют автоматический трафик так агрессивно. Проблема типична для сайтов за Cloudflare, Qrator или похожими системами, особенно в усиленных режимах защиты.
Не снижает ли добавление IP в whitelist общую безопасность? Точечное исключение по конкретному IP и, желательно, по конкретному пути и User-Agent — это узкая, контролируемая брешь, а не отключение защиты целиком. Риск минимален по сравнению с общей выгодой от корректно работающего мониторинга.
Список IP мониторинга может измениться? Да, поэтому лучше подгружать его автоматически через API, а не вписывать вручную один раз — статичный список рискует устареть при следующем изменении инфраструктуры сервиса мониторинга.
Как быстро понять, что дело именно в WAF, а не в реальном сбое? Проверить логи защиты на предмет заблокированных запросов с IP мониторинга в момент «падения» — если там есть явная блокировка, причина найдена без долгих догадок.