← Cloudflare Logs / logs / faq

Ответы 504 с origin status 0 в Logpush

❮ Назад к FAQ

Если вы загружаете данные Cloudflare Logpush в Splunk, Datadog или другую SIEM-систему, вы можете увидеть записи журнала с EdgeResponseStatus=504 и OriginResponseStatus=0 которые нигде не отображаются в панели управления Cloudflare.

В большинстве случаев это внутренние подзапросы Cloudflare, а не реальные ошибки конечных пользователей. Обычно источниками являются Early Hints обращения cache MISS и Workers Cache API cache.match() возвращает MISS. Эти подзапросы никогда не достигают вашего ориджина, поэтому ваш сайт продолжает нормально работать для конечных пользователей.

Cache Analytics и панель управления намеренно отфильтровывают эти подзапросы. Logpush отправляет каждую строку журнала, которую формирует edge-сервер, включая внутренние подзапросы, поэтому одни и те же данные оказываются в двух местах с двумя разными фильтрами по умолчанию. Отфильтруйте подзапросы в вашей SIEM с помощью RequestSource поле.

Типичная запись в вашей SIEM-системе выглядит так:

EdgeResponseStatus: 504
OriginResponseStatus: 0
ClientRequestHost: www.example.com
EdgeStartTimestamp: 2026-04-15T10:23:17Z

Ваше приложение работает в штатном режиме, origin-сервер исправен, и в панели управления для этой зоны не отображаются ответы с кодом 504. При этом в панелях SIEM по-прежнему может отображаться по несколько десятков тысяч таких записей в день.

Из раздела Справочник по набору данных HTTP requests:

OriginResponseStatus=0 сам по себе не является признаком ошибки. Это означает, что Cloudflare не выполнил успешный запрос к исходному серверу для этой строки журнала. Это нормально для попаданий в кэш, ответов Worker, блокировок WAF, редиректов и внутренних подзапросов.

Страница ошибки 502/504 указывает на две задокументированные безобидные причины 504 записи в логах: ответы cache MISS от Early Hints и Workers Cache API cache.match операций, при которых возвращается промах кэша (cache MISS).

Из раздела документация по Early Hints:

Возможен резкий рост 504 ответов с этим RequestSource earlyHintsCache в Cloudflare Logs при включённых Early Hints, что является ожидаемым и безопасным поведением. Запросы от earlyHintsCache являются внутренними подзапросами для кешированных Early Hints и не являются ни запросами конечных пользователей, ни запросами к вашему ориджину.

Статус их ответа указывает лишь на то, есть ли кешированные Early Hints для URI запроса: 200 при попадании в кеш (HIT), 504 при промахе кэша (cache MISS).

Это происходит, когда для зоны включена функция Early Hints и Cloudflare проверяет, есть ли в кэше Link: <...>; rel=preload или rel=preconnect заголовков, которые отправляются браузеру до основного ответа. Cache MISS означает, что в кеше нет Link заголовков для этого URL, поэтому запрос возвращает 504 внутри системы.

Если ваш origin-сервер не отправляет Link заголовков preload или preconnect, каждый запрос Early Hints завершается промахом (MISS), и каждый запрос в зоне создаёт одну из следующих внутренних 504 строк журнала. При большом масштабе это могут быть миллионы записей в день.

Из раздела Документация Workers Cache API:

cache.match генерирует 504 ответ с ошибкой, если запрошенное содержимое отсутствует или устарело. Cache API не предоставляет доступ к этому 504 напрямую в скрипт Worker, а вместо этого возвращает undefined. Тем не менее базовый 504 по-прежнему видно в Cloudflare Logs. Если вы используете Cloudflare Logs, вы можете увидеть эти 504 ответов с этим RequestSource edgeWorkerCacheAPI.

Это происходит, когда Worker в зоне вызывает caches.default.match(request) (или похожим) и содержимого нет в кеше либо истёк срок его действия. API возвращает undefined к Worker, но внутренний 504 по-прежнему появляется в ваших логах.

Панель управления Cloudflare применяет requestSource = "eyeball" фильтр к каждому представлению аналитики: Cache Analytics, HTTP Analytics и Security Analytics. Этот фильтр намеренно исключает внутренние подзапросы.

