Ora è più sicuro mettere Cloudflare davanti a Shopify: cosa ha risolto O2O e cosa significano ancora gli avvisi.

Avvio rapido: cosa fare sul tuo negozio

Se sei qui per i passaggi, eccoli. Tutta la configurazione si riduce a un CNAME con proxy attivo in Cloudflare, lo stesso dominio collegato in Shopify e un interruttore HTTPS lasciato dov'è. Il resto dell'articolo spiega perché ogni passaggio conta e come verificare che abbia tenuto, ma la configurazione è tutta qui.

Preferisci guardare: Field Notes: Cloudflare davanti a Shopify copre gli stessi argomenti in tre minuti, con la trascrizione completa sulla pagina.

Il passaggio 1 nella dashboard di Cloudflare: entrambi i record sono CNAME verso shops.myshopify.com con Proxy status Proxied.

I valori clawmart.digital che compaiono in tutto l'articolo provengono da un negozio di test reale che gestiamo su un'istanza Shopify pienamente funzionante, non da un mockup. Ogni screenshot, record e test qui sotto arriva da quel negozio.

L’avviso su un negozio che funziona

Il tuo dominio Shopify risulta collegato, il checkout funziona e il lucchetto SSL è al suo posto. Subito sotto quello stato verde compare un avviso ambra: il dominio ha un proxy Cloudflare, che Shopify non supporta. Le due cose sono vere allo stesso tempo, ed è su questa contraddizione che si blocca la maggior parte dei merchant.

È uno dei messaggi più confusi di tutta l'infrastruttura ecommerce, perché non è sbagliato e non è nemmeno del tutto giusto. Per anni mettere Cloudflare davanti a Shopify è stata davvero una cattiva idea, che rompeva i negozi in un modo preciso e prevedibile. Poi Cloudflare ha rilasciato una funzione di routing che ha risolto esattamente ciò che si rompeva, eppure Shopify continua a dirti di non farlo. È in quello scarto, tra una soluzione che funziona e un fornitore che non intende avallarla, che vive la preoccupazione del "il mio negozio sta per rompersi".

Questa è quindi la versione pratica: cosa si rompeva davvero, cosa ha risolto O2O, l'unica impostazione che può ancora buttare giù il sito se te la lasci sfuggire e come decidere se tutto questo ha senso sul tuo negozio.

Perché prima si rompeva: due nuvole arancioni

Cloudflare mostra un dominio con proxy attivo come una nuvoletta arancione. Il traffico verso quel dominio passa dalla rete Cloudflare prima di arrivare alla tua origin. Il punto critico con Shopify è che Shopify stesso gira su Cloudflare. Così, quando punti su Shopify il tuo dominio con la nuvoletta arancione, la richiesta arriva a Cloudflare con due zone che la rivendicano entrambe: la tua e quella di Shopify. Due nuvole arancioni, una sopra l'altra.

Storicamente Cloudflare non riusciva a stabilire con certezza quale zona dovesse gestire quella richiesta, quindi risolveva verso il posto sbagliato oppure entrava in loop. Il risultato era un negozio che funzionava a metà e si rompeva in modi difficili da riprodurre.

Il punto più delicato era SSL. Shopify emette e rinnova il tuo certificato tramite Let's Encrypt, e Let's Encrypt verifica che il dominio sia tuo con una challenge ACME servita su un percorso preciso:

Se un proxy davanti a Shopify intercetta, mette in cache o reindirizza quel percorso, la challenge non si completa mai. Nessuna challenge completata significa nessun certificato. E poiché i certificati si rinnovano a scadenza, il guasto era spesso silenzioso: il negozio funzionava benissimo per settimane con il certificato esistente, poi diventava non sicuro il giorno in cui quel certificato scadeva. Ecco perché il vecchio consiglio era una sola frase secca: rendi grigia la nuvoletta, solo DNS, togli il proxy di Cloudflare dal percorso.

