Het is nu veiliger om Cloudflare voor Shopify te zetten: wat O2O oploste en wat de waarschuwingen nog betekenen.

Snelstart: doe dit op je winkel

Kom je voor de stappen, hier zijn ze. De hele opzet bestaat uit een geproxyde CNAME in Cloudflare, hetzelfde domein gekoppeld in Shopify, en één HTTPS-schakelaar waar je vanaf blijft. De rest van dit artikel legt uit waarom elke stap ertoe doet en hoe je bevestigt dat het klopt, maar dit is de volledige configuratie.

Liever kijken: Field Notes: Cloudflare in front of Shopify behandelt hetzelfde in drie minuten, met een volledig transcript op de pagina.

Stap 1 in het Cloudflare-dashboard: beide records zijn CNAME's naar shops.myshopify.com met Proxy status Proxied.

De clawmart.digital-waarden die in dit artikel worden getoond, komen uit een echte testwinkel die we draaien op een volledig werkende Shopify-instantie, niet uit een mockup. Elke screenshot, elk record en elke test hieronder komt uit die winkel.

De waarschuwing op een werkende winkel

Je Shopify-domein staat als verbonden, de checkout werkt en het SSL-slotje is er. Direct onder die groene status staat een amberkleurige waarschuwing dat je domein een Cloudflare-proxy heeft, die Shopify niet ondersteunt. Beide zijn tegelijk waar, en op die tegenstelling lopen de meeste merchants vast.

Dit is een van de meest verwarrende meldingen in ecommerce-infrastructuur, want ze is niet fout en ook niet helemaal juist. Jarenlang was Cloudflare voor Shopify zetten een werkelijk slecht idee dat winkels op een specifieke, voorspelbare manier brak. Toen bracht Cloudflare een routeringsfunctie uit die precies dat probleem oploste, en toch zegt Shopify nog steeds dat je het niet moet doen. In dat gat, tussen een oplossing die werkt en een leverancier die haar niet wil onderschrijven, zit de zorg of je winkel op het punt staat stuk te gaan.

Dit is dus de praktische versie: wat er werkelijk brak, wat O2O oploste, de ene instelling die je site nog steeds plat kan leggen als je die mist, en hoe je beslist of iets hiervan op jouw winkel thuishoort.

Waarom het vroeger stukging: twee oranje wolken

Cloudflare toont een geproxyd domein als een oranje wolk. Verkeer naar dat domein loopt via het netwerk van Cloudflare voordat het je origin bereikt. Het addertje bij Shopify is dat Shopify zelf op Cloudflare draait. Wijs je dus je oranje bewolkte domein naar Shopify, dan komt het verzoek bij Cloudflare aan met twee zones die er allebei aanspraak op maken: die van jou en die van Shopify. Twee oranje wolken, op elkaar gestapeld.

Van oudsher kon Cloudflare niet betrouwbaar bepalen welke zone dat verzoek moest krijgen, waardoor het naar de verkeerde plek werd opgelost of in een lus belandde. Het resultaat was een winkel die half werkte en faalde op manieren die lastig te reproduceren waren.

De scherpste rand was SSL. Shopify levert en vernieuwt je certificaat via Let's Encrypt, en Let's Encrypt bewijst dat het domein van jou is met een ACME-challenge op een specifiek pad:

Als een proxy vóór Shopify dat pad onderschept, cachet of omleidt, wordt de challenge nooit afgerond. Geen afgeronde challenge betekent geen certificaat. En omdat certificaten volgens een schema vernieuwen, mislukte dit vaak stilletjes: de winkel werkte wekenlang prima op het bestaande certificaat en werd onveilig op de dag dat het verliep. Daarom was het oude advies één botte regel: zet de wolk grijs, DNS only, haal de proxy van Cloudflare uit het pad.

Wat Orange-to-Orange veranderde

