Cloudflare vor Shopify zu setzen ist jetzt sicherer: was O2O behoben hat und was die Warnungen weiterhin bedeuten.

Schnellstart: So richten Sie es in Ihrem Shop ein

Wenn Sie wegen der Schritte hier sind: hier sind sie. Das gesamte Setup besteht aus einem proxied CNAME in Cloudflare, derselben Domain, die in Shopify verbunden wird, und einem HTTPS-Schalter, den Sie in Ruhe lassen. Der Rest dieses Artikels erklärt, warum jeder Schritt zählt und wie Sie prüfen, ob er gehalten hat, aber das hier ist die komplette Konfiguration.

Lieber ansehen: Field Notes: Cloudflare in front of Shopify behandelt dasselbe Thema in drei Minuten, mit vollständigem Transkript auf der Seite.

Schritt 1 im Cloudflare-Dashboard: Beide Einträge sind CNAMEs auf shops.myshopify.com mit Proxy status Proxied.

Die in diesem Artikel gezeigten clawmart.digital-Werte stammen aus einem echten Testshop, den wir auf einer voll funktionsfähigen Shopify-Instanz betreiben, nicht aus einem Mockup. Jeder Screenshot, jeder Eintrag und jeder Test weiter unten stammt aus diesem Shop.

Die Warnung auf einem funktionierenden Shop

Ihre Shopify-Domain wird als verbunden angezeigt, der Checkout funktioniert, und das SSL-Schloss ist da. Direkt unter diesem grünen Status steht eine gelbe Warnung, dass Ihre Domain einen Cloudflare-Proxy hat, den Shopify nicht unterstützt. Beides stimmt gleichzeitig, und an diesem Widerspruch bleiben die meisten Händler hängen.

Das ist eine der verwirrendsten Meldungen in der E-Commerce-Infrastruktur, weil sie weder falsch noch ganz richtig ist. Jahrelang war es tatsächlich eine schlechte Idee, Cloudflare vor Shopify zu setzen, weil es Shops auf eine bestimmte, vorhersehbare Weise lahmgelegt hat. Dann hat Cloudflare eine Routing-Funktion ausgeliefert, die genau das behoben hat, was kaputtging, und trotzdem sagt Shopify Ihnen weiterhin, Sie sollen es lassen. In dieser Lücke zwischen einer Lösung, die funktioniert, und einem Anbieter, der sie nicht absegnet, sitzt die Sorge, der eigene Shop könnte gleich zusammenbrechen.

Also hier die praktische Version: was tatsächlich kaputtging, was O2O behoben hat, die eine Einstellung, die Ihre Website weiterhin lahmlegt, wenn Sie sie übersehen, und wie Sie entscheiden, ob irgendetwas davon zu Ihrem Shop passt.

Warum es früher kaputtging: zwei orange Wolken

Cloudflare zeigt eine proxied Domain als orange Wolke. Traffic zu dieser Domain läuft durch Cloudflares Netzwerk, bevor er Ihr Origin erreicht. Der Haken bei Shopify ist, dass Shopify selbst auf Cloudflare läuft. Wenn Sie also Ihre orange geschaltete Domain auf Shopify zeigen lassen, kommt der Request bei Cloudflare an, und zwei Zonen beanspruchen ihn: Ihre und die von Shopify. Zwei orange Wolken, übereinander.

Historisch konnte Cloudflare nicht zuverlässig bestimmen, welche Zone diesen Request besitzen sollte, also wurde er an die falsche Stelle aufgelöst oder lief in eine Schleife. Das Ergebnis war ein Shop, der halb funktionierte und auf schwer reproduzierbare Weise versagte.

Am schärfsten war die Kante bei SSL. Shopify stellt Ihr Zertifikat über Let's Encrypt bereit und erneuert es, und Let's Encrypt weist Ihren Domain-Besitz mit einer ACME-Challenge nach, die unter einem bestimmten Pfad ausgeliefert wird:

Wenn ein Proxy vor Shopify diesen Pfad abfängt, cached oder umleitet, wird die Challenge nie abgeschlossen. Keine abgeschlossene Challenge heißt kein Zertifikat. Und weil Zertifikate nach einem Zeitplan erneuert werden, scheiterte das oft still: Der Shop lief wochenlang problemlos mit dem vorhandenen Zertifikat und wurde an dem Tag unsicher, an dem es ablief. Deshalb bestand der alte Rat aus einer knappen Zeile: Wolke grau schalten, DNS only, Cloudflares Proxy aus dem Pfad nehmen.

Was Orange-to-Orange verändert hat