Cosa ha cambiato Orange-to-Orange

Orange-to-Orange, o O2O, è la risposta di Cloudflare al problema delle due zone e fa parte di un prodotto che si chiama Cloudflare for SaaS. Cloudflare ha aperto quel prodotto a tutti i clienti nel 2021, con disponibilità generale a ottobre, quindi O2O è un percorso di routing consolidato, con anni alle spalle, non un esperimento recente. Il meccanismo è lineare: quando la tua zona con proxy attivo punta un CNAME verso un servizio che è anch'esso cliente Cloudflare for SaaS, Cloudflare riconosce la destinazione e smette di trattare le due zone come una collisione. Instrada la richiesta prima attraverso la tua zona e poi attraverso quella del fornitore, in un ordine definito, e il doppio proxy diventa un passaggio di consegne.

Non devi credere sulla fiducia che O2O si sia attivato. Crea il CNAME con il proxy attivo e Cloudflare mette una piccola icona Shopify accanto al record. Quell'icona è il rilevamento che conferma che Cloudflare sa dove sta andando il traffico. In background Cloudflare fa anche una serie di operazioni specifiche per il fornitore, tra cui disattivare Workers e Snippets sul percorso /checkout, così niente di ciò che esegui all'edge può interferire con il pagamento.

Quel record si aggiunge nella dashboard di Cloudflare sotto DNS, poi Records. Fai clic su Add record, imposta Type su CNAME, Target su shops.myshopify.com e Proxy status su Proxied, così la nuvoletta diventa arancione. L'icona Shopify compare accanto al record non appena Cloudflare riconosce la destinazione come uno dei propri clienti SaaS.

Gestire l’unica eccezione: SSL

O2O ha risolto la collisione di routing. Non ha risolto SSL, perché SSL non è mai stato davvero un problema di routing. Era un proxy che toccava l'unico percorso che Shopify usa per rinnovare i certificati. Su un negozio configurato correttamente quasi tutto questo ormai funziona da solo, quindi la cosa utile è sapere che cosa è automatico e poi controllare la breve lista di ciò che non lo è.

Cosa avviene ormai in automatico

Il tuo negozio porta due certificati, ed entrambi si rinnovano senza di te. Poiché il dominio ha il proxy attivo, il certificato che vedono i visitatori è il certificato edge di Cloudflare, che Cloudflare convalida via DNS e rinnova da solo, quindi il percorso ACME non lo riguarda mai. Dietro, Shopify mantiene un certificato origin separato per la tratta da Cloudflare a Shopify, rinnovato tramite Let's Encrypt, e la modalità di crittografia Full è fatta apposta per fidarsene. Shopify esegue inoltre il passaggio da HTTP a HTTPS sulla propria origin, quindi i visitatori atterrano su una connessione sicura che Cloudflare muova un dito oppure no.

Quel certificato origin si rinnova tramite ACME, lo scambio automatico che Let's Encrypt usa per confermare che il dominio è sotto il tuo controllo. Chiede a qualunque cosa risponda per il tuo dominio di servire un token monouso sul percorso qui sopra, in HTTP semplice, e Shopify gestisce tutto lo scambio in background. È per questo che non ci pensi mai. La configurazione resta sana esattamente finché quell'unico percorso rimane raggiungibile.

L'unica cosa che la rompe

Tutto questo rinnovo automatico si regge su una singola impostazione di Cloudflare che deve restare disattivata, e in parecchie configurazioni risulta attiva per impostazione predefinita.

Il rimedio, quindi, sta soprattutto nel non attivare quell'interruttore e nel lasciare che sia il redirect sull'origin di Shopify a fare l'upgrade che già esegue. Se vuoi che anche Cloudflare imponga HTTPS al proprio edge, usa una redirect rule che salti il percorso della challenge, mai Always Use HTTPS.

Cosa verificare a campione