Orange-to-Orange, of O2O, is het antwoord van Cloudflare op het probleem met twee zones, en het is onderdeel van een product dat Cloudflare for SaaS heet. Cloudflare stelde dat product in 2021 open voor elke klant, algemeen beschikbaar vanaf die oktober, dus O2O is een uitgekristalliseerd routeringspad met jaren ervaring erachter, geen recent experiment. Het mechanisme is rechttoe rechtaan: wijst je geproxyde zone een CNAME naar een dienst die ook klant is van Cloudflare for SaaS, dan herkent Cloudflare het doel en behandelt het de twee zones niet langer als een botsing. Het stuurt het verzoek eerst door jouw zone en daarna door die van de provider, in een vastgelegde volgorde, en de dubbele proxy wordt een overdracht.

Je hoeft niet op goed geloof aan te nemen dat O2O is aangeslagen. Maak de CNAME aan met de proxy aan, en Cloudflare zet een klein Shopify-icoon naast het record. Dat icoon is de detectie die bevestigt dat Cloudflare weet waar het verkeer heen gaat. Cloudflare doet op de achtergrond ook provider-specifiek huishoudelijk werk, waaronder het uitschakelen van Workers en Snippets op het /checkout-pad, zodat niets wat jij aan de edge draait de betaling kan verstoren.

Je voegt dat record toe in het Cloudflare-dashboard onder DNS en daarna Records. Klik op Add record, zet Type op CNAME, Target op shops.myshopify.com en Proxy status op Proxied zodat de wolk oranje wordt. Het Shopify-icoon verschijnt naast het record zodra Cloudflare het doel herkent als een van zijn eigen SaaS-klanten.

De ene uitzondering aanpakken: SSL

O2O loste de routeringsbotsing op. Het loste SSL niet op, want SSL was nooit echt een routeringsprobleem. Het was een proxy die het ene pad raakte dat Shopify gebruikt om certificaten te vernieuwen. Op een correct ingerichte winkel loopt bijna alles hiervan nu vanzelf, dus het nuttige is om te weten wat automatisch gaat en daarna het korte lijstje na te lopen dat dat niet is.

Wat er nu automatisch gebeurt

Je winkel draagt twee certificaten, en beide vernieuwen zonder jou. Omdat het domein geproxyd is, is het certificaat dat bezoekers zien het edge-certificaat van Cloudflare zelf, dat Cloudflare via DNS valideert en zelfstandig vernieuwt, waardoor het ACME-pad er nooit aan te pas komt. Daarachter houdt Shopify een apart origin-certificaat aan voor het traject van Cloudflare naar Shopify, vernieuwd via Let's Encrypt, en je Full-encryptiemodus is erop gebouwd dat te vertrouwen. Shopify voert de upgrade van HTTP naar HTTPS ook uit op zijn eigen origin, dus bezoekers landen op een beveiligde verbinding, of Cloudflare nu een vinger uitsteekt of niet.

Dat origin-certificaat vernieuwt via ACME, de geautomatiseerde uitwisseling waarmee Let's Encrypt bevestigt dat jij het domein beheert. Het vraagt aan wat er ook voor jouw domein antwoordt om een eenmalig token op het pad hierboven te serveren, over gewoon HTTP, en Shopify handelt die hele uitwisseling op de achtergrond af. Daarom denk je er nooit aan. De opzet blijft precies zo lang gezond als dat ene pad bereikbaar blijft.

Het enige dat het breekt

Al die automatische vernieuwing rust op één Cloudflare-instelling die uit moet blijven, en die staat in genoeg opstellingen standaard aan.

De oplossing is dus grotendeels een kwestie van die schakelaar niet aanzetten, en de origin-redirect van Shopify de upgrade laten doen die hij toch al uitvoert. Wil je dat Cloudflare HTTPS ook op zijn eigen edge afdwingt, gebruik dan een redirectregel die het challengepad overslaat, nooit Always Use HTTPS.

Wat je even moet nalopen

Alles hieronder zit in het Cloudflare-dashboard. Log in op dash.cloudflare.com, kies je account en klik op het domein om de zone te openen. Elk item is een pad in de linkerzijbalk van die zone.