Orange-to-Orange, kurz O2O, ist Cloudflares Antwort auf das Zwei-Zonen-Problem und Teil eines Produkts namens Cloudflare for SaaS. Cloudflare hat dieses Produkt 2021 für alle Kunden geöffnet, allgemein verfügbar seit Oktober desselben Jahres, O2O ist also ein etablierter Routing-Pfad mit Jahren dahinter, kein junges Experiment. Der Mechanismus ist unkompliziert: Wenn Ihre proxied Zone einen CNAME auf einen Dienst zeigen lässt, der ebenfalls Cloudflare-for-SaaS-Kunde ist, erkennt Cloudflare das Ziel und behandelt die beiden Zonen nicht länger als Kollision. Der Request läuft zuerst durch Ihre Zone und danach durch die des Anbieters, in einer definierten Reihenfolge, und aus dem doppelten Proxy wird eine Übergabe.

Sie müssen nicht darauf vertrauen, dass O2O greift. Legen Sie den CNAME mit aktiviertem Proxy an, und Cloudflare setzt ein kleines Shopify-Symbol neben den Eintrag. Dieses Symbol ist die Erkennung, die bestätigt, dass Cloudflare weiß, wohin der Traffic geht. Cloudflare erledigt im Hintergrund außerdem anbieterspezifische Aufräumarbeiten und deaktiviert unter anderem Workers und Snippets auf dem Pfad /checkout, damit nichts, was Sie an der Edge laufen lassen, die Zahlung stören kann.

Diesen Eintrag legen Sie im Cloudflare-Dashboard unter DNS und dann Records an. Klicken Sie auf Add record, setzen Sie Type auf CNAME, Target auf shops.myshopify.com und Proxy status auf Proxied, sodass die Wolke orange wird. Das Shopify-Symbol erscheint neben dem Eintrag, sobald Cloudflare das Ziel als einen seiner eigenen SaaS-Kunden erkennt.

Die eine Ausnahme im Griff behalten: SSL

O2O hat die Routing-Kollision behoben. SSL hat es nicht behoben, denn SSL war nie wirklich ein Routing-Problem. Es war ein Proxy, der genau den Pfad berührt, über den Shopify Zertifikate erneuert. In einem korrekt eingerichteten Shop läuft davon inzwischen fast alles von selbst, nützlich ist also zu wissen, was automatisch passiert, und danach die kurze Liste durchzugehen, die es nicht tut.

Was heute automatisch passiert

Ihr Shop trägt zwei Zertifikate, und beide erneuern sich ohne Ihr Zutun. Weil die Domain proxied ist, ist das Zertifikat, das Besucher sehen, Cloudflares eigenes Edge-Zertifikat, das Cloudflare über DNS validiert und selbst erneuert, der ACME-Pfad kommt damit nie in Berührung. Dahinter hält Shopify ein separates Origin-Zertifikat für die Strecke von Cloudflare zu Shopify vor, erneuert über Let's Encrypt, und Ihr Verschlüsselungsmodus Full ist genau dafür gebaut, ihm zu vertrauen. Shopify führt außerdem die Anhebung von HTTP auf HTTPS am eigenen Origin durch, Besucher landen also auf einer sicheren Verbindung, ob Cloudflare dafür etwas tut oder nicht.

Dieses Origin-Zertifikat erneuert sich über ACME, den automatisierten Austausch, mit dem Let's Encrypt bestätigt, dass Sie die Domain kontrollieren. Wer auch immer für Ihre Domain antwortet, wird aufgefordert, ein Einmal-Token unter dem obigen Pfad über einfaches HTTP auszuliefern, und Shopify wickelt den gesamten Austausch im Hintergrund ab. Deshalb denken Sie nie darüber nach. Das Setup bleibt genau so lange gesund, wie dieser eine Pfad erreichbar bleibt.

Das eine, was es kaputt macht

Diese ganze automatische Erneuerung hängt daran, dass eine Cloudflare-Einstellung ausgeschaltet bleibt, und in vielen Setups ist sie standardmäßig an.

Die Lösung besteht also im Wesentlichen darin, diesen Schalter nicht einzuschalten und Shopifys Origin-Umleitung die Anhebung machen zu lassen, die sie ohnehin durchführt. Wenn Sie möchten, dass Cloudflare HTTPS auch an seiner eigenen Edge erzwingt, nutzen Sie eine Redirect-Regel, die den Challenge-Pfad auslässt, niemals Always Use HTTPS.

Was Sie stichprobenartig prüfen sollten

Alles Folgende liegt im Cloudflare-Dashboard. Melden Sie sich unter dash.cloudflare.com an, wählen Sie Ihr Konto und klicken Sie auf die Domain, um ihre Zone zu öffnen. Jeder Punkt ist ein Pfad in der linken Seitenleiste dieser Zone.