Tutto quello che segue vive nella dashboard di Cloudflare. Accedi su dash.cloudflare.com, scegli il tuo account e fai clic sul dominio per aprirne la zona. Ogni voce è un percorso nella barra laterale sinistra di quella zona.

Un'impostazione vicina su quella pagina Edge Certificates trae spesso in inganno: Automatic HTTPS Rewrites si può tranquillamente lasciare attiva. Riscrive soltanto i link alle risorse da http a https per evitare gli avvisi di contenuto misto, cosa ben diversa da Always Use HTTPS che forza un redirect di pagina intera. Anche Opportunistic Encryption e TLS 1.3 possono restare attivi. Always Use HTTPS è l'unico interruttore di quella schermata che deve restare disattivato.

Poi verifica dall'esterno, senza aspettare che un rinnovo fallisca. Richiedi il percorso della challenge in HTTP semplice e leggi la risposta:

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

Arrivare a Shopify è il risultato che conta, e un 404 per il token inventato è esattamente ciò che vuoi vedere. Un redirect 301 o 308 verso HTTPS significa che Always Use HTTPS o una regola catch-all sta ancora inghiottendo quel percorso. Dopodiché controlla lo stato SSL sotto Settings → Domains nell'admin Shopify e, nelle settimane successive, osserva la data di scadenza del certificato origin spostarsi in avanti da sola. Un certificato che si rinnova senza interventi è il segnale che la configurazione sta tenendo.

Ripeti quel test dopo ogni modifica al DNS o alle impostazioni di Cloudflare, non solo in fase di configurazione. Hardeep, utente della Shopify Community, ha sollevato il punto nel thread dedicato a questo articolo, e corrisponde al modo in cui queste configurazioni si rompono davvero. La configurazione era corretta il primo giorno, mesi dopo qualcuno ha modificato una regola o un record, e nessuno ha ricontrollato il percorso della challenge finché un certificato non si è rinnovato in silenzio.

Vale la pena nominare chiaramente una trappola: un certificato che oggi risulta emesso ti dice che quello attuale è stato rilasciato, non che lo sarà il prossimo. I certificati Let's Encrypt si rinnovano su un ciclo di circa sessanta o novanta giorni, quindi un negozio che sembra in perfetta salute potrebbe semplicemente non aver ancora raggiunto la data di rinnovo. Questo, insieme al fatto che molti negozi non hanno mai attivato Always Use HTTPS, spiega perché in tanti tengono questa configurazione per mesi senza intoppi, e perché il guasto, quando arriva, è sconcertante. Non è cambiato niente, tranne un certificato che in silenzio non si è rinnovato.

Dagli il peso giusto. È un'assicurazione a buon mercato contro un guasto raro ma silenzioso, non il segnale che il tuo negozio stia per rompersi. Fai la configurazione da due minuti, lancia il test, e hai chiuso l'unica falla al momento del rinnovo che è davvero difficile da notare.

Shopify continua a non metterci la firma, perché…

La documentazione di Shopify non parla più genericamente di "proxy". Nomina O2O direttamente:

"Le configurazioni con proxy Cloudflare, O2O incluso, non sono supportate da Shopify. Anche se il tuo negozio potrebbe sembrare funzionare correttamente, questa configurazione potrebbe rompersi in qualsiasi momento."

Non è un avviso datato su un problema ormai risolto. È una posizione attuale e deliberata, e due delle ragioni che la sostengono reggono anche dopo O2O:

La documentazione di Shopify aggiunge una terza ragione, il rilevamento dei bot, sostenendo che il traffico che passa da Cloudflare le arriva con attributi di richiesta alterati. In pratica è la più debole delle tre: Cloudflare gestisce una delle più grandi reti di bot management esistenti, quindi la maggior parte dei negozi guadagna all'edge molto più filtraggio dei bot di quanto Shopify perda in segnale. È l'unica voce nell'elenco di Shopify in cui il proxy ha più probabilità di aiutare che di danneggiare.

