Cloudflare Header verstehen: cf-cache-status, cf-ray und Co. einfach erklärt

Du hast deine WordPress Website hinter Cloudflare gehängt und willst wissen, ob das CDN überhaupt etwas tut. In den Antworten deines Servers tauchen plötzlich Zeilen wie cf-cache-status: DYNAMIC oder cf-ray: 8f2a1c3d4e5f6a7b-FRA auf. Diese Header sind so etwas wie der Beipackzettel von Cloudflare: Sie zeigen dir, ob eine Datei aus dem Cache kam, welches Rechenzentrum geantwortet hat und ob eine Sicherheitsregel dazwischengegangen ist. Hier erfährst du, was die einzelnen Werte bedeuten und was du daraus für deine Website ableiten kannst.

Was sind Cloudflare Header und wie liest du sie aus?

Cloudflare sitzt als Proxy zwischen deinen Besuchern und deinem Server. Jede Anfrage läuft durch das Netzwerk von Cloudflare, und auf dem Weg kommen Header dazu. Manche davon sieht der Browser deiner Besucher, andere landen nur bei deinem Server. Wie so ein Netzwerk grundsätzlich arbeitet, erklärt unser Artikel Was ist ein CDN?.

Am schnellsten siehst du die Header in den Entwicklertools deines Browsers. Öffne den Tab „Netzwerk“, lade die Seite neu und klick auf die erste Zeile. Noch schneller geht es im Terminal:

curl -sI https://example.com/

Die Antwort sieht dann ungefähr so aus:

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

Fehlen alle Zeilen mit cf-, läuft die Anfrage gar nicht über Cloudflare. Meist steht der DNS Eintrag dann auf „Nur DNS“ (graue Wolke) statt auf „Proxied“ (orange Wolke).

Was bedeutet cf-cache-status? Alle Werte im Überblick

Der Header cf-cache-status ist der wichtigste von allen. Er sagt dir, wie Cloudflare mit genau dieser Antwort umgegangen ist. Die offizielle Dokumentation kennt neun Werte:

• HIT: Die Datei lag im Cache und kam direkt von Cloudflare. Dein Server hat davon nichts mitbekommen. Das ist der Wert, den du sehen willst.
• MISS: Die Datei darf gecached werden, lag in diesem Rechenzentrum aber noch nicht vor. Cloudflare hat sie von deinem Server geholt. Beim nächsten Aufruf sollte dort HIT stehen.
• EXPIRED: Die Datei lag im Cache, war aber abgelaufen. Cloudflare hat sie frisch von deinem Server geholt.
• REVALIDATED: Die Kopie im Cache war abgelaufen. Cloudflare hat bei deinem Server nachgefragt, ob sich etwas geändert hat, und die Antwort lautete nein. Die Datei kam also aus dem Cache, der Besucher musste aber auf die Rückfrage warten.
• UPDATING: Die Kopie war abgelaufen und wurde trotzdem sofort ausgeliefert, während Cloudflare sie im Hintergrund erneuert. Das passiert, wenn dein Server stale-while-revalidate sendet.
• STALE: Cloudflare hat eine abgelaufene Kopie ausgeliefert, weil dein Server nicht erreichbar war. Ein Warnzeichen, das du ernst nehmen solltest.
• BYPASS: Die Datei wäre grundsätzlich ein Kandidat für den Cache gewesen, die Antwort deines Servers hat das aber verhindert, zum Beispiel durch ein Cookie.
• DYNAMIC: Cloudflare hat gar nicht erst im Cache nachgesehen, weil dieser Inhalt nach den geltenden Regeln nicht gecached wird.
• NONE/UNKNOWN: Cloudflare hat die Antwort selbst erzeugt, etwa bei einer Weiterleitung auf HTTPS, einer Blockade durch die Firewall oder einem Worker.

