Мониторинг сайтов · 6 мин · обновлено 2026-08-26

Cloudflare не проходит проверку: challenge или реальный сбой

Проверка сайта за Cloudflare может получить страницу challenge вместо ожидаемого ответа. Разбираем, как отличить защитную реакцию от сбоя CDN или origin и настроить проверку без опасных исключений.

Если автоматическая проверка не видит сайт за Cloudflare, это ещё не доказывает недоступность для посетителей. Сначала выясните, какой ответ пришёл проверяющему клиенту: штатная страница, Cloudflare Challenge, ошибка на стороне edge-узла или ошибка origin-сервера. Самый надёжный признак challenge — заголовок cf-mitigated: challenge; дополнительно сверяйте Content-Type, код ответа и небольшой устойчивый фрагмент ожидаемого содержимого.

Главная ошибка — считать любой 403, 503 или HTML от Cloudflare реальным падением. Обратная ошибка не менее опасна: автоматически записывать любой ответ с логотипом Cloudflare в «ложное срабатывание» и пропускать настоящий сбой.

Что означает «не проходит проверку»

У браузера пользователя и мониторинга разные профили. Браузер выполняет JavaScript, хранит cookie, имеет историю переходов и характерный набор заголовков. Проверяющий робот обычно делает короткий HTTP-запрос без пользовательской сессии. WAF, Bot Management, rate limit или правило защиты могут оценить эти запросы по-разному.

Поэтому полезно разделить четыре исхода:

Пришёл ожидаемый ответ приложения. Код, тип контента и контрольная строка совпали — проверка успешна.
Cloudflare выдал challenge. Сеть и edge отвечают, но автоматический клиент не получил целевой ресурс. Для проверки доступности это отдельное состояние, а не OK и не доказанный сбой приложения.
Cloudflare сообщает об ошибке связи с origin. Edge доступен, но запрос не был нормально обслужен источником. Это уже эксплуатационный инцидент, даже если страница ошибки открывается быстро.
Ответ не получен или повреждён. Возможны DNS-, TCP-, TLS-проблемы, тайм-аут либо региональная недоступность. Здесь challenge вообще может быть ни при чём.

Такое разделение сохраняет смысл сигнала: «защита отклонила проверку» требует другой реакции, чем «приложение не отвечает».

Как распознать Cloudflare Challenge

Cloudflare документирует явный признак: для страниц Challenge в ответе присутствует заголовок:

cf-mitigated: challenge

При этом Content-Type challenge-ответа будет text/html независимо от типа запрошенного ресурса. Например, JSON endpoint может неожиданно вернуть HTML. Поэтому проверка только кода 200 недостаточна: клиент способен получить не тот формат, который ожидало приложение.

Снимите ответ без автоматического сокрытия деталей:

curl -sS -D /tmp/site.headers -o /tmp/site.body   --max-time 15 https://example.ru/health

Затем проверьте:

grep -iE '^(HTTP/|cf-mitigated:|content-type:|server:|cf-ray:)' /tmp/site.headers
wc -c /tmp/site.body

cf-ray помогает сопоставлять запрос с логами и точкой Cloudflare, но сам по себе не означает challenge: этот заголовок встречается и в нормальных ответах. Точно так же строка cloudflare в Server лишь показывает участие прокси, а не причину ошибки.

Если cf-mitigated отсутствует, не пытайтесь угадать причину по оформлению HTML. Сохраните код, заголовки и первые безопасные байты тела, затем проверьте события безопасности Cloudflare для того же времени и запроса.

Диагностика за 10–15 минут

1. Зафиксируйте контракт успешного ответа

До настройки исключений определите, что именно считается работоспособностью:

допустимый HTTP-код, обычно 200;
ожидаемый Content-Type;
короткая стабильная строка, например status=ok или идентификатор версии формата;
предельное время ответа;
запрет на cf-mitigated: challenge.

Контрольная строка должна быть постоянной и не содержать секретов, персональных данных или случайного токена.

2. Повторите запрос из двух независимых сетей

Один адрес мониторинга может попасть под правило, rate limit или локальную проблему маршрута. Сравните результаты из другой сети или региона. Не ограничивайтесь браузером из той же офисной сети: он проверяет другой клиентский сценарий.