L’avviso è troppo pesante?

Un po', e in modo comprensibile. La dashboard segnala un negozio collegato e funzionante con un "Issue" ambra e la frase secca "not supported", che pesa più delle reali modalità di guasto, quasi tutte evitabili con una configurazione corretta. Un merchant legge "Issue" e sente "il tuo negozio sta per rompersi", mentre quello che Shopify intende è più vicino a "non ci mettiamo la firma".

Ma "not supported" non è "non funziona", e la distinzione conta. Significa che Shopify non garantirà, non farà debug e non si assumerà la responsabilità del comportamento di uno strato che non controlla. Per una piattaforma che possiede il tuo checkout e il tuo uptime, è un confine ragionevole da tracciare, anche se il banner lo traccia in modo brusco. La segnalazione ti dice che Shopify non mette la faccia sulla configurazione. Non ti dice che la configurazione sta fallendo.

Sono molti i negozi Shopify che lo usano

Non devi fidarti della parola di un solo negozio di test. Un proxy Cloudflare davanti a Shopify non è una configurazione di nicchia: parecchi brand affermati lo usano in produzione, ogni giorno. I nomi qui sotto sono esempi reali che abbiamo verificato a mano, ciascuno dei quali serve attualmente la propria vetrina attraverso un proxy Cloudflare con Shopify dietro.

Verificato a luglio 2026 interrogando ogni dominio e confermando una risposta con proxy Cloudflare insieme ai marker della vetrina Shopify. La configurazione di un negozio può cambiare in qualsiasi momento, quindi consideralo un'istantanea, non un'approvazione da parte dei brand elencati.

Cosa ti dà l’edge che Shopify non ti dà

Shopify include già una CDN, i certificati SSL e la protezione DDoS in ogni piano, come ha fatto notare anche Hardeep nel thread della community. Non è il proxy a rendere il tuo negozio veloce, cifrato o capace di assorbire un'ondata di traffico, e se è questo che stavi cercando, ce l'hai già. Quello che segue è l'insieme più ristretto di cose che Shopify non ti consegna.

Il motivo per accettare il compromesso non è il proxy in sé. È lo strato che il proxy mette davanti al tuo negozio, un edge programmabile che Shopify non ti espone. Contano soprattutto tre capacità, e la terza è una che la maggior parte dei negozi non vede proprio.

Niente di tutto questo è incluso in un piano Shopify, perché niente di tutto questo vive dentro Shopify. Vive un salto prima, all'edge, ed è proprio questa la ragione per cui un merchant dovrebbe accollarsi un proxy non supportato.

Un'avvertenza: la cache all'edge non è automatica. Cloudflare può tenere al proprio edge file statici come fogli di stile e immagini e servirli da un server vicino invece di andarli a prendere da Shopify a ogni visita, ma un negozio Shopify con proxy attivo non mette nulla in cache da solo, e una regola di cache predefinita o mal impostata può azzerarla del tutto, al punto che file marcati come memorizzabili per un anno vengono lasciati passare senza essere toccati. La rete di Shopify tiene comunque veloce la vetrina, quindi tratta la cache all'edge come un bonus di velocità a cui aderire volontariamente. La modalità di crittografia che previene i vecchi problemi SSL si verifica nelle configurazioni SSL/TLS, la stessa schermata del pulsante Configure visto prima; la cache si imposta in un'area a sé, quindi conviene controllare entrambe già che sei nella dashboard, dato che la cache è l'impostazione che con più probabilità sta lasciando velocità sul tavolo.

Su cosa ti metterà in guardia uno sviluppatore

Un bravo sviluppatore non lascerà passare questa configurazione senza fare domande, e le domande sono legittime. Nessuna di esse è un motivo per evitare il setup, ma ognuna merita di essere verificata sul tuo negozio invece che presa per buona. Non è lavoro in più: è lo stesso collaudo che faresti dopo qualsiasi modifica infrastrutturale, e fa parte del tenere in salute un negozio. Noi testiamo entrambe le cose qui sotto sul negozio che gestiamo, e dovresti farlo anche tu.