Gut zu wissen: Seit dem 26. Mai 2026 trennt Cloudflare zwei dieser Werte sauberer. Früher bekamen manche Antworten, die nicht gecached werden konnten, bei jedem Aufruf ein MISS. Seit der Umstellung steht dort immer BYPASS. MISS heißt jetzt nur noch: cachebar, aber gerade nicht vorrätig. Viele ältere Anleitungen im Netz beschreiben noch das alte Verhalten.

Warum zeigt deine WordPress Website cf-cache-status: DYNAMIC?

Das ist die häufigste Frage zu diesem Thema, und die Antwort beruhigt: Bei einer normalen WordPress Seite ist DYNAMIC der Normalfall. Cloudflare cached in der Standardeinstellung weder HTML noch JSON. Entschieden wird nach der Dateiendung, nicht nach dem Inhalt. Bilder, CSS, JavaScript, Schriften und PDFs landen im Cache, das HTML deiner Seiten nicht.

Das hat einen guten Grund. WordPress erzeugt Seiten dynamisch, und Cloudflare kann nicht wissen, ob gerade ein Warenkorb, eine Admin Leiste oder ein persönlicher Gruß im HTML steckt. Würde es solche Seiten ungefragt cachen, sähe im schlimmsten Fall ein Besucher den Warenkorb eines anderen.

Deine Bilder und Skripte sollten dagegen HIT melden. Prüf deshalb nicht nur die Startseite, sondern auch eine CSS Datei oder ein Bild.

Willst du auch das HTML von Cloudflare ausliefern lassen, hast du zwei Wege:

• Cache Rule: Du legst im Dashboard eine Regel an, die HTML als „Eligible for cache“ markiert. Dann musst du selbst dafür sorgen, dass eingeloggte Nutzer, der Adminbereich, Warenkorb und Kasse ausgenommen bleiben.
• APO für WordPress: Die Automatic Platform Optimization übernimmt diese Ausnahmen für dich und leert den Cache, sobald du einen Beitrag änderst. Dazu weiter unten mehr.

Steht DYNAMIC auch bei Bildern oder CSS, liegt es meist an einer Regel mit „Bypass cache“ oder am Development Mode. Der schaltet den Cache für drei Stunden komplett ab und wird gern vergessen.

cf-cache-status BYPASS oder ständig MISS: Woran liegt es?

Bei BYPASS wollte Cloudflare cachen, aber die Antwort deines Servers hat es untersagt. Die Anleitung zur Fehlersuche nennt vor allem diese Ursachen:

• Die Antwort enthält einen Set-Cookie Header. Bei WordPress ist das der Klassiker: Ein Shop, ein Plugin für Mehrsprachigkeit oder ein Tracking Plugin setzt bei jedem Aufruf ein Cookie, und schon wird nichts mehr gecached.
• Dein Server sendet Cache-Control: no-store oder private.
• Die Antwort enthält Vary: *.
• Die Datei ist größer als das Limit deines Tarifs (512 MB in Free, Pro und Business).

Bleibt es bei jedem Aufruf bei MISS, ist die Datei zwar cachebar, Cloudflare findet sie aber nie wieder. Dahinter stecken oft wechselnde Parameter in der Adresse, etwa utm_source oder eine Session ID, denn jede Variante gilt als eigene Datei. Bei Websites mit wenig Besuchern fliegen selten abgerufene Dateien außerdem früher aus dem Cache. Und jedes Rechenzentrum hat seinen eigenen Cache: Landen zwei Anfragen an verschiedenen Standorten, siehst du zweimal MISS.

Ein guter Helfer ist der Header Age. Er gibt in Sekunden an, wie lange die Kopie schon im Cache liegt. Rufst du eine Datei zweimal hintereinander ab und siehst HIT mit steigendem Age, funktioniert alles.

Was verrät der Header cf-ray?

Jede Anfrage, die durch Cloudflare läuft, bekommt eine eigene Kennung, die Ray ID. Sie steht im Header cf-ray und besteht aus zwei Teilen: einer Zeichenfolge und einem Kürzel aus drei Buchstaben. Das Kürzel nennt das Rechenzentrum, das geantwortet hat. FRA steht für Frankfurt, AMS für Amsterdam, CDG für Paris.