Ein Nachbar auf dieser Edge-Certificates-Seite bringt viele durcheinander: Automatic HTTPS Rewrites kann bedenkenlos an bleiben. Es schreibt lediglich http-Ressourcenlinks auf https um, um Mixed-Content-Warnungen zu vermeiden, was etwas ganz anderes ist als Always Use HTTPS, das eine Umleitung der ganzen Seite erzwingt. Opportunistic Encryption und TLS 1.3 können ebenfalls an bleiben. Always Use HTTPS ist der einzige Schalter auf diesem Bildschirm, der aus bleiben muss.

Bestätigen Sie es dann von außen, ohne auf eine gescheiterte Erneuerung zu warten. Rufen Sie den Challenge-Pfad über einfaches HTTP ab und lesen Sie die Antwort:

curl -sI http://clawmart.digital/.well-known/acme-challenge/test

Shopify zu erreichen ist der Erfolg, und ein 404 für das erfundene Token ist genau richtig. Eine Umleitung mit 301 oder 308 auf HTTPS bedeutet, dass Always Use HTTPS oder eine Catch-all-Regel den Pfad noch verschluckt. Prüfen Sie danach den SSL-Status unter Settings → Domains in Ihrem Shopify-Admin, und beobachten Sie über die folgenden Wochen, wie sich das Ablaufdatum des Origin-Zertifikats von selbst nach vorne bewegt. Ein Zertifikat, das sich unangetastet erneuert, ist das Signal, dass das Setup hält.

Führen Sie diesen Test nach jeder Änderung an Ihrem DNS oder Ihren Cloudflare-Einstellungen erneut aus, nicht nur bei der Einrichtung. Der Shopify-Community-Nutzer Hardeep hat das im Thread zu diesem Artikel angesprochen, und es passt dazu, wie diese Setups tatsächlich scheitern. Die Konfiguration war an Tag eins richtig, jemand hat Monate später eine Regel oder einen Eintrag bearbeitet, und niemand hat den Challenge-Pfad erneut geprüft, bis ein Zertifikat sich still nicht mehr erneuert hat.

Eine Falle sollte klar benannt werden: Ein Zertifikat, das heute als bereitgestellt angezeigt wird, sagt Ihnen, dass das aktuelle ausgestellt wurde, nicht dass die nächste Erneuerung klappt. Let's-Encrypt-Zertifikate erneuern sich in einem Zyklus von grob sechzig bis neunzig Tagen, ein Shop, der völlig gesund aussieht, hat sein Erneuerungsdatum also vielleicht einfach noch nicht erreicht. Das, zusammen mit der Tatsache, dass viele Shops Always Use HTTPS von vornherein nie eingeschaltet haben, ist der Grund, warum etliche das monatelang ohne Zwischenfall betreiben und warum der Fehler, wenn er kommt, verwirrend ist. Nichts hat sich geändert, außer einem Zertifikat, das sich still nicht erneuert hat.

Gewichten Sie es richtig. Das ist eine günstige Versicherung gegen einen seltenen, aber stillen Fehler, kein Zeichen dafür, dass Ihr Shop kurz vor dem Zusammenbruch steht. Erledigen Sie die zweiminütige Konfiguration, führen Sie den Test aus, und Sie haben die eine Lücke zum Erneuerungszeitpunkt geschlossen, die wirklich schwer zu bemerken ist.

Shopify segnet das trotzdem nicht ab, weil …

Shopifys Dokumentation redet nicht mehr allgemein um Proxys herum. Sie nennt O2O direkt:

"Cloudflare-Proxy-Setups, einschließlich O2O, werden von Shopify nicht unterstützt. Auch wenn Ihr Shop korrekt zu funktionieren scheint, kann dieses Setup jederzeit brechen."

Das ist keine veraltete Warnung vor einem gelösten Problem. Es ist eine aktuelle, bewusste Position, und zwei der Gründe dahinter halten auch nach O2O stand:

Shopifys eigene Dokumentation nennt einen dritten Grund, Bot-Erkennung, und argumentiert, dass Traffic durch Cloudflare mit veränderten Request-Attributen ankommt. In der Praxis ist das der schwächste der drei: Cloudflare betreibt eines der größten Bot-Management-Netzwerke überhaupt, die meisten Shops gewinnen an der Edge also weit mehr Bot-Filterung, als Shopify an Signal verliert. Es ist der eine Punkt auf Shopifys Liste, bei dem der Proxy eher hilft als schadet.

Ist die Warnung überzogen?