Eén buurman op die pagina Edge Certificates zorgt voor verwarring: Automatic HTTPS Rewrites mag gerust aan blijven. Die herschrijft alleen http-resourcelinks naar https om waarschuwingen over gemengde content te voorkomen, wat iets heel anders is dan Always Use HTTPS die een volledige paginaredirect forceert. Opportunistic Encryption en TLS 1.3 kunnen ook aan blijven. Always Use HTTPS is de enige schakelaar op dat scherm die uit moet blijven.

Bevestig het daarna van buitenaf, zonder te wachten tot een vernieuwing mislukt. Vraag het challengepad op over gewoon HTTP en lees het antwoord:

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

Shopify bereiken is de winst, en een 404 voor het verzonnen token is precies goed. Een redirect met 301 of 308 naar HTTPS betekent dat Always Use HTTPS of een allesomvattende regel het pad nog steeds opslokt. Controleer daarna de SSL-status onder Settings → Domains in je Shopify-admin, en kijk de weken erna of de vervaldatum van het origin-certificaat vanzelf opschuift. Een certificaat dat ongemoeid vernieuwt is het signaal dat de opzet standhoudt.

Voer die test opnieuw uit na elke wijziging in je DNS- of Cloudflare-instellingen, niet alleen bij het inrichten. Shopify Community-gebruiker Hardeep bracht dit ter sprake in de thread over dit artikel, en het komt overeen met hoe deze opstellingen in de praktijk falen. De configuratie klopte op dag één, maanden later paste iemand een regel of een record aan, en niemand controleerde het challengepad opnieuw tot een certificaat stilletjes niet vernieuwde.

Eén valkuil is het waard om helder te benoemen: een certificaat dat vandaag als geleverd staat, vertelt je dat het huidige is uitgegeven, niet dat de volgende vernieuwing ook lukt. Certificaten van Let's Encrypt vernieuwen in een cyclus van ruwweg zestig tot negentig dagen, dus een winkel die volledig gezond lijkt kan er simpelweg een zijn die zijn vernieuwingsdatum nog niet heeft bereikt. Dat, plus het feit dat veel winkels Always Use HTTPS nooit hebben aangezet, is waarom er zoveel maandenlang zonder problemen op draaien, en waarom de storing verwarrend is als ze komt. Er veranderde niets, behalve een certificaat dat stilletjes niet vernieuwde.

Geef het het juiste gewicht. Dit is goedkope verzekering tegen een zeldzame maar stille storing, geen teken dat je winkel op het punt staat stuk te gaan. Doe de configuratie van twee minuten, voer de test uit, en je hebt het ene gat rond de vernieuwing gedicht dat echt moeilijk op te merken is.

Shopify geeft hier nog steeds geen groen licht voor, en wel hierom…

De documentatie van Shopify doet niet langer vaag over "proxy's" in het algemeen. Ze noemt O2O expliciet:

"Cloudflare proxy setups, including O2O, aren't supported by Shopify. Although your store might appear to function correctly, this setup could break at any time."

Dat is geen verouderde waarschuwing over een opgelost probleem. Het is een actueel, bewust standpunt, en twee van de redenen erachter houden ook na O2O stand:

De documentatie van Shopify voegt een derde reden toe, botdetectie, met het argument dat verkeer via Cloudflare bij hen aankomt met gewijzigde requestattributen. In de praktijk is dat de zwakste van de drie: Cloudflare draait een van de grootste botmanagementnetwerken die er zijn, dus de meeste winkels winnen aan de edge veel meer botfiltering dan Shopify aan signaal verliest. Het is het enige punt op de lijst van Shopify waar de proxy eerder helpt dan schaadt.

Is de waarschuwing overdreven?

