Alles leeren oder selektiv leeren
Alles zu leeren räumt den kompletten Cache einer Zone in einem einzigen Aufruf und passt nach einem Deployment, das viele Dateien verändert hat. Selektives Leeren räumt nur die genannten URLs, Hostnames, Tags oder Präfixe, hält den Rest des Caches warm und passt für eine einzelne geänderte Datei.
Zuletzt aktualisiert:
Cloudflare kennt fünf Wege, zwischengespeicherte Inhalte zu invalidieren. Seit dem 3. April 2025 stehen alle fünf in jedem Tarif zur Verfügung, auch im kostenlosen. Vor diesem Datum waren drei davon Enterprise vorbehalten — deshalb behaupten ältere Artikel oft noch das Gegenteil.
Die fünf Methoden im Vergleich
| Methode | Was geleert wird | Wofür geeignet | Tarife |
|---|---|---|---|
| Alles leeren | Der komplette Cache einer Zone | Ein Deployment, das viele Dateien berührt hat, oder wenn unklar ist, was sich geändert hat | Alle |
| Nach URL | Genau die angegebenen URLs | Eine Datei, die du gerade ersetzt hast | Alle |
| Nach Hostname | Alles, was von einem Hostname ausgeliefert wird | Eine neu gebaute Subdomain, etwa img.example.com | Alle |
| Nach Präfix | Alles unterhalb eines URL-Pfads | Ein ganzer Bereich, etwa example.com/blog/ | Alle |
| Nach Tag | Alles mit einem Cache-Tag-Header | Inhalte, die fachlich zusammengehören statt nach Pfad | Alle |
Wann alles geleert wird
Alles zu leeren ist ein API-Aufruf, braucht keine Dateiliste und kann nichts übersehen. Genau das ist der Reiz, und er ist real: nach dem Neubau einer statischen Seite, bei dem sich jeder Dateiname mit Hash geändert hat, ist das Aufzählen der Änderungen vergebliche Arbeit.
Der Preis: die Cache-Trefferquote dieser Zone fällt auf null. Jeder Besuch nach dem Purge geht an deinen Origin, bis der Cache sich wieder füllt. Auf einer kleinen Seite merkt das niemand. Auf einer Seite mit ernsthaftem Traffic ist es eine Lastspitze am Origin, die du selbst ausgelöst hast — und wenn dieser Origin ein einzelner bescheidener Server ist, ist genau diese Spitze das, was ihn umlegt.
Wann selektiv geleert wird
Selektives Leeren hält den Rest des Caches warm. Du hast ein Stylesheet geändert; es gibt keinen Grund, warum jedes Produktbild der Seite erneut vom Origin geholt werden müsste.
Dafür musst du genau sein. Ein Purge nach URL trifft exakt die angegebene URL, inklusive Query-String und Protokoll. Diese drei sind drei verschiedene Cache-Einträge:
https://example.com/style.csshttps://example.com/style.css?v=2https://www.example.com/style.css
Die erste zu leeren bringt für die anderen beiden nichts. Das ist mit Abstand der häufigste Grund für die Schlussfolgerung, „Purge funktioniert nicht“: es hat funktioniert, nur auf einer URL, die niemand abruft.
Hostname, Präfix und Tag
Zwischen „eine exakte URL“ und „die ganze Zone“ liegen drei Zwischenwege, und sie werden zu selten genutzt, weil sie jahrelang Enterprise-Geld gekostet haben:
- Hostname ist der gröbste der drei und braucht keine Vorbereitung. Alles unter
cdn.example.comneu gebaut? Ein Aufruf. - Präfix arbeitet auf URL-Pfaden, also leert
example.com/blog/sämtliche Beiträge, ohne den Shop anzufassen. - Tag ist der mächtigste und der einzige mit Vorbereitung: dein Origin muss einen
Cache-Tag-Header senden. Danach leerst du „alles zu Produkt 4471“, egal über wie viele URLs es verteilt ist.
Eine Entscheidung in fünf Sekunden
- Weißt du genau, welche Dateien sich geändert haben, und sind es weniger als hundert? Nach URL leeren.
- Hat sich eine ganze Subdomain oder ein Bereich geändert? Nach Hostname oder Präfix leeren.
- Sendet dein Origin bereits
Cache-Tag? Nach Tag leeren. - Sonst, oder wenn du unsicher bist und die Seite klein ist? Alles leeren.
Wie FlarePurge damit umgeht
FlarePurge deckt das vollständige Leeren sowie das selektive Leeren nach URL und Hostname ab, und die drei zusammen machen die überwiegende Mehrheit echter Purges aus. Du fügst deine URLs ein und die App teilt sie selbst in Stapel auf: aus einer Liste mit 90 URLs werden drei API-Aufrufe, ohne dass du darüber nachdenkst.
Dazu kommen Massen-Purges: alle Favoriten auf einmal oder alle Zonen eines ganzen Kontos hinter einer einzigen Bestätigung, mit gedeckelter Parallelität, damit die Limits von Cloudflare nicht gerissen werden. Diese Limits sind hier dokumentiert.