Ein wenig, und das verständlicherweise. Das Dashboard markiert einen funktionierenden, verbundenen Shop mit einem gelben Issue und der nüchternen Formulierung nicht unterstützt, was schwerer wiegt als die tatsächlichen Fehlerfälle, von denen sich die meisten mit korrekter Konfiguration vermeiden lassen. Ein Händler liest Issue und hört, sein Shop stehe kurz vor dem Zusammenbruch, während Shopify eher meint, dass es für dieses Setup nicht geradesteht.

Aber nicht unterstützt ist nicht dasselbe wie funktioniert nicht, und der Unterschied zählt. Es bedeutet, dass Shopify für das Verhalten in einer Schicht, die es nicht kontrolliert, weder garantiert noch debuggt noch Verantwortung übernimmt. Für eine Plattform, der Ihr Checkout und Ihre Verfügbarkeit gehören, ist das eine vernünftige Grenze, auch wenn das Banner sie grob zieht. Die Markierung sagt Ihnen, dass Shopify nicht für das Setup einsteht. Sie sagt Ihnen nicht, dass das Setup versagt.

Viele Shopify-Shops betreiben genau das

Sie müssen sich nicht auf das Wort eines einzelnen Testshops verlassen. Ein Cloudflare-Proxy vor Shopify ist keine Randkonfiguration: Etliche etablierte Marken betreiben ihn täglich in Produktion. Die Namen unten sind Live-Beispiele, die wir von Hand geprüft haben, jedes davon liefert seinen Storefront derzeit über einen Cloudflare-Proxy mit Shopify dahinter aus.

Geprüft im Juli 2026, indem jede Domain abgerufen und eine Cloudflare-Proxy-Antwort zusammen mit Shopify-Storefront-Merkmalen bestätigt wurde. Das Setup eines Shops kann sich jederzeit ändern, betrachten Sie das also als Momentaufnahme, nicht als Empfehlung durch die genannten Marken.

Was Ihnen die Edge bringt, was Shopify nicht liefert

Shopify liefert auf jedem Plan bereits ein CDN, SSL-Zertifikate und DDoS-Schutz mit, worauf Hardeep im Community-Thread ebenfalls hingewiesen hat. Der Proxy ist nicht das, was Ihren Shop schnell, verschlüsselt oder widerstandsfähig gegen eine Flut macht, und wenn Sie danach gesucht haben, haben Sie es bereits. Was folgt, ist die engere Auswahl an Dingen, die Shopify Ihnen nicht in die Hand gibt.

Der Grund, den Tradeoff einzugehen, ist nicht der Proxy selbst. Es ist die Schicht, die der Proxy vor Ihren Shop legt, eine programmierbare Edge, die Shopify Ihnen nicht zugänglich macht. Drei Fähigkeiten zählen am meisten, und die dritte bekommen die meisten Shops überhaupt nie zu sehen.

Nichts davon kommt mit einem Shopify-Plan, weil nichts davon in Shopify lebt. Es lebt einen Hop früher, an der Edge, und genau das ist der ganze Grund, warum ein Händler überhaupt einen nicht unterstützten Proxy in Kauf nimmt.

Eine Einschränkung: Edge-Caching passiert nicht automatisch. Cloudflare kann statische Dateien wie Stylesheets und Bilder an seiner Edge vorhalten und von einem nahen Server ausliefern, statt sie bei jedem Besuch von Shopify zu holen, aber ein proxied Shopify-Shop cached nicht von selbst, und eine standardmäßige oder falsch zugeschnittene Cache-Regel kann das komplett unterdrücken, sodass Dateien, die für ein Jahr als cachefähig markiert sind, unangetastet durchgereicht werden. Shopifys eigenes Netzwerk hält den Storefront ohnehin schnell, betrachten Sie Edge-Caching also als Geschwindigkeitsbonus, für den Sie sich bewusst entscheiden. Den Verschlüsselungsmodus, der die alten SSL-Probleme verhindert, bestätigen Sie in den SSL/TLS-Konfigurationen, demselben Bildschirm wie die weiter oben behandelte Schaltfläche Configure; Caching wird in einem eigenen Bereich eingestellt, es lohnt sich also, beides zu prüfen, solange Sie im Dashboard sind, denn Caching ist die Einstellung, die am wahrscheinlichsten Geschwindigkeit verschenkt.

Wovor ein Entwickler Sie warnen wird

Ein guter Entwickler winkt das nicht ohne Fragen durch, und die Fragen sind berechtigt. Keine davon ist ein Grund, das Setup zu meiden, aber jede lohnt es, auf dem eigenen Shop zu bestätigen, statt sie zu glauben. Das ist keine Zusatzarbeit: Es ist dasselbe Testen, das Sie nach jeder Infrastrukturänderung durchführen würden, und es gehört dazu, einen Shop gesund zu halten. Wir testen beides auf dem Shop, den wir betreiben, und Sie sollten das auch.

