← Cloudflare Cache / cache / troubleshooting

Prozkoumejte odpovědi mimo mezipaměť

Pokud je URL adresa, kterou jste očekávali mít uloženou v mezipaměti, pokaždé obsloužena z origin serveru, pak cf-cache-status hlavička odpovědi určuje, jaké rozhodnutí o cache Cloudflare provedl. Načtěte URL, zkontrolujte hlavičku a postupujte podle části, která odpovídá zobrazené hodnotě:

• DYNAMIC : Cloudflare rozhodl, že požadavek není způsobilý pro uložení do mezipaměti ještě předtím, než se do mezipaměti podíval. Více informací naleznete v DYNAMIC: požadavek není způsobilý pro cache.
• BYPASS : Cloudflare byl připraven odpověď uložit do mezipaměti, ale odpověď nebo konfigurace originu tomu zabránily. Více informací naleznete v BYPASS: odpověď origin serveru nelze uložit do mezipaměti.
• MISS u více po sobě jdoucích požadavků od stejného klienta, odpověď lze uložit do mezipaměti, ale opakovaně dochází k cache miss. Více informací najdete v Opakovaný MISS: cachovatelné, ale není v cache.

Pro jakýkoli jiný stav najdete informace v části Ukládání odpovědí do mezipaměti pro úplný seznam.

Nedávná Purge Everything, vymazání podle URL, vymazání podle předpony, vymazání podle tagu, nebo vymazání podle hostname vymaže mezipaměť. Další požadavek v každém datovém centru mezipaměť znovu naplní a vrátí MISS než následující požadavky začnou vracet HIT. Pokud proběhlo nedávno vymazání mezipaměti, počkejte, než se mezipaměť znovu naplní, a teprve poté pokračujte.

Cloudflare rozhodl o tom, že se odpověď „neuloží do mezipaměti“, už v okamžiku požadavku, ještě před nahlédnutím do mezipaměti. Nejčastější příčiny:

• Přípona souboru není v výchozí cachované přípony souborů seznam , například .html nebo odpovědi JSON API, a žádné pravidlo pro ni neumožňuje uložení do mezipaměti. Přidejte Cache Rule hodnotou Způsobilé pro cache nastaveno na Ano.
• Pravidlo instruuje Cloudflare, aby obešel mezipaměť. Zkontrolujte, zda pravidlo Cache Rule s Bypass cache nastavení nebo starší Cache Level: Bypass Configuration Rule nebo Page Rule, odpovídá adrese URL. Použijte Trasování pravidel potvrdit, která pravidla se uplatňují.
• Metoda požadavku není GET nebo HEAD. Cloudflare ukládá do mezipaměti pouze tyto dvě metody.
• Development Mode je povolena pro zónu. Development Mode pozastaví mezipaměť na tři hodiny a vrací DYNAMIC pro každou odpověď.

Jakmile je požadavek způsobilý, následné odpovědi odrážejí rozhodnutí přijaté v době odpovědi (HIT, MISS, BYPASS, a tak dále).

Požadavek byl způsobilý k cachování, ale odpověď origin serveru nebo konfigurace zabránily Cloudflare v jeho uložení. Mezi časté příčiny patří:

• Odpověď překračuje limit velikosti pro cachovatelný obsah pro váš plán. Rozdělte objekt na menší prostředky nebo přejděte na plán s vyšším limitem. R2 je alternativou k úložišti na origin serveru, nezvyšuje tak limit velikosti položek, které lze uložit do mezipaměti CDN.

• Origin vrátil no-store nebo samotné private v Cloudflare-CDN-Cache-Control nebo CDN-Cache-Control hlavička. Cloudflare vyhodnocuje tyto hlavičky před Cache-Control, v pořadí priority Cloudflare-CDN-Cache-Control > CDN-Cache-Control > Cache-Control. Origin server, který vrací Cache-Control: public, max-age=3600 společně s CDN-Cache-Control: no-store vytváří BYPASS. Cloudflare nepředává Cloudflare-CDN-Cache-Control klientovi, takže není v odpovědi vidět. Pokud vidíte BYPASS bez CDN-Cache-Control hlavičky zkontrolujte, co origin server skutečně odeslal, případně nechte origin server hlavičku vynechat a test zopakujte. Hlavička Cache Rule s Edge Cache TTL nastavení, které ignoruje cache-control originu, přepíše obě direktivy. Více informací najdete v CDN-Cache-Control pro pravidla priority.

