Nagłówki Cloudflare: co oznaczają cf-cache-status, cf-ray i inne?

Twoja witryna WordPress działa za Cloudflare, a ty chcesz wiedzieć, czy CDN w ogóle cokolwiek daje. W odpowiedziach twojego serwera nagle pojawiają się linijki takie jak cf-cache-status: DYNAMIC albo cf-ray: 8f2a1c3d4e5f6a7b-FRA. Te nagłówki są czymś w rodzaju ulotki dołączonej do Cloudflare: pokazują, czy plik przyszedł z cache, które centrum danych odpowiedziało i czy po drodze wkroczyła jakaś reguła bezpieczeństwa. Z tego artykułu dowiesz się, co oznaczają poszczególne wartości i jakie wnioski możesz z nich wyciągnąć dla swojej witryny.

Czym są nagłówki Cloudflare i jak je odczytać?

Cloudflare działa jako proxy między twoimi odwiedzającymi a twoim serwerem. Każde żądanie przechodzi przez sieć Cloudflare, a po drodze dochodzą kolejne nagłówki. Część z nich widzi przeglądarka odwiedzających, inne trafiają tylko do twojego serwera. Jak taka sieć działa od podstaw, wyjaśnia nasz artykuł Czym jest CDN?.

Nagłówki najszybciej zobaczysz w narzędziach dla deweloperów w swojej przeglądarce. Otwórz zakładkę „Sieć” (w angielskiej wersji „Network”), odśwież stronę i kliknij pierwszy wiersz. Jeszcze szybciej pójdzie w terminalu:

curl -sI https://example.com/

Odpowiedź wygląda wtedy mniej więcej tak:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=0
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 8f2a1c3d4e5f6a7b-FRA

Jeśli w odpowiedzi nie ma ani jednej linijki z cf-, żądanie w ogóle nie przechodzi przez Cloudflare. Zwykle rekord DNS jest wtedy ustawiony na „DNS only” (szara chmurka) zamiast na „Proxied” (pomarańczowa chmurka).

Co oznacza cf-cache-status? Przegląd wszystkich wartości

Nagłówek cf-cache-status jest najważniejszy ze wszystkich. Mówi ci, jak Cloudflare potraktował właśnie tę odpowiedź. Oficjalna dokumentacja wymienia dziewięć wartości:

• HIT: Plik był w cache i przyszedł prosto z Cloudflare. Twój serwer nawet tego nie zauważył. To wartość, którą chcesz widzieć.
• MISS: Plik może trafić do cache, ale w tym centrum danych jeszcze go nie było. Cloudflare pobrał go z twojego serwera. Przy następnym wywołaniu powinno tam być HIT.
• EXPIRED: Plik był w cache, ale stracił ważność. Cloudflare pobrał świeżą wersję z twojego serwera.
• REVALIDATED: Kopia w cache straciła ważność. Cloudflare zapytał twój serwer, czy coś się zmieniło, i odpowiedź brzmiała: nie. Plik przyszedł więc z cache, ale odwiedzający musiał poczekać na to dodatkowe zapytanie.
• UPDATING: Kopia straciła ważność, a mimo to została od razu dostarczona, podczas gdy Cloudflare odświeża ją w tle. Dzieje się tak, gdy twój serwer wysyła stale-while-revalidate.
• STALE: Cloudflare dostarczył nieaktualną kopię, ponieważ twój serwer był nieosiągalny. To sygnał ostrzegawczy, który warto potraktować poważnie.
• BYPASS: Plik w zasadzie nadawał się do cache, ale odpowiedź twojego serwera na to nie pozwoliła, na przykład z powodu cookie.
• DYNAMIC: Cloudflare w ogóle nie zajrzał do cache, ponieważ zgodnie z obowiązującymi regułami ta treść do niego nie trafia.
• NONE/UNKNOWN: Cloudflare sam wygenerował odpowiedź, na przykład przy przekierowaniu na HTTPS, przy blokadzie przez firewall albo gdy odpowiedział Worker.