Een beetje wel, en dat is begrijpelijk. Het dashboard markeert een werkende, verbonden winkel met een amberkleurige "Issue" en de kale zin "not supported", en dat komt harder binnen dan de werkelijke faalscenario's, die grotendeels te vermijden zijn met een correcte configuratie. Een merchant leest "Issue" en hoort "je winkel staat op het punt stuk te gaan", terwijl Shopify eerder bedoelt "wij staan hier niet voor in".

Maar "niet ondersteund" is niet "werkt niet", en dat onderscheid doet ertoe. Het betekent dat Shopify gedrag in een laag die zij niet beheren niet garandeert, debugt of er verantwoordelijkheid voor neemt. Voor een platform dat je checkout en je uptime in handen heeft is dat een redelijke grens, ook al trekt de banner hem bot. De melding zegt je dat Shopify niet achter de opzet gaat staan. Ze zegt niet dat de opzet faalt.

Er draaien veel Shopify-winkels op deze opzet

Je hoeft niet af te gaan op het woord van één testwinkel. Een Cloudflare-proxy voor Shopify is geen randverschijnsel: talloze gevestigde merken draaien het elke dag in productie. De namen hieronder zijn live voorbeelden die we met de hand hebben geverifieerd, elk daarvan serveert zijn storefront momenteel via een Cloudflare-proxy met Shopify erachter.

Geverifieerd in juli 2026 door elk domein op te vragen en een Cloudflare-proxyrespons te bevestigen samen met Shopify-storefrontkenmerken. De opzet van een winkel kan op elk moment veranderen, dus beschouw dit als een momentopname en niet als een aanbeveling door de genoemde merken.

Wat de edge je oplevert wat Shopify niet biedt

Shopify levert op elk abonnement al een CDN, SSL-certificaten en DDoS-bescherming, zoals Hardeep ook opmerkte in de community-thread. De proxy is niet wat je winkel snel, versleuteld of bestand tegen een vloedgolf maakt, en als je daarvoor kwam, heb je het al. Wat volgt is de smallere set dingen die Shopify je niet geeft.

De reden om de afweging te accepteren is niet de proxy zelf. Het is de laag die de proxy voor je winkel zet, een programmeerbare edge die Shopify niet aan jou blootstelt. Drie mogelijkheden doen er het meest toe, en de derde krijgen de meeste winkels helemaal nooit te zien.

Niets daarvan zit in een Shopify-abonnement, want niets daarvan leeft binnen Shopify. Het leeft één hop eerder, aan de edge, en dat is de hele reden waarom een merchant een niet-ondersteunde proxy zou accepteren.

Eén kanttekening: edge-caching gaat niet vanzelf. Cloudflare kan statische bestanden zoals stylesheets en afbeeldingen aan zijn edge bewaren en ze vanaf een nabije server serveren in plaats van ze bij elk bezoek bij Shopify op te halen, maar een geproxyde Shopify-winkel cachet niet uit zichzelf, en een standaard of verkeerd afgebakende cacheregel kan het volledig onderdrukken, waardoor bestanden die als een jaar cachebaar zijn gemarkeerd ongemoeid worden doorgelaten. Het netwerk van Shopify zelf houdt de storefront hoe dan ook snel, dus behandel edge-caching als een snelheidsbonus waarvoor je kiest. De encryptiemodus die de oude SSL-problemen voorkomt bevestig je in de SSL/TLS-configuraties, hetzelfde scherm als de eerder besproken knop Configure; caching stel je in een eigen onderdeel in, dus het loont beide te controleren zolang je toch in het dashboard zit, omdat caching de instelling is die het meest waarschijnlijk snelheid laat liggen.

Waar een developer je voor zal waarschuwen

Een goede developer laat dit niet zonder vragen passeren, en die vragen zijn terecht. Geen ervan is een reden om de opzet te vermijden, maar elk is het waard om op je eigen winkel te bevestigen in plaats van op goed geloof aan te nemen. Dat is geen extra werk: het is dezelfde toetsing die je na elke infrastructuurwijziging zou uitvoeren, en het hoort bij het gezond houden van een winkel. Wij testen beide punten hieronder op de winkel die we draaien, en jij zou dat ook moeten doen.