La latenza al passaggio di consegne

La prima domanda riguarda la velocità: passare dalla tua zona Cloudflare prima di quella di Shopify aggiunge tempo percepibile? Non dovrebbe, perché entrambe le zone si trovano già sulla stessa rete Cloudflare, quindi il passaggio avviene dentro quella rete e non fuori, su internet aperto. L'abbiamo misurato su clawmart.digital, il negozio di test con proxy attivo, confrontandolo con endpoint Shopify myshopify.com grezzi dalla stessa macchina. Il negozio con proxy rispondeva all'edge in circa 150 o 200 millisecondi, la stessa fascia degli endpoint Shopify senza proxy accanto a lui. Il salto in più si perdeva nella normale variabilità tra un'esecuzione e l'altra.

Quando un negozio Shopify con proxy sembra davvero lento, la causa è quasi sempre un tema pesante o un'app di terze parti lenta, non il proxy. Misura prima di dare la colpa all'edge. Il time to first byte, eseguito più volte da una sola postazione, è la lettura più rapida:

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

Confrontalo con una baseline a nuvoletta grigia (solo DNS), oppure con il tuo indirizzo myshopify.com, o con un'esecuzione di WebPageTest. Qualche millisecondo di differenza significa che il proxy non è il tuo collo di bottiglia. Centinaia di millisecondi significano che lo sono il tema e lo stack di app, ed è lì che va speso il tempo: alleggerire il tema, tagliare le app che non usi più e sistemare il modo in cui si caricano le immagini sposteranno il numero molto più di qualsiasi cosa tu configuri all'edge.

Le app nel checkout

La seconda domanda riguarda il checkout: il proxy interferirà con le app di checkout extensibility, con i pagamenti o con gli script che girano nel passaggio più importante? Per come è progettato, non dovrebbe. Il routing O2O di Cloudflare disattiva Workers e Snippets proprio sul percorso /checkout, così niente di ciò che esegui all'edge può toccare il pagamento. Nei nostri test nessuna delle app di checkout extensibility più diffuse si è comportata male dietro questa configurazione. È la nostra esperienza, non una garanzia per ogni app sul mercato, quindi esegui sempre un checkout completo di persona.

Fai passare un ordine vero con le tue app attive: verifica che sconti, logiche di spedizione, upsell ed eventuali estensioni post-acquisto scattino come farebbero senza il proxy, e che l'ordine arrivi in Shopify con gli attributi che ti aspetti. Se un'app deve comportarsi male, lo fa qui, sul tuo ordine di test, molto prima che un cliente ci si imbatta.

Le funzioni di Shopify continueranno a funzionare?

È la domanda che i merchant si fanno subito prima di fare marcia indietro: se Cloudflare sta davanti, le cose che gestisco dentro Shopify si comportano ancora come devono? Quella che genera più ansia sono i redirect degli URL, perché si gestiscono nell'admin Shopify, contano per la SEO e non è ovvio se un proxy davanti li metterà in cache, li riscriverà o se li ingoierà.

Così lo abbiamo testato sul negozio con proxy invece di ragionarci sopra. Abbiamo creato un 301 nell'admin Shopify da /pages/redirect-test-20260727 alla homepage, verificato prima che il percorso restituisse un 404 in modo che nulla di reale ne risentisse, controllato da diverse angolazioni e poi lo abbiamo eliminato.

La risposta specifica su Cloudflare sta in quell'ultima riga. Ha passato i redirect direttamente, senza mai metterli in cache, quindi la logica dei redirect resta interamente sotto il controllo di Shopify. E non è nemmeno fortuna: Shopify invia cache-control: private, no-store sul 301 stesso, quindi Cloudflare non lo metterebbe in cache neanche se glielo chiedessi. Le query string sopravvivono, l'apex funziona e l'HTTP semplice funziona.