Im Alltag hilft dir die Ray ID an drei Stellen. Zeigt Cloudflare einem Besucher eine Fehlerseite, steht die Ray ID unten auf der Seite, und du findest damit genau diese Anfrage in den Logs oder den Security Events wieder. Zweitens erkennst du am Kürzel, ob deine Besucher wirklich an einem nahen Standort landen. Und drittens erklärt es so manches rätselhafte MISS, wenn zwei Anfragen in verschiedenen Rechenzentren angekommen sind.

Dieselbe Ray ID schickt Cloudflare übrigens auch an deinen Server. Schreibst du sie dort ins Log, kannst du eine Anfrage vom Browser bis zu PHP verfolgen.

cf-apo-via und cf-edge-cache: Läuft APO für WordPress?

Nutzt du die Automatic Platform Optimization, kommen zwei weitere Header dazu. Laut Cloudflare erkennst du eine funktionierende Einrichtung an drei Zeilen:

• cf-cache-status: HIT zeigt, dass das HTML aus dem Cache kam.
• cf-apo-via: tcache zeigt, dass APO die Anfrage bedient hat.
• cf-edge-cache: cache,platform=wordpress bestätigt, dass das Cloudflare Plugin in WordPress installiert und aktiv ist.

Fehlt cf-edge-cache, ist meist das Plugin deaktiviert oder nicht mit deinem Konto verbunden. Steht bei cf-apo-via ein anderer Wert als tcache, hat APO die Seite nicht aus dem Cache geliefert, zum Beispiel weil du eingeloggt bist. Teste deshalb immer in einem privaten Fenster.

Was bedeutet cf-mitigated: challenge?

Dieser Header taucht nur auf, wenn Cloudflare statt deiner Seite eine Prüfseite ausliefert, also den bekannten Hinweis, dass der Besucher kurz verifiziert wird. challenge ist der einzige gültige Wert.

Für Menschen ist das meist nur eine kurze Verzögerung. Für alles, was automatisch auf deine Website zugreift, ist es ein echtes Hindernis. Die Prüfseite ist immer HTML, auch wenn eigentlich JSON angefragt wurde. Ruft dein eigenes JavaScript die REST API auf und bekommt plötzlich eine Prüfseite zurück, läuft es in einen Fehler, den du ohne diesen Header kaum einordnen könntest. Dasselbe gilt für Monitoring Dienste, Zahlungsanbieter mit Webhooks und Analysetools. Siehst du cf-mitigated: challenge bei Zugriffen, die durchgehen sollten, lohnt ein Blick in die Security Events im Dashboard. Dort steht, welche Regel angeschlagen hat.

Welche Cloudflare Header kommen bei deinem Server an?

Nicht alle Header sind für den Browser gedacht. Einige hängt Cloudflare an die Anfrage, bevor sie deinen Server erreicht. Die vollständige Liste ist lang, für WordPress sind vor allem diese wichtig:

• CF-Connecting-IP: die echte IP Adresse des Besuchers. Ohne diesen Header sieht dein Server nur Adressen von Cloudflare.
• X-Forwarded-For: die Kette aller Proxys, durch die die Anfrage gelaufen ist. Cloudflare empfiehlt, für die Besucheradresse lieber CF-Connecting-IP zu lesen.
• X-Forwarded-Proto und CF-Visitor: zeigen, ob der Besucher per HTTP oder HTTPS gekommen ist.
• CF-IPCountry: das Land des Besuchers als Kürzel aus zwei Buchstaben. XX heißt unbekannt, T1 steht für das Tor Netzwerk.
• CDN-Loop: schützt davor, dass eine Anfrage endlos im Kreis durch Cloudflare läuft.

