Weiterleitungen mit Cloudflare

Deine Möglichkeiten im Überblick

Cloudflare hat gleich mehrere Funktionen, die Weiterleitungen senden. Sie überschneiden sich teilweise, deshalb lohnt es sich, bewusst zu wählen:

Funktion	Geltungsbereich	Ideal für
Single Redirects (Redirect Rules)	Eine Zone	Regelbasierte Weiterleitungen mit Bedingungen und dynamischen Zielen: www, HTTPS, Ordner, Muster
Bulk Redirects	Ganzes Konto	Lange Listen fester Weiterleitungen von URL zu URL, Domain-Umzüge
Always Use HTTPS	Eine Zone	Ein Schalter, der jede HTTP-Anfrage auf HTTPS umleitet
Page Rules (Forwarding URL)	Eine Zone	Veraltet, nicht mehr für neue Setups nutzen
Workers	Selbst definierte Routen	Logik, die sich mit Regeln nicht abbilden lässt, etwa Lookups in einem KV-Store

Alle funktionieren nur für Hostnamen, deren DNS-Einträge proxied sind (orange Wolke). Ein reiner DNS-Eintrag schickt den Traffic direkt an deinen Server – Cloudflare bekommt die Anfrage dann gar nicht zu sehen.

Single Redirects

Single Redirects sind die Nachfolger der Forwarding-URL-Page-Rules. Du legst sie in deiner Zone unter Rules als Redirect Rule an. Jede Regel besteht aus zwei Teilen: einem Filterausdruck, der festlegt, welche Anfragen passen, und einer Weiterleitungsaktion mit Ziel-URL, Statuscode (301, 302, 303, 307 oder 308) und der Option „Preserve query string“. Wie viele Regeln du anlegen darfst, hängt von deinem Tarif ab. Alle Details stehen in der Cloudflare-Dokumentation.

Einzelne Seite weiterleiten (statisches Ziel)

Ausdruck:

http.request.uri.path eq "/alte-seite"

Aktion: Typ Static, URL https://example.com/neue-seite/, Statuscode 301. Setz den Haken bei „Preserve query string“, wenn Parameter wie Tracking-Codes erhalten bleiben sollen.

Gleicher Pfad auf anderem Host (dynamisches Ziel)

Für eine Weiterleitung von www auf die Domain ohne www baust du das Ziel mit concat() zusammen:

Ausdruck:  http.host eq "www.example.com"
Ziel:      concat("https://example.com", http.request.uri.path)
Status:    301, Preserve query string: an

Weil der Pfad aus http.request.uri.path kommt und der Query-String separat erhalten bleibt, landet https://www.example.com/shop/?seite=2 auf https://example.com/shop/?seite=2.

Ordner und Muster

Einen Ordner verschiebst du am einfachsten mit Wildcard-Mustern. Wähl im Regeleditor den Wildcard-Abgleich und trag Anfrage- und Ziel-URL ein – oder schreib es als Ausdruck:

Ausdruck:  http.request.full_uri wildcard r"https://example.com/blog/*"
Ziel:      wildcard_replace(http.request.full_uri, r"https://example.com/blog/*", "https://example.com/artikel/${1}")

${1} wird durch das ersetzt, was auf das erste * gepasst hat. Für komplexere Fälle gibt es regex_replace() zusammen mit dem Operator matches; ob dir reguläre Ausdrücke zur Verfügung stehen, hängt vom Tarif ab.

HTTPS und www in einem Hop

Das klassische Setup ist „Always Use HTTPS“ (unter SSL/TLS → Edge Certificates) plus ein Single Redirect von www auf die Domain ohne www. Je nachdem, wie beides zusammenspielt, braucht http://www.example.com/ dann zwei Hops: erst nach https://www.example.com/, dann nach https://example.com/. Jeder zusätzliche Hop kostet Zeit und macht Redirect-Ketten wahrscheinlicher.

Mit einer einzigen Regel, die beide Fälle abdeckt, umgehst du das:

Ausdruck:  (http.host eq "www.example.com") or (http.host eq "example.com" and not ssl)
Ziel:      concat("https://example.com", http.request.uri.path)
Status:    301, Preserve query string: an

Das Feld ssl ist wahr, wenn der Besucher per HTTPS verbunden ist. Mit dieser Regel brauchst du Always Use HTTPS für die beiden Hostnamen nicht mehr. Lässt du es für andere Subdomains eingeschaltet, prüf http://www.example.com/ mit dem Redirect-Checker und stell sicher, dass die URL in genau einem Schritt ankommt. Hintergründe zu beiden Themen: HTTP auf HTTPS und www-Weiterleitung.

Bulk Redirects