Un dettaglio emerso durante la pulizia vale la pena di conoscerlo, perché sembra un problema di Cloudflare e non lo è. Dopo aver eliminato il redirect, l'URL nudo ha continuato a servire il vecchio 301 per circa trenta secondi, mentre una versione dello stesso URL con cache-buster restituiva già 404. Era un singolo nodo edge di Shopify che teneva una copia obsoleta, non Cloudflare: cf-cache-status è rimasto DYNAMIC per tutto il tempo e la variante con query string era corretta da subito. Si è risolto da solo. Quindi, dopo aver modificato o rimosso un redirect, dagli un minuto prima di concludere che non ha funzionato, e testa con un cache-buster se hai dubbi.

Questo si ricollega anche all'avvertenza sulla cache di prima, e vale in entrambe le direzioni. Con la cache all'edge disattivata, le modifiche ai redirect hanno effetto immediato, il che è un vantaggio accidentale. Se in seguito attivi la cache dell'HTML all'edge, anche i redirect possono finirci dentro e le tue modifiche smetteranno di comparire subito. Se scegli quella strada, escludi i percorsi di redirect dalla regola di cache oppure inserisci un passaggio di purge in qualunque strumento usi per gestire i redirect in blocco.

Configurarlo prima che il negozio sia pubblico

Non serve una vetrina già lanciata per configurare e testare tutto questo. Spesso è più intelligente farlo mentre il negozio è ancora privato, così il rilevamento O2O, l'emissione dell'SSL e il test del checkout avvengono dove nessun cliente può capitare in mezzo a una configurazione a metà. L'unico requisito è un piano Shopify a pagamento, perché i domini personalizzati non sono disponibili nella prova gratuita. Non devi però lanciare il negozio: un piano a pagamento tenuto dietro la sua pagina password è tutto ciò che serve. Se sei su un development store Partner gratuito, che limita i domini personalizzati, trasferiscilo prima a un piano a pagamento, poi segui gli stessi passaggi.

Quindi conviene usarlo?

Trasformalo da un sì o no in una decisione su cosa ti serve all'edge, perché è l'unica cosa che giustifica il compromesso.

Gli utenti della Shopify Community Steve_TopNewYork e sophia24 sono arrivati entrambi a quella terza ragione nello stesso thread, ed è il costo che i merchant sottovalutano. Il proxy raramente è la cosa che si rompe, ma una volta che è nel percorso è uno strato in più da escludere alle due di notte, quando il checkout fa i capricci e ancora non sai perché. È una tassa reale per un team piccolo, e vale la pena pagarla solo per una funzione che sai nominare.

Se decidi di usarlo, tratta la checklist come non negoziabile: un CNAME con proxy attivo verso shops.myshopify.com, conferma che compaia l'icona Shopify, lascia Always Use HTTPS disattivato, escludi il percorso ACME dal tuo redirect HTTPS e controlla la data di rinnovo del certificato come controlleresti che un backup sia stato davvero eseguito. Configurati così, parecchi negozi girano con Cloudflare davanti a Shopify senza drammi. Salta quei passaggi e avrai creato esattamente il guasto silenzioso che l'avviso cerca di prevenire.

La versione breve, in video: Field Notes: Cloudflare davanti a Shopify ripercorre cosa ha risolto O2O e le due cose che un servizio edge ti mostra e Shopify no.

Domande frequenti

È sicuro mettere Cloudflare davanti a un negozio Shopify?