Интерпретация:

challenge только у автоматической точки — вероятна реакция защиты на профиль клиента;
одинаковая origin-ошибка из нескольких точек — вероятнее реальный инцидент;
проблема только в одном регионе — возможен маршрут, конкретный edge или региональное правило;
браузер и робот получают разные тела с одинаковым 200 — проверяйте содержимое, а не только статус.

3. Сопоставьте запрос с Security Events

Ищите событие по времени, пути, IP точки проверки, действию правила и Ray ID, если он доступен. Важно установить конкретный механизм: managed challenge, block, rate limiting или пользовательское WAF-правило. «Наверное, Cloudflare» — недостаточный диагноз.

4. Отделите edge от origin

Проверка публичного URL отвечает на вопрос «доступен ли пользовательский путь через CDN». Прямой тест origin отвечает на другой вопрос — «жив ли источник». Его выполняют только из доверенной сети и с корректным Host/SNI; открывать origin всему интернету ради диагностики не нужно.

Если публичный URL отдаёт ошибку, а origin здоров, исследуйте правила Cloudflare, DNS и связь edge с origin. Если обе проверки падают, начинайте с приложения, балансировщика, TLS и ресурсов origin.

5. Проверьте воспроизводимость без шторма запросов

Не запускайте десятки повторов подряд: это способно активировать rate limit и исказить картину. Сделайте несколько запросов с разумным интервалом, сохраните время и результат каждого. Для алерта используйте подтверждение повторной проверкой, но не превращайте его в бесконечный retry.

Как настроить проверку безопасно

Лучший вариант — отдельный минимальный URL, например /health/public, который:

доступен через тот же домен и Cloudflare, что и основной сайт;
отвечает быстро и не создаёт тяжёлую нагрузку;
возвращает простой предсказуемый ответ;
не раскрывает версии компонентов, конфигурацию и состояние внутренних зависимостей;
не требует выполнения challenge.

Исключение в WAF делайте узким: конкретный путь плюс подтверждённые адреса проверяющих точек или другой доступный устойчивый признак. Не отключайте защиту для всего домена, всех ботов или широкого диапазона URL. Учтите, что IP точки может измениться: процедура обновления allowlist должна быть частью эксплуатации.

Если исключение сделать нельзя, мониторинг должен классифицировать challenge отдельно. Считать его успехом неправильно: реальный API-клиент без браузера может столкнуться с той же проблемой. Считать его доказанным падением origin тоже неправильно.

Что не стоит делать

Проверять только главную страницу. Она тяжёлая, персонализируется и чаще попадает под защитные правила.
**Принимать любой 2xx за успех.** Challenge или заглушка могут не совпасть с контрактом ресурса.
Отключать WAF ради мониторинга. Это увеличивает поверхность атаки и маскирует неверно выбранную проверку.
**Подделывать браузер одним User-Agent.** Это хрупкая имитация, а не договорённость между защитой и мониторингом.
Добавлять случайный query-параметр к каждому запросу. Так можно обойти кэш, увеличить нагрузку на origin и получить сценарий, отличный от пользовательского.
Считать прямой origin-check заменой публичной проверке. Он не проверяет DNS, TLS и правила на пути через CDN.

Короткое дерево решений

Есть cf-mitigated: challenge? Зафиксируйте событие Cloudflare и проверьте узкое исключение для health URL.
Заголовка нет, но формат ответа неожиданный? Сравните код, Content-Type, тело и события безопасности.
Ошибка повторяется из нескольких сетей? Проверьте публичный путь и origin раздельно.
Origin здоров, публичный путь нет? Исследуйте CDN/DNS/WAF/TLS между edge и источником.
Ошибка только у одной точки? Проверьте регион, маршрут, репутацию IP и локальное правило, не закрывая инцидент без повторного теста.

Challenge — это диагностируемый ответ защиты, а не синоним сбоя. Настройте проверку так, чтобы она различала ожидаемое содержимое, challenge и инфраструктурную ошибку. Добавьте публичный health URL в мониторинг Web‑Puls и задайте проверку кода и контрольной строки — это даст сигнал о пользовательском пути без необходимости ослаблять защиту всего сайта.