INTEGRITY Dokumentace

← Cloudflare Logs / logs / faq

Odpovědi 504 s origin status 0 v Logpush

❮ Zpět na FAQ

Proč se mi zobrazují odpovědi 504 s OriginResponseStatus=0 v Logpush, které se nezobrazují v dashboardu?

Pokud importujete Cloudflare Logpush do Splunk, Datadog nebo jiného SIEM, můžete v protokolech vidět záznamy s EdgeResponseStatus=504 a OriginResponseStatus=0 které se v Cloudflare dashboardu vůbec nezobrazují.

Ve většině případů jde o interní dílčí požadavky Cloudflare, nikoli o skutečné chyby koncových uživatelů. Nejčastějšími zdroji jsou Early Hints vyhledávání cache MISS a Workers Cache API cache.match() se vrátí stav MISS. Tyto podpožadavky se nikdy nedostanou k vašemu originu, takže váš web pro koncové uživatele funguje i nadále normálně.

Cache Analytics a dashboard tyto podpožadavky záměrně filtrují. Logpush odesílá každý řádek protokolu vytvořený edge serverem, včetně interních podpožadavků, takže stejná data se objevují na dvou místech se dvěma různými výchozími filtry. Podpožadavky odfiltrujte ve svém SIEM pomocí RequestSource .

Jak vypadá odpovídající položka protokolu

Typický záznam ve vašem SIEM vypadá takto:

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

Vaše aplikace funguje normálně, původní server je v pořádku a v řídicím panelu pro tuto zónu se nezobrazují žádné odpovědi 504. Přesto se ve vašich panelech SIEM může denně zobrazovat desítky tisíc těchto záznamů.

Co znamenají jednotlivá pole

Z Referenční přehled datové sady HTTP requests:

Pole Definice
EdgeResponseStatus Stavový kód HTTP vrácený klientovi službou Cloudflare.
OriginResponseStatus Stav vrácený upstream serverem. Hodnota 0 znamená, že od origin serveru nebyla přijata žádná odpověď a odpověď byla doručena z edge sítě Cloudflare. Pokud na zóně běží Worker, 0 může být také důsledkem dílčího požadavku Workers na origin server.

OriginResponseStatus=0 samo o sobě není signálem chyby. Znamená to, že Cloudflare pro daný řádek protokolu neprovedl úspěšné načtení z origin serveru. To je běžné u zásahů do mezipaměti, odpovědí Workeru, blokování WAF, přesměrování a interních dílčích požadavků.

Proč k této kombinaci dochází

Stránka chyby 502/504 uvádí dvě zdokumentované neškodné příčiny 504 položky v logách: odpovědi cache MISS z Early Hints a Workers Cache API cache.match operace, které vracejí cache MISS.

Příčina 1: Early Hints cache MISS

Z dokumentace k Early Hints:

Můžete zaznamenat nárůst počtu 504 odpovědi s RequestSource z earlyHintsCache ve službě Cloudflare Logs, když je zapnutá funkce Early Hints, což je očekávané a neškodné chování. Požadavky od earlyHintsCache jsou interní podpožadavky pro cachované Early Hints a nejedná se ani o požadavky koncových uživatelů, ani nesměřují k vašemu originu.

Jejich stav odpovědi pouze udává, zda pro dané URI požadavku existují cachované Early Hints: 200 při cache HIT, 504 při cache MISS.

K tomu dochází, když je pro zónu povoleno Early Hints a Cloudflare zjišťuje, zda existují nějaké uložené Link: <...>; rel=preload nebo rel=preconnect hlaviček, které se mají odeslat prohlížeči před hlavní odpovědí. Cache MISS znamená, že v cache nejsou žádné uložené Link hlaviček pro danou URL adresu, takže vyhledávání vrátí 504 interně.

Pokud váš origin server nevysílá Link hlaviček preload nebo preconnect, každé vyhledávání Early Hints je MISS a každý požadavek na zóně vytvoří jeden z těchto interních 504 řádků protokolu. Při velkém objemu to může být miliony záznamů denně.

Příčina 2: Workers Cache API cache.match MISS

Z Dokumentace Workers Cache API:

cache.match generuje 504 chybovou odpověď, pokud požadovaný obsah chybí nebo mu vypršela platnost. Cache API toto 504 přímo do Worker skriptu, ale místo toho vrací undefined. Přesto podkladové 504 je stále viditelné ve službě Cloudflare Logs. Pokud používáte Cloudflare Logs, můžete tyto 504 odpovědi s RequestSource z edgeWorkerCacheAPI.