Latency bij de overdracht

De eerste vraag is snelheid: kost routeren via jouw Cloudflare-zone vóór de zone van Shopify merkbaar tijd? Dat zou niet moeten, want beide zones zitten al op hetzelfde Cloudflare-netwerk, dus de overdracht gebeurt binnen dat netwerk en niet over het open internet. We hebben het gemeten op clawmart.digital, de geproxyde testwinkel, tegenover kale Shopify-myshopify.com-endpoints vanaf dezelfde machine. De geproxyde winkel antwoordde aan de edge in ruwweg 150 tot 200 milliseconden, dezelfde band als de niet-geproxyde Shopify-endpoints ernaast. De extra hop verdween in de normale variatie tussen metingen.

Als een geproxyde Shopify-winkel wél traag aanvoelt, is de oorzaak vrijwel altijd een zwaar thema of een trage app van derden, niet de proxy. Meet voordat je de edge de schuld geeft. Time to first byte, meerdere keren uitgevoerd vanaf één locatie, is de snelste peiling:

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

Vergelijk dat met een grijze-wolk-basislijn (DNS only), of met je myshopify.com-adres, of met een run in WebPageTest. Een paar milliseconden verschil betekent dat de proxy je knelpunt niet is. Honderden milliseconden betekent dat het thema en de app-stack dat wel zijn, en daar moet je je tijd in steken: het thema uitdunnen, apps schrappen die je niet meer gebruikt en het laden van afbeeldingen verbeteren verzetten het getal veel meer dan wat je ook aan de edge configureert.

Apps in de checkout

De tweede vraag is de checkout: gaat de proxy checkout-extensibility-apps, betalingen of de scripts die bij de belangrijkste stap draaien in de weg zitten? Van opzet uit zou dat niet moeten. De O2O-routing van Cloudflare schakelt Workers en Snippets uit op specifiek het /checkout-pad, zodat niets wat jij aan de edge draait de betaling kan raken. In onze tests heeft geen van de populaire checkout-extensibility-apps zich achter deze opzet misdragen. Dat is onze ervaring, geen garantie voor elke app op de markt, dus voer altijd zelf een volledige checkout uit.

Zet een echte bestelling door met je apps live: bevestig dat kortingen, verzendlogica, upsells en eventuele post-purchase-extensies precies zo afgaan als zonder de proxy, en dat de bestelling in Shopify landt met de attributen die je verwacht. Als een app zich gaat misdragen, komt dat hier naar boven, bij je testbestelling, ruim voordat een klant het ooit tegenkomt.

Blijven je Shopify-functies werken?

Dit is de vraag die merchants stellen vlak voordat ze afhaken: als Cloudflare ervoor zit, gedragen de dingen die ik binnen Shopify beheer zich dan nog? Wat de meeste onrust geeft zijn URL-redirects, omdat ze in de Shopify-admin worden beheerd, ze voor SEO belangrijk zijn en het niet vanzelfsprekend is of een proxy ervoor ze cachet, herschrijft of opslokt.

Dus hebben we het getest op de geproxyde winkel in plaats van erover te redeneren. We maakten in de Shopify-admin een 301 aan van /pages/redirect-test-20260727 naar de homepage, bevestigden vooraf dat het pad een 404 gaf zodat niets echts werd geraakt, controleerden het vanuit meerdere invalshoeken en verwijderden het weer.

Het Cloudflare-specifieke antwoord staat in die laatste rij. Het liet de redirects ongewijzigd door en cachete ze nooit, dus je redirectlogica blijft volledig onder de controle van Shopify. Dat is ook geen toeval: Shopify stuurt cache-control: private, no-store mee op de 301 zelf, dus Cloudflare zou hem niet cachen, zelfs niet als je erom vroeg. Querystrings overleven, het apex-domein werkt, en gewoon HTTP werkt.