Latenz bei der Übergabe

Die erste Frage ist Geschwindigkeit: Kostet das Routing durch Ihre Cloudflare-Zone vor Shopifys eigener Zone spürbar Zeit? Sollte es nicht, denn beide Zonen liegen bereits im selben Cloudflare-Netzwerk, die Übergabe passiert also innerhalb dieses Netzwerks statt draußen über das offene Internet. Wir haben das auf clawmart.digital, dem proxied Testshop, gegen rohe Shopify-Endpoints unter myshopify.com von derselben Maschine aus gemessen. Der proxied Shop antwortete an der Edge in ungefähr 150 bis 200 Millisekunden, im selben Bereich wie die nicht proxied Shopify-Endpoints daneben. Der zusätzliche Hop ging in der normalen Schwankung zwischen den Durchläufen unter.

Wenn sich ein proxied Shopify-Shop doch langsam anfühlt, liegt die Ursache fast immer an einem schweren Theme oder einer langsamen Drittanbieter-App, nicht am Proxy. Messen Sie, bevor Sie die Edge beschuldigen. Time to First Byte, mehrfach von einem Standort ausgeführt, ist der schnellste Anhaltspunkt:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://clawmart.digital/

Vergleichen Sie das mit einer Baseline bei grauer Wolke (DNS only), mit Ihrer Adresse unter myshopify.com oder mit einem WebPageTest-Lauf. Ein Unterschied von wenigen Millisekunden heißt, dass der Proxy nicht Ihr Engpass ist. Hunderte Millisekunden heißen, dass Theme und App-Stack es sind, und genau dort sollten Sie die Zeit investieren: das Theme abspecken, nicht mehr genutzte Apps entfernen und das Laden von Bildern reparieren bewegt die Zahl weit mehr als alles, was Sie an der Edge konfigurieren.

Apps im Checkout

Die zweite Frage ist der Checkout: Stört der Proxy Checkout-Extensibility-Apps, Zahlungen oder die Skripte, die im wichtigsten Schritt laufen? Konstruktionsbedingt sollte er das nicht. Cloudflares O2O-Routing deaktiviert Workers und Snippets gezielt auf dem Pfad /checkout, damit nichts, was Sie an der Edge laufen lassen, die Zahlung berühren kann. In unseren Tests hat sich keine der gängigen Checkout-Extensibility-Apps hinter diesem Setup danebenbenommen. Das ist unsere Erfahrung, keine Garantie für jede App am Markt, führen Sie also immer selbst einen vollständigen Checkout durch.

Geben Sie eine echte Bestellung auf, während Ihre Apps aktiv sind: Prüfen Sie, dass Rabatte, Versandlogik, Upsells und alle Post-Purchase-Extensions genauso auslösen wie ohne den Proxy und dass die Bestellung mit den erwarteten Attributen in Shopify landet. Wenn sich eine App danebenbenimmt, zeigt sich das hier, bei Ihrer Testbestellung, lange bevor ein Kunde ihr begegnet.

Funktionieren Ihre Shopify-Features weiterhin?

Das ist die Frage, die Händler stellen, kurz bevor sie zurückrudern: Verhalten sich die Dinge, die ich in Shopify verwalte, weiterhin so, wenn Cloudflare davor sitzt? Am meisten Unruhe stiften URL-Weiterleitungen, weil sie im Shopify-Admin verwaltet werden, für SEO zählen und nicht offensichtlich ist, ob ein Proxy davor sie cached, umschreibt oder verschluckt.

Also haben wir es auf dem proxied Shop getestet, statt darüber zu spekulieren. Wir haben im Shopify-Admin eine 301 von /pages/redirect-test-20260727 auf die Startseite angelegt, vorher bestätigt, dass der Pfad einen 404 lieferte, damit nichts Echtes betroffen war, sie aus mehreren Blickwinkeln geprüft und danach gelöscht.

Die Cloudflare-spezifische Antwort steht in dieser letzten Zeile. Cloudflare hat die Weiterleitungen direkt durchgereicht und nie gecached, Ihre Weiterleitungslogik bleibt also vollständig unter Shopifys Kontrolle. Das ist auch kein Zufall: Shopify sendet auf der 301 selbst cache-control: private, no-store, Cloudflare würde sie also selbst dann nicht cachen, wenn Sie es verlangen. Query-Strings überleben, die Apex-Domain funktioniert, und einfaches HTTP funktioniert.