Bulk Redirects sind für Listen gemacht: Hunderte oder Tausende fester Quell- und Ziel-URLs, etwa nach einem Relaunch oder einem Domain-Umzug. Du konfigurierst sie auf Kontoebene statt pro Zone, und sie bestehen aus zwei Teilen:

1. Einer Bulk Redirect List mit den Einträgen. Die legst du einzeln an oder lädst eine CSV-Datei hoch.
2. Einer Bulk Redirect Rule, die die Liste aktiviert. Ohne Regel passiert mit der Liste nichts.

Jeder Eintrag hat eine Quell-URL, eine Ziel-URL, einen Statuscode und ein paar Optionen:

• Preserve query string: übernimmt Parameter ins Ziel.
• Include subdomains: Der Eintrag greift auch für Subdomains des Quell-Hosts.
• Subpath matching: Der Eintrag greift auch für alle Pfade unterhalb der Quell-URL.
• Preserve path suffix: hängt zusammen mit Subpath matching den restlichen Pfad ans Ziel an. alte-domain.de/ nach https://example.com/ mit beiden Optionen zieht eine komplette Domain um und behält dabei jeden Pfad.

Hat die Quell-URL kein Schema, passt sie auf HTTP und HTTPS gleichermaßen. Reguläre Ausdrücke oder Wildcards unterstützen Bulk Redirects bewusst nicht – genau deshalb sind sie auch bei riesigen Listen schnell. Brauchst du Muster, nimm Single Redirects.

Eine Domain, die du nur noch für Weiterleitungen behältst, braucht keinen Server. Leg einen proxied DNS-Eintrag auf eine Platzhalteradresse an, etwa einen A-Eintrag auf 192.0.2.1 oder einen AAAA-Eintrag auf 100::, und lass die Redirect-Regel jede Anfrage beantworten.

Page Rules sind ein Auslaufmodell

Jahrelang war „Forwarding URL“ in den Page Rules der Weg, um bei Cloudflare weiterzuleiten. Page Rules sind inzwischen veraltet, und Cloudflare empfiehlt, sie durch die neueren Rules-Produkte zu ersetzen – bei Weiterleitungen also durch Single Redirects. Die Migration ist meist unkompliziert: Aus einer Page Rule mit dem Muster www.example.com/* und dem Ziel https://example.com/$1 wird die Wildcard- oder concat()-Regel von oben. Deaktivier nach der Umstellung die alte Page Rule und teste, damit sich nichts überschneidet.

Doppelte Weiterleitungen und Schleifen mit dem Origin vermeiden

Die meisten Redirect-Probleme mit Cloudflare entstehen, weil zwei Ebenen denselben Job erledigen: Cloudflare am Edge und dein Webserver (.htaccess, nginx, ein CMS-Plugin) am Origin.

• SSL-Modus „Flexible“ plus HTTPS-Weiterleitung am Server ist die häufigste Schleife. Im Modus Flexible spricht Cloudflare per unverschlüsseltem HTTP mit deinem Server. Der sieht HTTP, leitet auf HTTPS um, der Browser kommt über Cloudflare zurück, das wieder per HTTP anfragt – bis der Browser „zu viele Weiterleitungen“ meldet. Lösung: Zertifikat auf dem Origin installieren und auf Full (strict) umstellen.
• Widersprüchliche Host-Regeln. Cloudflare leitet www auf die Domain ohne www um, der Server (etwa WordPress mit eingetragener www-URL) schickt sie wieder zurück auf www. Das ist eine Schleife. Leg dich auf einen kanonischen Host fest und konfigurier ihn überall gleich.
• Gestapelte Hops. Der Edge leitet auf https://example.com/shop weiter, danach hängt der Server noch einen Slash an. Zwei Hops. Lass deine Edge-Regeln direkt auf die endgültige URL zeigen, inklusive Slash und Schreibweise.
• Gecachte Weiterleitungen. Cloudflare kann Weiterleitungsantworten deines Servers cachen. Nach Änderungen am Server leerst du also erst den Cache, bevor du testest.

Faustregel: Um Protokoll und Host kümmerst du dich genau einmal, und zwar am Edge; auf dem Server bleiben nur inhaltsbezogene Weiterleitungen. Edge-Redirects kommen ohne Umweg über deinen Server aus und sind damit auch für Besucher die schnellste Variante.

Testen

Redirect-Regeln greifen innerhalb von Sekunden. Teste mit dem Redirect-Checker statt im Browser, denn der cacht 301-Weiterleitungen. Prüf jede Variante: HTTP und HTTPS, mit und ohne www, mit Query-String. Jede sollte die endgültige URL in genau einem Hop und mit dem gewählten Statuscode erreichen. Bei großen Bulk-Redirect-Listen jagst du eine Stichprobe der Quell-URLs durch den Bulk-Redirect-Checker.