Warto wiedzieć: od 26 maja 2026 roku Cloudflare wyraźniej rozdziela dwie z tych wartości. Wcześniej niektóre odpowiedzi, których nie dało się zapisać w cache, dostawały MISS przy każdym wywołaniu. Od tej zmiany zawsze widnieje tam BYPASS. MISS oznacza teraz tylko tyle: plik może trafić do cache, ale akurat go tam nie ma. Wiele starszych poradników w sieci wciąż opisuje dawne zachowanie.

Dlaczego twoja witryna WordPress pokazuje cf-cache-status: DYNAMIC?

To najczęstsze pytanie w tym temacie, a odpowiedź uspokaja: przy zwykłej stronie WordPress DYNAMIC to stan normalny. W ustawieniach domyślnych Cloudflare nie zapisuje w cache ani HTML, ani JSON. Decyduje rozszerzenie pliku, a nie jego zawartość. Obrazy, CSS, JavaScript, czcionki i pliki PDF trafiają do cache, kod HTML twoich stron już nie.

Ma to dobry powód. WordPress generuje strony dynamicznie, a Cloudflare nie może wiedzieć, czy w HTML znajduje się akurat koszyk, pasek administracyjny albo osobiste powitanie. Gdyby zapisywał takie strony w cache bez pytania, w najgorszym razie jeden odwiedzający zobaczyłby koszyk innego.

Twoje obrazy i skrypty powinny za to zgłaszać HIT. Dlatego nie sprawdzaj tylko strony głównej, ale też jakiś plik CSS albo obrazek.

Jeśli chcesz, żeby Cloudflare dostarczał także HTML, masz dwie drogi:

• Cache Rule: W panelu Cloudflare tworzysz regułę, która oznacza HTML jako „Eligible for cache”. Wtedy musisz samodzielnie zadbać o to, żeby zalogowani użytkownicy, panel administracyjny, koszyk i strona zamówienia były z tego wyłączone.
• APO dla WordPressa: Automatic Platform Optimization zajmuje się tymi wyjątkami za ciebie i czyści cache, gdy tylko zmienisz wpis. Więcej o tym niżej.

Jeśli DYNAMIC widać także przy obrazach albo CSS, przyczyną jest zwykle reguła z „Bypass cache” albo Development Mode. Ten tryb wyłącza cache całkowicie na trzy godziny i łatwo o nim zapomnieć.

cf-cache-status BYPASS albo ciągle MISS: co jest przyczyną?

Przy BYPASS Cloudflare chciał zapisać plik w cache, ale odpowiedź twojego serwera na to nie pozwoliła. Poradnik rozwiązywania problemów wymienia przede wszystkim te przyczyny:

• Odpowiedź zawiera nagłówek Set-Cookie. W WordPressie to klasyka: sklep, wtyczka do obsługi wielu języków albo wtyczka do śledzenia ustawia cookie przy każdym wywołaniu i nic już nie trafia do cache.
• Twój serwer wysyła Cache-Control: no-store albo private.
• Odpowiedź zawiera Vary: *.
• Plik jest większy niż limit w twoim planie (512 MB w planach Free, Pro i Business).

Jeśli przy każdym wywołaniu wciąż widać MISS, plik wprawdzie nadaje się do cache, ale Cloudflare nigdy go tam ponownie nie znajduje. Często stoją za tym zmienne parametry w adresie, na przykład utm_source albo identyfikator sesji, bo każdy wariant liczy się jako osobny plik. Na witrynach z niewielkim ruchem rzadko pobierane pliki szybciej też wypadają z cache. Do tego każde centrum danych ma własny cache: jeśli dwa żądania trafią do różnych lokalizacji, zobaczysz dwa razy MISS.

Dobrym pomocnikiem jest nagłówek Age. Podaje w sekundach, jak długo kopia leży już w cache. Jeśli pobierzesz plik dwa razy z rzędu i zobaczysz HIT z rosnącą wartością Age, wszystko działa.

Co mówi nagłówek cf-ray?

Każde żądanie, które przechodzi przez Cloudflare, dostaje własny identyfikator, czyli Ray ID. Znajduje się on w nagłówku cf-ray i składa się z dwóch części: ciągu znaków i trzyliterowego skrótu. Skrót wskazuje centrum danych, które odpowiedziało. FRA oznacza Frankfurt, AMS Amsterdam, a CDG Paryż.