È molto più praticabile di un tempo, ma Shopify non lo supporta ufficialmente, quindi è una scelta calcolata più che priva di rischi. Il problema di routing che rompeva i negozi, due zone Cloudflare in collisione, è stato risolto dalla funzione Orange-to-Orange (O2O) di Cloudflare. Configurato correttamente, cioè con un CNAME con proxy attivo verso shops.myshopify.com, senza Always Use HTTPS e con il percorso della challenge ACME escluso da qualsiasi redirect HTTPS, molti negozi lo usano in modo affidabile. La documentazione di Shopify continua però ad affermare che le configurazioni con proxy Cloudflare, O2O incluso, non sono supportate e potrebbero rompersi in qualsiasi momento, perché Shopify non può garantire il comportamento di uno strato di proxy che non controlla. In sintesi, onestamente: tecnicamente solido se impostato bene, ufficialmente non supportato, consigliabile solo per i negozi che hanno bisogno all’edge di qualcosa che Shopify non offre.

Che cos’è Orange-to-Orange (O2O)?

Orange-to-Orange è la funzione di routing di Cloudflare per il caso in cui un cliente Cloudflare punta il proprio dominio con proxy attivo verso un servizio che è a sua volta cliente Cloudflare. Nella dashboard il proxy di Cloudflare è rappresentato da una nuvoletta arancione, quindi due zone Cloudflare sovrapposte fanno orange-to-orange. Shopify è cliente Cloudflare for SaaS, quindi un negozio Shopify rientra esattamente in questo caso. Prima di O2O, Cloudflare non riusciva a stabilire con certezza quale zona dovesse gestire la richiesta e le due entravano in collisione. O2O rileva che la destinazione del CNAME appartiene a un altro cliente Cloudflare e instrada la richiesta prima attraverso la tua zona e poi attraverso quella del fornitore, in ordine. Puoi confermare che funziona quando accanto al record CNAME nella dashboard di Cloudflare compare una piccola icona Shopify.

Perché Shopify dice che Cloudflare non è supportato?

La documentazione di Shopify indica tre ragioni principali. Due reggono bene. Primo, SSL: Shopify emette e rinnova i certificati tramite Let’s Encrypt usando una challenge HTTP ACME, e qualsiasi proxy davanti è un elemento in più che può interferire con quella convalida. Secondo, la gestione degli incidenti: quando l’infrastruttura di Shopify ha un problema, i proxy aggiuntivi davanti al negozio rendono più difficile per Shopify reinstradare il traffico attorno al guasto, il che aumenta l’esposizione ai disservizi invece di ridurla. La terza, il rilevamento dei bot, è più debole: Shopify sostiene che il traffico che passa da Cloudflare arriva con attributi di richiesta alterati, ma Cloudflare gestisce una delle più grandi reti di bot management al mondo, quindi la maggior parte dei negozi guadagna all’edge più filtraggio dei bot di quanto Shopify perda in segnale. Nessuna di queste ragioni significa che la configurazione non possa funzionare. Significano che Shopify non si assumerà la responsabilità del comportamento di uno strato che non le appartiene.

Perché il certificato SSL del mio negozio Shopify fallisce dietro Cloudflare?

Quasi sempre a causa dell’impostazione Always Use HTTPS. Shopify convalida la proprietà del dominio e rinnova i certificati SSL rispondendo a una challenge servita sul percorso /.well-known/acme-challenge/. Always Use HTTPS forza un redirect su ogni richiesta, incluso quel percorso, quindi la challenge non si completa mai e il certificato non può essere emesso né rinnovato. Il negozio continua a funzionare con il certificato esistente finché non scade, poi il dominio diventa non sicuro o smette di connettersi. La soluzione documentata da Cloudflare è lasciare Always Use HTTPS disattivato e creare invece una redirect rule che forzi HTTPS per tutto tranne che per il percorso /.well-known/acme-challenge/.

Devo mettermi un promemoria in calendario per controllare il rinnovo SSL ed evitare che il negozio si rompa?