Eén detail uit het opruimen is het weten waard, omdat het op een Cloudflare-probleem lijkt en dat niet is. Nadat we de redirect hadden verwijderd, bleef de kale URL nog ongeveer dertig seconden de oude 301 serveren terwijl een cache-busted versie van dezelfde URL al 404 teruggaf. Dat was één Shopify edge-node die een verouderde kopie vasthield, niet Cloudflare: cf-cache-status bleef de hele tijd DYNAMIC en de variant met querystring was meteen correct. Het loste zichzelf op. Geef het dus na het wijzigen of verwijderen van een redirect een minuut voordat je concludeert dat het niet werkte, en test met een cache-buster als je twijfelt.

Dit sluit ook aan op de eerdere kanttekening over caching, en het snijdt twee kanten op. Met edge-caching uit werken redirectwijzigingen direct door, wat een onbedoeld voordeel is. Zet je later HTML-caching aan op de edge, dan kunnen redirects daar ook gecachet worden en verschijnen je aanpassingen niet meer meteen. Ga je die kant op, sluit dan redirectpaden uit van de cacheregel of bouw een purge-stap in de tooling waarmee je redirects in bulk beheert.

De opzet inrichten voordat de winkel openbaar is

Je hebt geen gelanceerde storefront nodig om dit alles in te richten en te testen. Vaak is het slimmer om het te doen terwijl de winkel nog privé is, zodat O2O-detectie, SSL-levering en de checkouttest allemaal gebeuren waar geen klant in een halfafgemaakte opzet kan belanden. De enige vereiste is een betaald Shopify-abonnement, omdat eigen domeinen niet beschikbaar zijn tijdens een gratis proefperiode. Je hoeft de winkel echter niet te lanceren: een betaald abonnement achter de wachtwoordpagina is alles wat de opzet nodig heeft. Zit je op een gratis Partner development store, waar eigen domeinen beperkt zijn, zet die dan eerst om naar een betaald abonnement en volg daarna dezelfde stappen.

Moet je het dan draaien?

Maak er van een ja-of-nee een beslissing over wat je aan de edge nodig hebt, want dat is het enige dat de afweging rechtvaardigt.

Shopify Community-gebruikers Steve_TopNewYork en sophia24 kwamen in dezelfde thread allebei op die derde reden uit, en dat is de kostenpost die merchants onderschatten. De proxy is zelden het onderdeel dat stukgaat, maar zodra hij in het pad zit is het één laag extra die je om twee uur 's nachts moet uitsluiten wanneer de checkout zich misdraagt en je nog niet weet waarom. Dat is een reële belasting voor een klein team, en die betaal je alleen voor een functie die je kunt benoemen.

Draai je het toch, behandel de checklist dan als niet-onderhandelbaar: een geproxyde CNAME naar shops.myshopify.com, bevestig dat het Shopify-icoon verschijnt, laat Always Use HTTPS uit, sluit het ACME-pad uit van je HTTPS-redirect, en controleer de vernieuwingsdatum van het certificaat zoals je zou controleren of een back-up echt is gelopen. Zo geconfigureerd draaien er volop winkels zonder problemen met Cloudflare voor Shopify. Sla die stappen over, en je hebt precies de stille storing opgezet die de waarschuwing probeert te voorkomen.

De korte versie, op video: Field Notes: Cloudflare in front of Shopify loopt door wat O2O oploste en de twee dingen die een edge-dienst je laat zien die Shopify niet toont.

Veelgestelde vragen

Is het veilig om Cloudflare voor een Shopify-winkel te zetten?