Ein Detail aus dem Aufräumen ist es wert, gekannt zu werden, weil es wie ein Cloudflare-Problem aussieht und keines ist. Nachdem wir die Weiterleitung gelöscht hatten, lieferte die nackte URL noch rund dreißig Sekunden die alte 301, während eine Cache-Buster-Variante derselben URL bereits 404 zurückgab. Das war ein einzelner Shopify-Edge-Knoten, der eine veraltete Kopie hielt, nicht Cloudflare: cf-cache-status blieb durchgehend DYNAMIC, und die Query-String-Variante war sofort korrekt. Es hat sich von selbst erledigt. Warten Sie nach dem Ändern oder Entfernen einer Weiterleitung also eine Minute, bevor Sie schließen, dass es nicht funktioniert hat, und testen Sie im Zweifel mit einem Cache-Buster.

Das knüpft auch an die Caching-Einschränkung von vorhin an, und es schneidet in beide Richtungen. Mit ausgeschaltetem Edge-Caching wirken Änderungen an Weiterleitungen sofort, was ein unbeabsichtigter Vorteil ist. Wenn Sie später HTML-Caching an der Edge einschalten, können Weiterleitungen auch dort gecached werden, und Ihre Änderungen erscheinen nicht mehr sofort. Wenn Sie diesen Weg gehen, nehmen Sie Weiterleitungspfade von der Cache-Regel aus oder bauen Sie einen Purge-Schritt in das Werkzeug ein, mit dem Sie Weiterleitungen in großer Zahl verwalten.

Einrichten, bevor der Shop öffentlich ist

Sie brauchen keinen gestarteten Storefront, um all das zu konfigurieren und zu testen. Oft ist es klüger, das zu tun, solange der Shop noch privat ist, damit O2O-Erkennung, SSL-Bereitstellung und der Checkout-Test alle dort stattfinden, wo kein Kunde in ein halbfertiges Setup stolpern kann. Die einzige Voraussetzung ist ein kostenpflichtiger Shopify-Plan, denn eigene Domains sind in der kostenlosen Testphase nicht verfügbar. Sie müssen den Shop aber nicht starten: Ein bezahlter Plan hinter seiner Passwortseite reicht für die Einrichtung völlig. Wenn Sie einen kostenlosen Partner-Development-Store nutzen, der eigene Domains einschränkt, übertragen Sie ihn zuerst auf einen kostenpflichtigen Plan und folgen dann denselben Schritten.

Sollten Sie es also betreiben?

Machen Sie daraus statt einer Ja-oder-Nein-Frage eine Entscheidung darüber, was Sie an der Edge brauchen, denn nur das rechtfertigt den Tradeoff.

Die Shopify-Community-Nutzer Steve_TopNewYork und sophia24 sind im selben Thread beide bei diesem dritten Punkt gelandet, und er ist der Preis, den Händler unterschätzen. Der Proxy ist selten das, was kaputtgeht, aber sobald er im Pfad sitzt, ist er eine weitere Schicht, die Sie um zwei Uhr nachts ausschließen müssen, wenn der Checkout sich seltsam verhält und Sie noch nicht wissen, warum. Für ein kleines Team ist das eine echte Belastung, und sie lohnt sich nur für eine Funktion, die Sie benennen können.

Wenn Sie es betreiben, behandeln Sie die Checkliste als nicht verhandelbar: ein proxied CNAME auf shops.myshopify.com, bestätigen, dass das Shopify-Symbol erscheint, Always Use HTTPS aus lassen, den ACME-Pfad von Ihrer HTTPS-Weiterleitung ausnehmen und das Erneuerungsdatum des Zertifikats so prüfen, wie Sie prüfen würden, ob ein Backup tatsächlich gelaufen ist. So konfiguriert betreiben etliche Shops Cloudflare vor Shopify ohne Drama. Lassen Sie diese Schritte aus, und Sie haben genau die stille Störung eingerichtet, die die Warnung verhindern will.

Die Kurzfassung als Video: Field Notes: Cloudflare in front of Shopify zeigt, was O2O behoben hat und welche zwei Dinge ein Edge-Dienst Ihnen zeigt, die Shopify nicht zeigt.

Häufig gestellte Fragen

Ist es sicher, Cloudflare vor einen Shopify-Shop zu setzen?