Na co dzień Ray ID przydaje się w trzech sytuacjach. Gdy Cloudflare pokazuje odwiedzającemu stronę błędu, Ray ID widnieje na dole tej strony i dzięki niemu odnajdziesz dokładnie to żądanie w logach albo w Security Events. Po drugie, skrót pokazuje ci, czy twoi odwiedzający naprawdę trafiają do pobliskiej lokalizacji. Po trzecie, wyjaśnia on niejedno zagadkowe MISS, gdy dwa żądania dotarły do różnych centrów danych.

Ten sam Ray ID Cloudflare wysyła zresztą także do twojego serwera. Jeśli zapiszesz go tam w logu, prześledzisz żądanie od przeglądarki aż do PHP.

cf-apo-via i cf-edge-cache: czy APO dla WordPressa działa?

Jeśli korzystasz z Automatic Platform Optimization, dochodzą dwa kolejne nagłówki. Według Cloudflare działającą konfigurację rozpoznasz po trzech linijkach:

• cf-cache-status: HIT pokazuje, że HTML przyszedł z cache.
• cf-apo-via: tcache pokazuje, że żądanie zostało obsłużone przez APO.
• cf-edge-cache: cache,platform=wordpress potwierdza, że wtyczka Cloudflare jest zainstalowana i aktywna w WordPressie.

Jeśli brakuje cf-edge-cache, wtyczka jest zwykle wyłączona albo nie jest połączona z twoim kontem. Jeśli cf-apo-via ma inną wartość niż tcache, APO nie dostarczyło strony z cache, na przykład dlatego, że przeglądasz ją po zalogowaniu. Dlatego zawsze testuj w oknie prywatnym.

Co oznacza cf-mitigated: challenge?

Ten nagłówek pojawia się tylko wtedy, gdy Cloudflare zamiast twojej strony dostarcza stronę weryfikacyjną, czyli znany komunikat, że odwiedzający jest przez chwilę sprawdzany. challenge to jedyna prawidłowa wartość.

Dla ludzi to zwykle tylko krótkie opóźnienie. Dla wszystkiego, co automatycznie łączy się z twoją witryną, to prawdziwa przeszkoda. Strona weryfikacyjna to zawsze HTML, nawet jeśli żądanie dotyczyło JSON. Jeśli twój własny JavaScript wywołuje REST API i nagle dostaje w odpowiedzi stronę weryfikacyjną, kończy się to błędem, który bez tego nagłówka trudno byłoby zrozumieć. To samo dotyczy usług monitoringu, operatorów płatności korzystających z webhooków i narzędzi analitycznych. Jeśli widzisz cf-mitigated: challenge przy żądaniach, które powinny przechodzić, zajrzyj do Security Events w panelu Cloudflare. Tam znajdziesz regułę, która zadziałała.

Które nagłówki Cloudflare docierają do twojego serwera?

Nie wszystkie nagłówki są przeznaczone dla przeglądarki. Niektóre Cloudflare dodaje do żądania, zanim dotrze ono do twojego serwera. Pełna lista jest długa, ale dla WordPressa najważniejsze są te:

• CF-Connecting-IP: prawdziwy adres IP odwiedzającego. Bez tego nagłówka twój serwer widzi tylko adresy Cloudflare.
• X-Forwarded-For: łańcuch wszystkich serwerów proxy, przez które przeszło żądanie. Cloudflare zaleca, by adres odwiedzającego odczytywać raczej z CF-Connecting-IP.
• X-Forwarded-Proto i CF-Visitor: pokazują, czy odwiedzający połączył się przez HTTP, czy przez HTTPS.
• CF-IPCountry: kraj odwiedzającego w postaci dwuliterowego kodu. XX oznacza kraj nieznany, T1 sieć Tor.
• CDN-Loop: chroni przed sytuacją, w której żądanie bez końca krąży w kółko po sieci Cloudflare.

Prawdziwy adres IP to coś więcej niż szczegół. Wtyczki bezpieczeństwa blokują atakujących po adresie IP, WordPress zapisuje go przy komentarzach, a twój dostawca hostingu analizuje go w logach. Jeśli dociera tam tylko adres Cloudflare, twoja wtyczka może w najgorszym razie zablokować naraz wszystkich odwiedzających. Większość dostawców hostingu i wtyczek bezpieczeństwa da się do tego odpowiednio skonfigurować. Ważne przy tym: ufaj nagłówkowi tylko wtedy, gdy żądanie naprawdę pochodzi z adresu należącego do sieci Cloudflare. W przeciwnym razie każdy może wpisać do nagłówka dowolny adres IP.