Het is een stuk haalbaarder dan vroeger, maar Shopify ondersteunt het niet officieel, dus het is een berekende keuze en geen risicovrije. Het routeringsprobleem waar winkels vroeger op stukliepen, twee botsende Cloudflare-zones, is opgelost door de Orange-to-Orange-functie (O2O) van Cloudflare. Correct geconfigureerd, dus met een geproxyde CNAME naar shops.myshopify.com, zonder Always Use HTTPS, en met het ACME-challengepad uitgesloten van elke HTTPS-redirect, draaien veel winkels er betrouwbaar op. De documentatie van Shopify zelf stelt nog altijd dat Cloudflare-proxyopstellingen inclusief O2O niet worden ondersteund en op elk moment kunnen breken, omdat zij het gedrag in een proxylaag die zij niet beheren niet kunnen garanderen. De eerlijke samenvatting: technisch degelijk als het goed staat, officieel niet ondersteund, en het best bewaard voor winkels die iets aan de edge nodig hebben wat Shopify niet levert.

Wat is Orange-to-Orange (O2O)?

Orange-to-Orange is de routeringsfunctie van Cloudflare voor het geval dat een Cloudflare-klant zijn geproxyde domein naar een dienst wijst die zelf ook Cloudflare-klant is. De proxy van Cloudflare wordt in het dashboard getoond als een oranje wolk, dus twee gestapelde Cloudflare-zones zijn orange-to-orange. Shopify is klant van Cloudflare for SaaS, dus een Shopify-winkel is precies dit geval. Vóór O2O kon Cloudflare niet betrouwbaar bepalen welke zone het verzoek moest krijgen en botsten de twee. O2O detecteert dat het CNAME-doel bij een andere Cloudflare-klant hoort en routeert het verzoek eerst door jouw zone en daarna door die van de provider, op volgorde. Je ziet dat het werkt zodra er een klein Shopify-icoon naast het CNAME-record in je Cloudflare-dashboard verschijnt.

Waarom zegt Shopify dat Cloudflare niet wordt ondersteund?

De documentatie van Shopify geeft drie hoofdredenen. Twee daarvan houden goed stand. Ten eerste SSL: Shopify geeft certificaten uit en vernieuwt ze via Let’s Encrypt met een ACME HTTP-challenge, en elke proxy ervoor is nog iets extra’s dat die validatie kan verstoren. Ten tweede incidentafhandeling: als de infrastructuur van Shopify zelf een probleem heeft, maken extra proxy’s voor de winkel het voor Shopify moeilijker om eromheen te routeren, wat je blootstelling aan storingen eerder vergroot dan verkleint. De derde, botdetectie, is zwakker: Shopify stelt dat verkeer via Cloudflare aankomt met gewijzigde requestattributen, maar Cloudflare draait een van de grootste botmanagementnetwerken ter wereld, dus de meeste winkels winnen aan de edge meer botfiltering dan Shopify aan signaal verliest. Geen van deze punten betekent dat de opzet niet kan werken. Ze betekenen dat Shopify geen verantwoordelijkheid neemt voor gedrag in een laag die zij niet bezitten.

Waarom mislukt mijn Shopify SSL-certificaat achter Cloudflare?

Vrijwel altijd door de instelling Always Use HTTPS. Shopify valideert domeineigendom en vernieuwt SSL-certificaten door een challenge te beantwoorden op het pad /.well-known/acme-challenge/. Always Use HTTPS forceert een redirect bij elk verzoek, inclusief dat pad, waardoor de challenge nooit wordt afgerond en het certificaat niet kan worden uitgegeven of vernieuwd. De winkel blijft werken op het bestaande certificaat tot het verloopt, waarna het domein onveilig wordt of geen verbinding meer maakt. De oplossing die Cloudflare documenteert is Always Use HTTPS uit laten en in plaats daarvan een redirectregel maken die HTTPS afdwingt voor alles behalve het pad /.well-known/acme-challenge/.

Moet ik een agenda-herinnering zetten om de SSL-vernieuwing te controleren zodat mijn winkel niet stukgaat?