K tomu dochází, když Worker v zóně volá caches.default.match(request) (nebo podobným) a obsah není v mezipaměti nebo jeho platnost vypršela. API vrátí undefined do Workeru, ale interní 504 se stále zobrazuje ve vašich protokolech.

Proč se tyto záznamy nezobrazují v dashboardu

Cloudflare dashboard uplatňuje requestSource = "eyeball" filtr na každé zobrazení analytiky: Cache Analytics, HTTP Analytics a Security Analytics. Tento filtr záměrně vynechává interní dílčí požadavky.

Logpush je nezpracovaný proud protokolů bez takového filtru. Odesílá každý řádek protokolu, který edge vygeneruje, včetně interních dílčích požadavků. Stejná data se tak objevují na obou místech, ale s odlišnými výchozími filtry: dashboard tyto záznamy skrývá, zatímco váš SIEM nikoli.

Chcete-li replikovat filtr dashboardu v GraphQL Analytics API, přečtěte si Filtrování koncových uživatelů.

Potvrďte, co vidíte

Přidejte RequestSource pole do vaší úlohy Logpush, konkrétně do jejího output_options.field_names. Změny polí se projeví přibližně za 10 až 15 minut podle Referenční dokumentace ke konfiguraci 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"]
    }
  }'

Jakmile pole začne procházet, znovu zkontrolujte své 504 / 0 položky:

RequestSource hodnota Význam Akce
earlyHintsCache Interní podpožadavek Early Hints (neškodný) Vyřadit
edgeWorkerCacheAPI Workers Cache API MISS (neškodné) Vyřadit
eyeball nebo prázdné Skutečný požadavek koncového uživatele Prošetřete jako skutečný 504

Filtrujte ve vašem SIEM

Do dashboardů, výstrah a dotazů ve vašem SIEM přidejte filtr odpovídající tomuto. Tím zopakujete filtr, který Cloudflare dashboard používá pro svá analytická zobrazení.

Splunk:

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

Datadog:

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

Sumo Logic nebo obecný:

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

Kdy je 504 s origin status 0 skutečným problémem

Ne každý 504 hodnotou OriginResponseStatus=0 je interní podpožadavek. Skutečné chyby na straně origin serveru vytvářejí stejnou kombinaci polí:

RequestSource tyto požadavky odlišuje od interních dílčích požadavků. Pokud RequestSource je eyeball nebo prázdné a edge vrátil 504, prověřte stav origin serveru, konektivitu Tunnelu nebo spolehlivost Workeru.

Omezte šum přímo u zdroje

Pokud z Early Hints nemáte žádný přínos, například proto, že váš origin server nevysílá Link hlaviček preload nebo preconnect: Early Hints můžete zcela vypnout:

  1. V Cloudflare dashboardu přejděte na Rychlost > Optimalizace > Optimalizace obsahu.
  2. Zapněte Early Hints vypnuto.

Tím se odstraní earlyHintsCache podřízených požadavků už u zdroje, místo aby se filtrovaly až po cestě. Chcete-li zjistit, zda Early Hints pro vaši zónu k něčemu přispívá, zadejte dotaz do GraphQL Analytics API na 103 stavových kódů odeslaných klientům. Pokud je tento počet nulový, zatímco earlyHintsCache aktivita je vysoká, Early Hints je zapnuto, ale nic neposkytuje.

V případě Workers Cache API je 504 Chování MISS je vlastní tomu, jak cache.match signalizuje miss. Správnou opravou je filtrování ve vašem SIEM.

Souhrn

  1. Přidejte RequestSource k vaší úloze Logpush field_names.
  2. Počkejte přibližně 15 minut, než se změna projeví.
  3. Zkontrolujte RequestSource hodnotu na 504 / 0 položky.
  4. Vyřadit earlyHintsCache a edgeWorkerCacheAPI ve vašem SIEM.
  5. Pokud všechny vaše 504 / 0 položky jsou earlyHintsCache a neposkytujete Link hlaviček preload zvažte vypnutí Early Hints v nastavení Speed.
  6. Zkoumejte pouze záznamy, kde RequestSource je eyeball nebo prázdné jako skutečné problémy s origin serverem.