Die echte IP Adresse ist mehr als ein Detail. Sicherheitsplugins sperren Angreifer nach IP Adresse, WordPress speichert sie bei Kommentaren, und dein Hoster wertet sie in den Logs aus. Kommt dort nur die Adresse von Cloudflare an, sperrt dein Plugin im Zweifel alle Besucher auf einmal aus. Die meisten Hoster und Sicherheitsplugins lassen sich darauf einstellen. Wichtig dabei: Vertrau dem Header nur, wenn die Anfrage wirklich von einer Adresse aus dem Netz von Cloudflare stammt. Sonst kann sich jeder eine beliebige IP Adresse in den Header schreiben.

Auch eine bekannte Fehlerquelle hängt hier dran. Bei der SSL Einstellung „Flexible“ spricht Cloudflare mit deinem Server unverschlüsselt. WordPress glaubt dann, der Besucher sei per HTTP gekommen, leitet auf HTTPS um, und es entsteht eine Endlosschleife. Die saubere Lösung ist ein Zertifikat auf dem Server und die Einstellung „Full (strict)“.

Wie steuerst du mit Cache-Control, was Cloudflare cached?

Wie lange Cloudflare eine Datei behält, bestimmt in erster Linie dein Server. Dafür gibt es drei Header, die Cloudflare in dieser Reihenfolge auswertet:

1. Cloudflare-CDN-Cache-Control gilt nur für Cloudflare und wird nicht an den Browser weitergereicht.
2. CDN-Cache-Control gilt für alle CDNs auf dem Weg.
3. Cache-Control gilt für Browser und, wenn die anderen beiden fehlen, auch für Cloudflare.

Damit kannst du Browser und CDN getrennt steuern. Ein Beispiel: Der Browser soll eine Datei nur eine Stunde behalten, Cloudflare aber einen ganzen Tag.

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

Sendet dein Server gar keine Angaben, greifen die Standardwerte. Antworten mit Status 200 und 301 bleiben 120 Minuten im Cache, Weiterleitungen mit 302 und 303 nur 20 Minuten, Fehler mit 404 und 410 drei Minuten. Der letzte Punkt überrascht viele: Lädst du ein fehlendes Bild nach, kann Cloudflare noch ein paar Minuten lang die alte Fehlermeldung ausliefern.

Welche weiteren Header setzt Cloudflare?

Neben den bekannten Zeilen fallen dir vielleicht noch ein paar andere auf:

• server: cloudflare ersetzt die Angabe deines Webservers. Ob dahinter Apache, nginx oder LiteSpeed läuft, sieht von außen niemand mehr.
• report-to und nel gehören zum Network Error Logging. Der Browser meldet darüber Verbindungsfehler an Cloudflare. Die Funktion lässt sich im Dashboard abschalten, was mit Blick auf den Datenschutz für manche Websites interessant ist.
• alt-svc kündigt dem Browser an, dass die Website auch per HTTP/3 erreichbar ist. Einen eigenen alt-svc Header deines Servers entfernt Cloudflare.

Ein paar Header deines Servers kommen übrigens nie beim Besucher an. Dazu gehören Cache-Tag und die X-Accel Header von nginx. Wunder dich also nicht, wenn du sie im Browser vergeblich suchst.

Wie prüfst du Cloudflare Header mit InspectWP?

InspectWP liest beim Erstellen eines Reports die Header deiner Website aus und zeigt dir im Bereich HTTP Header unter anderem cf-cache-status und cf-ray an. Du siehst also ohne Terminal, ob deine Website über Cloudflare läuft und wie die Startseite ausgeliefert wurde. Dazu kommen die Werte, die mit dem Caching zusammenhängen: die Komprimierung, die HTTP Version und die Header für Sicherheit.

Praktisch ist das vor allem, wenn du mehrere Websites betreust. Mit automatischen Reports fällt dir auf, wenn eine Seite plötzlich nicht mehr aus dem Cache kommt oder Cloudflare nach einem Umzug gar nicht mehr davorhängt. Blockiert eine Prüfseite von Cloudflare den Abruf, weist dich InspectWP darauf hin. In unserem Hilfeartikel Was tun, wenn der Crawl nicht klappt? steht, wie du den Bot Schutz dafür passend einstellst. Ein kostenloser Report zeigt dir in kurzer Zeit, welche Header deine Website gerade sendet.