• no-cache, max-age=0, nebo s-maxage=0 v Cloudflare-CDN-Cache-Control nebo CDN-Cache-Control nevytvářejí BYPASS. Vytvářejí MISS u prvního požadavku, pak REVALIDATED nebo EXPIRED u následujících požadavků.

• Origin vrátil Cache-Control: no-store nebo samotné private. Tyto direktivy blokují ukládání do mezipaměti buď Origin Cache Control režim ve výchozím nastavení. Existují dvě výjimky: Cache-Control: private="<header>" s uvedenými názvy hlaviček zůstává ukládáno do mezipaměti, Cloudflare pouze odstraní uvedené hlavičky. A Cache Rule s hodnotou Edge TTL, která ignoruje cache-control originu (Edge TTL → Ignorovat hlavičku cache-control a použít toto TTL nebo Status code TTL) přepíše obě direktivy, takže odpověď s no-store a navíc po dobu daného nastavení Edge TTL je objekt cachován.

• Origin vrátil Cache-Control: no-cache, max-age=0, nebo s-maxage=0, a Origin Cache Control je vypnuto (výchozí nastavení u plánů Enterprise). Pokud je povoleno Origin Cache Control (výchozí nastavení u plánů Free, Pro a Business), tyto direktivy místo toho způsobí, že Cloudflare odpověď uloží do mezipaměti a znovu ověří, což vede k REVALIDATED nebo EXPIRED. Viz Seznamte se s no-store a no-cache direktivy a Podmínky tabulka.

• Origin vrátil Set-Cookie hlavička. Cloudflare ve výchozím nastavení neukládá do mezipaměti odpovědi, které obsahují Set-Cookie. Chcete-li odpověď uložit do mezipaměti, použijte jednu z následujících možností:

  • Nastavit explicitní Edge TTL na Cache Rule pomocí Edge TTL → Ignorovat hlavičku cache-control a použít toto TTL nebo Status code TTL. Cloudflare ignoruje direktivy origin serveru a odstraní Set-Cookie, a odpověď uloží do cache.
  • Nechat origin server vrátit Cache-Control: private="Set-Cookie" nebo no-cache="Set-Cookie". Cloudflare zahodí pojmenovanou hlavičku a zbytek uloží do mezipaměti.
  • Odebrat Set-Cookie ještě před rozhodnutím o mezipaměti, a to pomocí Response Header Modification Transform Rule.
  • V plánech Enterprise s Origin Cache Control vypnuté, Cloudflare odstraní Set-Cookie a uloží odpověď do mezipaměti na výchozí úrovni mezipaměti. Cache Level: Cache Everything Page Rule nebo Cache Rule s Způsobilé pro cache nastaveno na Ano (bez explicitně nastavené hodnoty Edge TTL) toto přepíše a vrátí BYPASS.

  Viz Interakce Set-Cookie hlavička odpovědi s Cache pro úplnou tabulku.

• Origin vrátil Vary: *. Tato hodnota mezipaměť vždy obchází bez ohledu na jiná nastavení.

• Požadavek obsahoval Authorization hlavička a Origin Cache Control je zapnuto (výchozí nastavení u plánů Free, Pro a Business). V tomto režimu lze odpověď uložit do mezipaměti pouze v případě, že Cache-Control také zahrnuje public, s-maxage, nebo must-revalidate. Na plánech Enterprise s vypnutou funkcí Origin Cache Control Authorization sama o sobě neukládání do mezipaměti nebrání.

Viz BYPASS pro referenční definici tohoto stavu.

MISS u prvního požadavku v každém datacentru je očekávaný, protože tento požadavek naplňuje mezipaměť. Pokud stejná URL adresa i nadále vrací MISS napříč po sobě jdoucími požadavky, děje se jedna z následujících věcí.

Cloudflare ve výchozím nastavení sestavuje cache key ze schématu, hostitele, cesty a řetězce dotazu na originu. Po nakonfigurování mohou přispívat také cookies, hlavičky a typ zařízení. Schéma v cache key je schéma, které Cloudflare používá k připojení k originu, nikoli schéma použité klientem: zóna s jediným schématem originu obsluhuje požadavky klientů HTTP i HTTPS ze stejné položky mezipaměti.

Pokud každý skutečný požadavek klienta vytvoří jiný klíč, mezipaměť nikdy nezaznamená opakování a každý požadavek je MISS. Časté případy:

• Parametry dotazu, které se mění při každém požadavku , jako jsou ID relace, časová razítka nebo marketingové značky, například utm_*. Ve výchozím nastavení je každý jedinečný řetězec dotazu samostatnou položkou mezipaměti. Nakonfigurujte Cache Rules nebo Nastavení Cache Key vyloučit nebo ignorovat parametry, jejichž hodnota se u každého požadavku mění. Řazení pouze sjednocuje pořadí parametrů: použijte ho, když se požadavky liší pouze pořadím parametrů, ne když se liší hodnoty.
• vlastní cache key obsahuje cookie nebo hlavičku s hodnotou, která se liší podle uživatele. Vytvoření vlastních cache keys sekce upozorňuje, že vlastní klíče "may reduce your cache hit rate and result in cache sharding", jedná se o stejné chování.
• Cache podle typu zařízení klasifikuje klienty jinak, než se očekávalo, zejména u botů nebo klientů s neobvyklými User-Agent hodnoty.
• Vary v Cache Rules je nakonfigurováno pro hlavičku, origin ji uvede ve své Vary hlavička odpovědi, a akce je normalize nebo passthrough. Každá varianta odpovědi se uloží pod samostatným klíčem. Pokud má hlavička vysokou kardinalitu, například nenormalizovaná Accept-Language hodnotu nebo hlavičku specifickou pro uživatele: praktická míra zásahů do mezipaměti klesá. Hodnota bypass akce zcela zabraňuje ukládání do mezipaměti.

Dva identické požadavky vytvoří stejný klíč mezipaměti, a proto nemohou odhalit odchylku. K diagnostice použijte Trasování pravidel zobrazit uplatněnou konfiguraci klíče mezipaměti a akci Vary pro danou URL adresu, a porovnat ji s vlastnostmi požadavku (řetězec dotazu, cookies, hlavičky, typ zařízení), které se liší mezi skutečnými požadavky klientů.

Prostředky s malým provozem mohou být z cache vyřazeny ještě předtím, než dorazí další požadavek. Pokud dva po sobě jdoucí požadavky na stejnou adresu URL ze stejného datového centra vrátí MISS, zapněte Tiered Cache nebo Cache Reserve uchovat long-tail obsah déle.

Pokud vaše požadavky míří do různých datacenter Cloudflare, každé z nich generuje vlastní stav pro první požadavek MISS. Porovnejte kód datového centra, tedy poslední tři znaky cf-ray hlavičky, abyste potvrdili, že obě odpovědi pocházejí ze stejného datového centra. Různé sítě klientů mohou přesto směřovat do stejného datového centra, takže změna sítě nezaručuje jinou lokalitu.

Po úpravě konfigurace odešlete na danou URL adresu dva požadavky ze stejného klienta a ověřte, že výsledek odpovídá vaší konfiguraci:

• Platné, kladné Edge TTL: cf-cache-status: HIT a Age hlavička, jejíž hodnota se s dalšími požadavky zvyšuje. Age chybí u prvního požadavku, který naplní mezipaměť místního datového centra z vyšší úrovně přes Tiered Cache , HIT odpovídá horní vrstvě, ale místní datacentrum ho z cache ještě neobsloužilo. Následné požadavky obsahují Age, a u Tiered Cache může být hodnota už vysoká, protože odráží stáří objektu v cache platné pro celou síť Cloudflare.
• Origin vrací Cache-Control: no-cache hodnotou Origin Cache Control zapnuté: cf-cache-status: REVALIDATED když origin potvrdí, že uložená kopie se nezměnila, nebo EXPIRED když origin vrátí nový obsah. Obě hodnoty znamenají, že odpověď je uložena v mezipaměti. must-revalidate sama o sobě nevynucuje revalidaci při každém požadavku, pouze zabraňuje podávání zastaralého obsahu po vypršení TTL platnosti.

Pokud je odpověď stále MISS nebo BYPASS po těchto kontrolách zachyťte dvě úplné odpovědi (hlavičky požadavku a odpovědi, včetně cf-ray hodnoty) a otevřete tiket podpory. Hodnota cf-ray hodnoty jsou nutné pro trasování požadavku přes síť Cloudflare.

• Ukládání odpovědí do mezipaměti , odkaz pro každou cf-cache-status hodnota.
• Výchozí chování cache , když Cloudflare ve výchozím nastavení úspěšně ukládá do mezipaměti.
• Cache Rules : slouží k nastavení Edge TTL, způsobilosti k ukládání do mezipaměti a klíče mezipaměti.
• Cache Analytics : měří poměr zásahů do mezipaměti a identifikuje málo výkonné adresy URL.