Es ist deutlich tragfähiger als früher, aber Shopify unterstützt es nicht offiziell, es ist also eine kalkulierte Entscheidung und keine risikofreie. Das Routing-Problem, das früher Shops lahmgelegt hat, nämlich zwei kollidierende Cloudflare-Zonen, wurde durch Cloudflares Funktion Orange-to-Orange (O2O) gelöst. Korrekt konfiguriert, also mit einem proxied CNAME auf shops.myshopify.com, ohne Always Use HTTPS und mit dem ACME-Challenge-Pfad, der von jeder HTTPS-Weiterleitung ausgenommen ist, laufen viele Shops damit zuverlässig. Shopifys eigene Dokumentation stellt weiterhin fest, dass Cloudflare-Proxy-Setups einschließlich O2O nicht unterstützt werden und jederzeit brechen können, weil Shopify das Verhalten in einer Proxy-Schicht, die es nicht kontrolliert, nicht garantieren kann. Die ehrliche Zusammenfassung: technisch solide, wenn es richtig eingerichtet ist, offiziell nicht unterstützt, und am besten Shops vorbehalten, die an der Edge etwas brauchen, das Shopify nicht bietet.

Was ist Orange-to-Orange (O2O)?

Orange-to-Orange ist Cloudflares Routing-Funktion für den Fall, dass ein Cloudflare-Kunde seine proxied Domain auf einen Dienst zeigen lässt, der ebenfalls Cloudflare-Kunde ist. Cloudflares Proxy wird im Dashboard als orange Wolke dargestellt, zwei übereinanderliegende Cloudflare-Zonen sind also Orange-to-Orange. Shopify ist Cloudflare-for-SaaS-Kunde, ein Shopify-Shop ist damit genau dieser Fall. Vor O2O konnte Cloudflare nicht zuverlässig bestimmen, welche Zone den Request besitzen sollte, und die beiden kollidierten. O2O erkennt, dass das CNAME-Ziel einem anderen Cloudflare-Kunden gehört, und routet den Request zuerst durch Ihre Zone und danach durch die des Anbieters, in dieser Reihenfolge. Sie können bestätigen, dass es funktioniert, wenn ein kleines Shopify-Symbol neben dem CNAME-Eintrag in Ihrem Cloudflare-Dashboard erscheint.

Warum sagt Shopify, dass Cloudflare nicht unterstützt wird?

Shopifys Dokumentation nennt drei Hauptgründe. Zwei davon halten gut stand. Erstens SSL: Shopify stellt Zertifikate über Let’s Encrypt mit einer ACME-HTTP-Challenge aus und erneuert sie, und jeder Proxy davor ist eine weitere Instanz, die diese Validierung stören kann. Zweitens Incident Response: Wenn Shopifys eigene Infrastruktur ein Problem hat, erschweren zusätzliche Proxys vor dem Shop es Shopify, um das Problem herum umzuleiten, was das Ausfallrisiko eher erhöht als senkt. Der dritte Grund, Bot-Erkennung, ist schwächer: Shopify argumentiert, dass Traffic durch Cloudflare mit veränderten Request-Attributen ankommt, aber Cloudflare betreibt eines der größten Bot-Management-Netzwerke der Welt, die meisten Shops gewinnen an der Edge also mehr Bot-Filterung, als Shopify an Signal verliert. Keiner dieser Punkte bedeutet, dass das Setup nicht funktionieren kann. Sie bedeuten, dass Shopify keine Verantwortung für das Verhalten in einer Schicht übernimmt, die ihm nicht gehört.

Warum scheitert mein Shopify-SSL-Zertifikat hinter Cloudflare?

Fast immer wegen der Einstellung Always Use HTTPS. Shopify validiert den Domain-Besitz und erneuert SSL-Zertifikate, indem es eine Challenge unter dem Pfad /.well-known/acme-challenge/ beantwortet. Always Use HTTPS erzwingt bei jedem Request eine Umleitung, auch auf diesem Pfad, die Challenge wird also nie abgeschlossen und das Zertifikat kann weder ausgestellt noch erneuert werden. Der Shop läuft mit dem vorhandenen Zertifikat weiter, bis es abläuft, danach wird die Domain unsicher oder nimmt keine Verbindung mehr an. Die von Cloudflare dokumentierte Lösung: Always Use HTTPS ausgeschaltet lassen und stattdessen eine Redirect-Regel anlegen, die HTTPS für alles außer dem Pfad /.well-known/acme-challenge/ erzwingt.

Muss ich mir eine Kalendererinnerung setzen, um die SSL-Erneuerung zu prüfen, damit mein Shop nicht ausfällt?