Logpush представляет собой необработанный поток журналов без такого фильтра. Он передает каждую строку журнала, которую формирует edge-сервер, включая внутренние подзапросы. Одни и те же данные появляются в обоих местах с двумя разными фильтрами по умолчанию: панель управления скрывает эти записи, а ваш SIEM их не скрывает.

Чтобы воспроизвести фильтр панели управления в GraphQL Analytics API, обратитесь к Фильтрация конечных пользователей.

Добавьте RequestSource в output_options.field_names. Изменения полей вступают в силу в течение примерно от 10 до 15 минут согласно Справочник по конфигурации API.

curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/logpush/jobs/$JOB_ID" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "output_options": {
      "field_names": ["...existing fields...", "RequestSource"]
    }
  }'

Как только поле начнёт поступать, повторно проверьте свои 504 / 0 записи:

Добавьте в панели, оповещения и запросы вашей SIEM-системы фильтр, эквивалентный приведённому ниже. Он воспроизводит тот же фильтр, который панель управления Cloudflare применяет в своих аналитических представлениях.

Splunk:

NOT RequestSource IN ("earlyHintsCache", "edgeWorkerCacheAPI")

Datadog:

NOT @RequestSource:("earlyHintsCache" OR "edgeWorkerCacheAPI")

Sumo Logic или общий:

!(RequestSource = "earlyHintsCache" OR RequestSource = "edgeWorkerCacheAPI")

Не каждый 504 с OriginResponseStatus=0 это внутренний подзапрос. Настоящие сбои на стороне origin-сервера дают такое же сочетание полей:

• Тайм-аут origin-сервера : Cloudflare открыл соединение (или попытался это сделать), но не получил ответа. OriginResponseStatus остаётся 0 потому что не был получен статус.
• Cloudflare Tunnel не может подключиться к origin-серверу, cloudflared подключено, но не может связаться с настроенной службой. Дополнительную информацию можно найти в Частые ошибки туннеля.
• Worker fetch() до origin завершается сбоем или истечением времени ожидания : согласно OriginResponseStatus : если в зоне выполняется Worker, значение 0 может быть результатом подзапроса Workers к origin-серверу.

RequestSource отличает их от внутренних подзапросов. Если RequestSource это eyeball или пусто, и периферийная сеть вернула 504, проверьте состояние источника, подключение Tunnel или надёжность работы Worker.

Если Early Hints не приносит вам пользы, например если ваш origin-сервер не отправляет Link заголовков preload или preconnect, можно полностью отключить Early Hints:

1. В панели управления Cloudflare перейдите в Speed > Оптимизация > Оптимизация контента.
2. Включите Early Hints выключить.

Это устраняет earlyHintsCache подзапросов на источнике вместо их фильтрации ниже по цепочке. Чтобы проверить, приносит ли Early Hints пользу вашей зоне, отправьте запрос к GraphQL Analytics API для 103 кодов статуса, отданных клиентам. Если это значение равно нулю, а earlyHintsCache активность высокая, Early Hints включён, но ничего не отдаёт.

В случае Workers Cache API 504 Поведение MISS определяется тем, как cache.match означает промах (miss). Правильным решением будет фильтрация на стороне SIEM.

1. Добавить RequestSource вашего задания Logpush field_names.
2. Подождите примерно 15 минут, пока изменение вступит в силу.
3. Проверьте RequestSource значение в вашем 504 / 0 записи.
4. Исключить earlyHintsCache и edgeWorkerCacheAPI в вашей SIEM.
5. Если все ваши 504 / 0 записи представляют собой earlyHintsCache и вы не отдаёте Link заголовки preload, рассмотрите возможность отключения Early Hints в настройках Speed.
6. Анализируйте только записи, в которых RequestSource это eyeball или пусто как реальные проблемы исходного сервера.

• Набор данных HTTP requests: справочник полей
• Early Hints: Emit Early Hints
• Workers Cache API: ошибки
• Ошибка 502 или 504
• GraphQL Analytics API: фильтрация конечных пользователей
• Настройка Logpush API
• Cloudflare Tunnel: частые ошибки
• Подзапросы Worker: почему поля origin появляются в записях журнала подзапросов Worker