Z tym wiąże się też dobrze znane źródło błędów. Przy ustawieniu SSL „Flexible” Cloudflare komunikuje się z twoim serwerem bez szyfrowania. WordPress myśli wtedy, że odwiedzający połączył się przez HTTP, przekierowuje na HTTPS i powstaje nieskończona pętla. Właściwym rozwiązaniem jest certyfikat na serwerze i ustawienie „Full (strict)”.

Jak za pomocą Cache-Control sterować tym, co Cloudflare zapisuje w cache?

O tym, jak długo Cloudflare przechowuje plik, decyduje przede wszystkim twój serwer. Służą do tego trzy nagłówki, które Cloudflare sprawdza w tej kolejności:

1. Cloudflare-CDN-Cache-Control dotyczy tylko Cloudflare i nie jest przekazywany do przeglądarki.
2. CDN-Cache-Control dotyczy wszystkich sieci CDN po drodze.
3. Cache-Control dotyczy przeglądarek, a gdy brakuje dwóch pozostałych, także Cloudflare.

Dzięki temu możesz osobno sterować przeglądarką i CDN. Przykład: przeglądarka ma trzymać plik tylko przez godzinę, a Cloudflare przez cały dzień.

Cache-Control: max-age=3600
Cloudflare-CDN-Cache-Control: max-age=86400

Jeśli twój serwer nie wysyła żadnych wskazówek, obowiązują wartości domyślne. Odpowiedzi ze statusem 200 i 301 zostają w cache przez 120 minut, przekierowania 302 i 303 tylko przez 20 minut, a błędy 404 i 410 przez trzy minuty. Ostatni punkt wielu zaskakuje: jeśli wgrasz brakujący obrazek dopiero po fakcie, Cloudflare może jeszcze przez kilka minut dostarczać stary komunikat o błędzie.

Jakie inne nagłówki ustawia Cloudflare?

Oprócz znanych już linijek możesz zauważyć jeszcze kilka innych:

• server: cloudflare zastępuje nazwę twojego serwera WWW. Z zewnątrz nikt już nie zobaczy, czy działa za nim Apache, nginx czy LiteSpeed.
• report-to i nel należą do Network Error Logging. Za ich pomocą przeglądarka zgłasza do Cloudflare błędy połączenia. Tę funkcję można wyłączyć w panelu Cloudflare, co ze względu na ochronę danych bywa istotne dla niektórych witryn.
• alt-svc informuje przeglądarkę, że witryna jest dostępna także przez HTTP/3. Cloudflare usuwa nagłówek alt-svc ustawiony przez twój serwer.

Kilka nagłówków twojego serwera nigdy zresztą nie dociera do odwiedzających. Należą do nich Cache-Tag i nagłówki X-Accel z nginx. Nie zdziw się więc, jeśli na próżno szukasz ich w przeglądarce.

Jak sprawdzić nagłówki Cloudflare za pomocą InspectWP?

InspectWP podczas tworzenia raportu odczytuje nagłówki twojej witryny i w sekcji nagłówków HTTP pokazuje między innymi cf-cache-status i cf-ray. Bez terminala widzisz więc, czy twoja witryna działa przez Cloudflare i w jaki sposób została dostarczona strona główna. Do tego dochodzą wartości związane z cache: kompresja, wersja HTTP i nagłówki bezpieczeństwa.

Najbardziej przydaje się to wtedy, gdy opiekujesz się kilkoma witrynami. Dzięki automatycznym raportom zauważysz, gdy strona nagle przestanie przychodzić z cache albo gdy po migracji witryna w ogóle przestanie działać za Cloudflare. Jeśli strona weryfikacyjna Cloudflare zablokuje pobieranie, InspectWP cię o tym poinformuje. W naszym artykule pomocy Co zrobić, gdy crawl się nie powiedzie wyjaśniamy, jak odpowiednio dostosować ochronę przed botami. Darmowy raport w krótkim czasie pokaże ci, jakie nagłówki wysyła teraz twoja witryna.