Nein, nicht wenn es korrekt konfiguriert ist. Die Erneuerung ist darauf ausgelegt, von selbst zu laufen. Das Zertifikat, das Ihre Besucher tatsächlich sehen, ist Cloudflares eigenes Edge-Zertifikat, das Cloudflare über DNS validiert und automatisch erneuert, es hängt also überhaupt nicht am ACME-Challenge-Pfad. Dahinter erneuert sich Shopifys Origin-Zertifikat im Hintergrund über Let’s Encrypt, und das funktioniert weiter, solange Always Use HTTPS aus ist und der Pfad /.well-known/acme-challenge/ nicht umgeleitet wird. Führen Sie nach der Einrichtung einmalig den curl-Test aus, um zu bestätigen, dass dieser Pfad einen 404 und keine Umleitung zurückgibt, dann hat die automatische Erneuerung alles, was sie braucht. Wenn Sie ein Sicherheitsnetz wollen, ist das richtige Werkzeug keine manuelle Kalendererinnerung, auf die Sie reagieren müssen, sondern ein automatisierter SSL-Ablaufmonitor, der Ihnen eine E-Mail schickt, falls das Zertifikat je in die Nähe von zwei Wochen vor Ablauf gerät. So hängt nichts daran, dass Sie sich an einen Jahrestag erinnern.

Woran würde ich ein Zertifikatsproblem erkennen, bevor es den Shop lahmlegt?

Richten Sie Monitoring ein, damit man es Ihnen sagt, statt dass Sie es von einem Kunden erfahren. Ein kostenloser SSL- und Uptime-Monitor wie UptimeRobot, Better Uptime oder ein vergleichbarer Dienst kann die Domain beobachten und Sie Tage vor Ablauf eines Zertifikats alarmieren oder in dem Moment, in dem HTTPS zu scheitern beginnt. Cloudflare selbst kann im Bereich Notifications des Dashboards ebenfalls Benachrichtigungen zu Zertifikats- und Origin-Problemen verschicken. Mit einem von beiden hört das stille Scheitern der Erneuerung, das einzige echte Risiko dieses Setups, auf, still zu sein: Sie bekommen eine E-Mail mit Wochen Vorlauf, lange bevor das Schloss für Käufer bricht.

Funktionieren Shopify-URL-Weiterleitungen hinter einem Cloudflare-Proxy weiterhin?

Ja. Wir haben das auf einem proxied Shop von Anfang bis Ende getestet: Eine im Shopify-Admin angelegte 301 war sofort live, ohne Wartezeit für die Propagierung, lieferte den korrekten 301 und den korrekten Location-Header, führte in einem Hop zu einem 200 am Ziel, erhielt Query-Strings wie ?utm_source=test und funktionierte von der Apex-Domain und über einfaches HTTP. Cloudflare hat die Weiterleitung direkt durchgereicht und nie gecached und meldete bei jedem Request cf-cache-status: DYNAMIC, Ihre Weiterleitungslogik bleibt also vollständig unter Shopifys Kontrolle. Shopify sendet auf der 301 selbst außerdem cache-control: private, no-store, Cloudflare würde sie also selbst dann nicht cachen, wenn Sie es so konfigurieren. Eine Einschränkung: Nach dem Ändern oder Löschen einer Weiterleitung kann ein Shopify-Edge-Knoten rund dreißig Sekunden lang eine veraltete Kopie ausliefern, warten Sie also eine Minute und testen Sie mit einem Cache-Buster, bevor Sie schließen, dass es nicht funktioniert hat. Wenn Sie später HTML-Caching an der Cloudflare-Edge aktivieren, nehmen Sie Weiterleitungspfade aus oder ergänzen Sie einen Purge-Schritt, denn Weiterleitungen können auch dort gecached werden.

Kann ich Cloudflare für einen Shopify-Shop einrichten, der noch nicht öffentlich ist?

Ja, und oft ist das der clevere Weg. Sie brauchen keinen gestarteten Storefront, nur einen kostenpflichtigen Shopify-Plan, denn eigene Domains sind in der kostenlosen Testphase nicht verfügbar. Halten Sie den Shop hinter seiner Passwortseite unter Online Store und dann Preferences, legen Sie in Cloudflare denselben proxied CNAME auf shops.myshopify.com an, mit einem Host, den Sie nicht produktiv ausliefern, etwa einer Staging-Subdomain, und verbinden Sie diesen Host in Shopify unter Settings und dann Domains. Shopify stellt SSL bereit und das Cloudflare-Dashboard zeigt das Shopify-Symbol, sobald Orange-to-Orange greift, während die Öffentlichkeit nur die Passwortseite sieht. Führen Sie den ACME-curl-Test und einen vollständigen Test-Checkout mit aktiven Apps durch, und wenn alles besteht, entfernen Sie das Passwort und setzen Ihre echte Domain als primär. Sie starten auf einer Konfiguration, die Sie bereits bewiesen haben. Wenn Sie einen kostenlosen Partner-Development-Store nutzen, der eigene Domains einschränkt, übertragen Sie ihn zuerst auf einen kostenpflichtigen Plan.