No, non se è configurato correttamente. Il rinnovo è progettato per funzionare da solo. Il certificato che i tuoi visitatori vedono davvero è il certificato edge di Cloudflare, che Cloudflare convalida via DNS e rinnova automaticamente, quindi non dipende mai dal percorso della challenge ACME. Dietro, il certificato origin di Shopify si rinnova tramite Let’s Encrypt in background, e continua a funzionare finché Always Use HTTPS resta disattivato e il percorso /.well-known/acme-challenge/ non viene reindirizzato. Esegui una volta il test con curl dopo la configurazione per confermare che quel percorso restituisca un 404 e non un redirect, e il rinnovo automatico avrà tutto ciò che gli serve. Se vuoi una rete di sicurezza, lo strumento giusto non è un promemoria manuale su cui devi agire, ma un monitor automatico della scadenza SSL che ti invii una email se il certificato arriva a un paio di settimane dalla scadenza. Così niente dipende dal fatto che tu ti ricordi una data.

Come faccio ad accorgermene prima che un problema di certificato butti giù il negozio?

Imposta un monitoraggio, così te lo comunicano invece di scoprirlo da un cliente. Un monitor gratuito di SSL e uptime come UptimeRobot, Better Uptime o un servizio simile può sorvegliare il dominio e avvisarti giorni prima che un certificato scada, oppure nell’istante in cui HTTPS inizia a fallire. Anche Cloudflare può inviare notifiche su problemi di certificati e origin dall’area Notifications della dashboard. Con uno dei due attivo, il fallimento silenzioso del rinnovo, che è l’unico rischio reale di questa configurazione, smette di essere silenzioso: ricevi una email con settimane di anticipo, molto prima che il lucchetto si rompa per chi compra.

I redirect URL di Shopify funzionano ancora dietro un proxy Cloudflare?

Sì. Lo abbiamo testato da capo a fondo su un negozio con proxy attivo: un 301 creato nell’admin Shopify è andato in produzione subito, senza attesa di propagazione, ha restituito il 301 e l’header location corretti, ha portato a un 200 sulla destinazione in un solo salto, ha preservato le query string come ?utm_source=test e ha funzionato dal dominio apex e in HTTP semplice. Cloudflare ha passato il redirect direttamente senza mai metterlo in cache, riportando cf-cache-status: DYNAMIC a ogni richiesta, quindi la logica dei redirect resta interamente sotto il controllo di Shopify. Shopify invia inoltre cache-control: private, no-store sul 301 stesso, quindi Cloudflare non lo metterebbe in cache nemmeno se lo configurassi per farlo. Un’avvertenza: dopo aver modificato o eliminato un redirect, un nodo edge di Shopify può servire una copia obsoleta per circa trenta secondi, quindi aspetta un minuto e testa con un cache-buster prima di concludere che non ha funzionato. Se in seguito attivi la cache dell’HTML all’edge di Cloudflare, escludi i percorsi di redirect o aggiungi un passaggio di purge, perché anche i redirect possono finire in cache lì.

Posso configurare Cloudflare su un negozio Shopify non ancora pubblico?

Sì, ed è spesso il modo più intelligente di farlo. Non serve una vetrina già lanciata, serve solo un piano Shopify a pagamento, dato che i domini personalizzati non sono disponibili nella prova gratuita. Tieni il negozio dietro la sua pagina password sotto Online Store e poi Preferences, crea in Cloudflare lo stesso CNAME con proxy attivo verso shops.myshopify.com usando un host che non stai servendo in produzione, per esempio un sottodominio di staging, e collega quell’host in Shopify sotto Settings e poi Domains. Shopify emette l’SSL e la dashboard di Cloudflare mostra l’icona Shopify non appena Orange-to-Orange si attiva, il tutto mentre il pubblico vede solo la pagina password. Esegui il test curl ACME e un checkout di prova completo con le tue app attive e, quando tutto passa, togli la password e imposta il tuo dominio reale come primario. Vai in produzione su una configurazione che hai già dimostrato funzionante. Se sei su un development store Partner gratuito, che limita i domini personalizzati, trasferiscilo prima a un piano a pagamento.