Nee, niet als het correct is geconfigureerd. De vernieuwing is ontworpen om vanzelf te lopen. Het certificaat dat je bezoekers daadwerkelijk zien is het edge-certificaat van Cloudflare zelf, dat Cloudflare via DNS valideert en automatisch vernieuwt, dus dat hangt helemaal niet af van het ACME-challengepad. Daarachter vernieuwt het origin-certificaat van Shopify op de achtergrond via Let’s Encrypt, en dat blijft werken zolang Always Use HTTPS uit staat en het pad /.well-known/acme-challenge/ niet wordt omgeleid. Voer na de installatie de eenmalige curl-test uit om te bevestigen dat dat pad een 404 teruggeeft en geen redirect, en dan heeft de automatische vernieuwing alles wat ze nodig heeft. Wil je een vangnet, dan is het juiste middel geen handmatige agenda-herinnering waar jij op moet handelen, maar een geautomatiseerde SSL-vervalmonitor die je mailt als het certificaat ooit binnen een paar weken van vervallen komt. Zo hangt er niets af van jouw geheugen voor een jaardatum.

Hoe kom ik erachter voordat een certificaatprobleem de winkel platlegt?

Zet monitoring op zodat je het te horen krijgt in plaats van het van een klant te vernemen. Een gratis SSL- en uptimemonitor zoals UptimeRobot, Better Uptime of een vergelijkbare dienst kan het domein bewaken en je dagen voordat een certificaat verloopt waarschuwen, of op het moment dat HTTPS begint te falen. Cloudflare zelf kan ook meldingen sturen over certificaat- en originproblemen vanuit het onderdeel Notifications in het dashboard. Met een van beide is de stille vernieuwingsfout die het enige echte risico van deze opzet vormt niet langer stil: je krijgt een e-mail met weken speling, ruim voordat het slotje het voor shoppers begeeft.

Werken Shopify URL-redirects nog achter een Cloudflare-proxy?

Ja. We hebben dit van begin tot eind getest op een geproxyde winkel: een 301 die in de Shopify-admin werd aangemaakt ging direct live zonder wachttijd voor propagatie, gaf de juiste 301 en location-header terug, liep in één hop door naar een 200 op de bestemming, behield querystrings zoals ?utm_source=test, en werkte vanaf het apex-domein en over gewoon HTTP. Cloudflare liet de redirect ongewijzigd door en cachete hem nooit, met cf-cache-status: DYNAMIC bij elk verzoek, dus je redirectlogica blijft volledig onder de controle van Shopify. Shopify stuurt bovendien cache-control: private, no-store mee op de 301 zelf, dus Cloudflare zou hem niet cachen, zelfs niet als je dat instelde. Eén kanttekening: na het wijzigen of verwijderen van een redirect kan een Shopify edge-node ongeveer dertig seconden een verouderde kopie blijven serveren, dus geef het een minuut en test met een cache-buster voordat je concludeert dat het niet werkte. Zet je later HTML-caching aan op de Cloudflare-edge, sluit dan redirectpaden uit of bouw een purge-stap in, want redirects kunnen daar ook gecachet worden.

Kan ik Cloudflare instellen op een Shopify-winkel die nog niet openbaar is?

Ja, en vaak is dat de slimme aanpak. Je hebt geen gelanceerde storefront nodig, alleen een betaald Shopify-abonnement, omdat eigen domeinen niet beschikbaar zijn tijdens een gratis proefperiode. Houd de winkel achter de wachtwoordpagina onder Online Store en dan Preferences, maak in Cloudflare dezelfde geproxyde CNAME naar shops.myshopify.com met een host die je niet in productie gebruikt, bijvoorbeeld een staging-subdomein, en koppel die host in Shopify onder Settings en dan Domains. Shopify levert SSL en het Cloudflare-dashboard toont het Shopify-icoon zodra Orange-to-Orange aanslaat, terwijl het publiek alleen de wachtwoordpagina ziet. Voer de ACME curl-test uit en doe een volledige testcheckout met je apps live, en verwijder als alles slaagt het wachtwoord en stel je echte domein in als primair. Je lanceert dan op een configuratie die je al hebt bewezen. Zit je op een gratis Partner development store, waar eigen domeinen beperkt zijn, zet die dan eerst om naar een betaald abonnement.