Agora é mais seguro colocar o Cloudflare na frente do Shopify: o que o O2O resolveu e o que os avisos ainda significam.

Início Rápido: Faça Isto na Sua Loja

Se você veio pelos passos, aqui estão eles. A configuração inteira é um CNAME com proxy no Cloudflare, o mesmo domínio conectado na Shopify e uma chave de HTTPS que fica intocada. O restante deste artigo explica por que cada passo importa e como confirmar que ele se sustentou, mas esta é toda a configuração.

Prefere assistir: Field Notes: Cloudflare in front of Shopify cobre o mesmo terreno em três minutos, com transcrição completa na página.

Passo 1 no painel do Cloudflare: os dois registros são CNAMEs para shops.myshopify.com com Proxy status Proxied.

Os valores clawmart.digital mostrados ao longo deste artigo vêm de uma loja de teste ativa que mantemos em uma instância Shopify plenamente funcional, não de uma simulação. Toda captura de tela, registro e teste abaixo vem dessa loja.

O Aviso em uma Loja que Funciona

Seu domínio Shopify aparece como conectado, o checkout funciona e o cadeado do SSL está lá. Logo abaixo desse status verde há um aviso âmbar de que o seu domínio tem um proxy Cloudflare, algo que a Shopify não suporta. As duas coisas são verdadeiras ao mesmo tempo, e é nessa contradição que a maioria dos lojistas trava.

Esta é uma das mensagens mais confusas da infraestrutura de ecommerce, porque ela não está errada e também não está exatamente certa. Durante anos, colocar o Cloudflare na frente da Shopify foi uma péssima ideia que quebrava lojas de um jeito específico e previsível. Depois o Cloudflare lançou um recurso de roteamento que corrigiu exatamente o que quebrava, e mesmo assim a Shopify continua dizendo para você não fazer isso. Essa distância, entre uma correção que funciona e um fornecedor que não a endossa, é onde mora a preocupação do tipo "minha loja está prestes a quebrar?".

Então esta é a versão prática: o que de fato quebrava, o que o O2O corrigiu, a única configuração que ainda vai derrubar o seu site se você errar, e como decidir se algo disso faz sentido na sua loja.

Por Que Isso Quebrava: Duas Nuvens Laranja

O Cloudflare mostra um domínio com proxy como uma nuvem laranja. O tráfego desse domínio passa pela rede do Cloudflare antes de chegar à sua origem. O detalhe no caso da Shopify é que a própria Shopify roda sobre o Cloudflare. Então, quando você aponta o seu domínio de nuvem laranja para a Shopify, a requisição chega ao Cloudflare com duas zonas reivindicando o mesmo tráfego: a sua e a da Shopify. Duas nuvens laranja, empilhadas.

Historicamente, o Cloudflare não conseguia determinar com segurança qual zona deveria assumir a requisição, então ela resolvia para o lugar errado ou entrava em loop. O resultado era uma loja que funcionava pela metade e falhava de formas difíceis de reproduzir.

A aresta mais afiada era o SSL. A Shopify provisiona e renova o seu certificado pela Let's Encrypt, e a Let's Encrypt comprova que você é dono do domínio com um desafio ACME servido em um caminho específico:

Se um proxy na frente da Shopify intercepta, armazena em cache ou redireciona esse caminho, o desafio nunca se completa. Sem desafio concluído, não há certificado. E como os certificados renovam em ciclos, isso costumava falhar em silêncio: a loja funcionava bem com o certificado atual por semanas e ficava insegura no dia em que ele vencia. É por isso que o conselho antigo cabia em uma linha direta: deixe a nuvem cinza, DNS only, tire o proxy do Cloudflare do caminho.

O Que o Orange-to-Orange Mudou

Orange-to-Orange, ou O2O, é a resposta do Cloudflare ao problema das duas zonas, e faz parte de um produto chamado Cloudflare for SaaS. O Cloudflare abriu esse produto para todos os clientes em 2021, com disponibilidade geral em outubro daquele ano, então o O2O é um caminho de roteamento consolidado, com anos de estrada, não um experimento recente. O mecanismo é simples: quando a sua zona com proxy aponta um CNAME para um serviço que também é cliente do Cloudflare for SaaS, o Cloudflare reconhece o destino e para de tratar as duas zonas como uma colisão. Ele roteia a requisição primeiro pela sua zona e depois pela zona do provedor, em uma ordem definida, e o proxy duplo vira uma passagem de bastão.

Você não precisa acreditar por fé que o O2O entrou em ação. Crie o CNAME com o proxy ligado e o Cloudflare coloca um pequeno ícone da Shopify ao lado do registro. Esse ícone é a detecção confirmando que ele sabe para onde o tráfego está indo. O Cloudflare também faz uma manutenção específica por provedor em segundo plano, incluindo desativar Workers e Snippets no caminho /checkout, de modo que nada que você rode na borda possa interferir no pagamento.

Você adiciona esse registro no painel do Cloudflare em DNS e depois Records. Clique em Add record, defina o Type como CNAME, o Target como shops.myshopify.com e o Proxy status como Proxied, para que a nuvem fique laranja. O ícone da Shopify aparece ao lado do registro assim que o Cloudflare reconhece o destino como um dos seus próprios clientes SaaS.

Lidando com a Única Exceção: SSL

O O2O corrigiu a colisão de roteamento. Ele não corrigiu o SSL, porque o SSL nunca foi de fato um problema de roteamento. Era um proxy tocando o único caminho que a Shopify usa para renovar certificados. Em uma loja bem configurada, quase tudo isso hoje roda sozinho, então o que vale é saber o que é automático e depois conferir a lista curta do que não é.

O que hoje acontece automaticamente

Sua loja carrega dois certificados, e ambos renovam sem você. Como o domínio tem proxy, o certificado que os visitantes veem é o certificado de borda do próprio Cloudflare, que o Cloudflare valida por DNS e renova sozinho, então o caminho ACME nunca encosta nele. Atrás dele, a Shopify mantém um certificado de origem separado para o trecho entre Cloudflare e Shopify, renovado pela Let's Encrypt, e o seu modo de criptografia Full foi feito para confiar nele. A Shopify também executa a elevação de HTTP para HTTPS na sua própria origem, então os visitantes chegam em uma conexão segura independentemente de o Cloudflare mover um dedo.

Esse certificado de origem renova via ACME, a troca automatizada que a Let's Encrypt usa para confirmar que você controla o domínio. Ela pede que o que quer que responda pelo seu domínio sirva um token de uso único no caminho acima, em HTTP puro, e a Shopify conduz toda a troca em segundo plano. É por isso que você nunca pensa nisso. A configuração continua saudável exatamente enquanto esse caminho permanecer acessível.

A única coisa que quebra tudo

Toda essa renovação automática depende de uma configuração do Cloudflare permanecer desligada, e ela vem ligada em muitos ambientes por padrão.

Então a correção é, em boa medida, uma questão de não ligar essa chave e deixar o redirecionamento de origem da Shopify fazer a elevação que ele já executa. Se você quiser que o Cloudflare também force HTTPS na própria borda, use uma regra de redirecionamento que ignore o caminho do desafio, nunca Always Use HTTPS.

O que verificar

Tudo o que segue fica no painel do Cloudflare. Entre em dash.cloudflare.com, escolha a sua conta e clique no domínio para abrir a zona dele. Cada item é um caminho na barra lateral esquerda dessa zona.

Um vizinho nessa página de Edge Certificates confunde muita gente: Automatic HTTPS Rewrites pode ficar ligado sem problema. Ele apenas reescreve links de recursos em http para https a fim de evitar avisos de conteúdo misto, o que é bem diferente do Always Use HTTPS forçando um redirecionamento de página inteira. Opportunistic Encryption e TLS 1.3 também podem ficar ligados. Always Use HTTPS é a única chave dessa tela que precisa ficar desligada.

Depois confirme por fora, sem esperar uma renovação falhar. Requisite o caminho do desafio em HTTP puro e leia a resposta:

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

Chegar até a Shopify é a vitória, e um 404 para o token inventado é exatamente o esperado. Um redirecionamento 301 ou 308 para HTTPS significa que Always Use HTTPS ou uma regra genérica ainda está engolindo o caminho. Depois disso, confira o status do SSL em Settings → Domains no seu admin da Shopify e, nas semanas seguintes, observe a data de expiração do certificado de origem avançar sozinha. Um certificado que renova sem intervenção é o sinal de que a configuração está se sustentando.

Rode esse teste de novo depois de qualquer mudança no seu DNS ou nas configurações do Cloudflare, e não apenas na instalação. O usuário Hardeep, da Shopify Community, levantou esse ponto na discussão sobre este artigo, e isso combina com o jeito como essas configurações realmente falham. Estava tudo certo no primeiro dia, alguém editou uma regra ou um registro meses depois e ninguém reconferiu o caminho do desafio até um certificado silenciosamente não renovar.

Vale nomear uma armadilha com todas as letras: um certificado que aparece como provisionado hoje diz que o certificado atual foi emitido, não que a próxima renovação vai acontecer. Certificados da Let's Encrypt renovam em um ciclo de aproximadamente sessenta a noventa dias, então uma loja que parece completamente saudável pode ser apenas uma loja que ainda não chegou à data de renovação. Isso, somado ao fato de que muitas lojas nunca ligaram o Always Use HTTPS, é o motivo de tantas rodarem assim por meses sem nenhum incidente, e também o motivo de a falha, quando vem, ser confusa. Nada mudou, exceto um certificado que silenciosamente não renovou.

Dê a isso o peso certo. Este é um seguro barato contra uma falha incomum mas silenciosa, não um sinal de que a sua loja vai quebrar. Faça a configuração de dois minutos, rode o teste e você terá fechado a única brecha de renovação que é genuinamente difícil de perceber.

A Shopify Ainda Não Endossa Isso, Porque…

A documentação da Shopify não fala mais de "proxies" de forma genérica. Ela cita o O2O nominalmente:

"Configurações de proxy Cloudflare, incluindo O2O, não têm suporte da Shopify. Embora a sua loja possa parecer funcionar corretamente, essa configuração pode parar de funcionar a qualquer momento."

Não é um aviso desatualizado sobre um problema já resolvido. É uma posição atual e deliberada, e dois dos motivos por trás dela continuam de pé mesmo depois do O2O:

A documentação da própria Shopify acrescenta um terceiro motivo, detecção de bots, argumentando que o tráfego vindo pelo Cloudflare chega com atributos de requisição alterados. Na prática, esse é o mais fraco dos três: o Cloudflare opera uma das maiores redes de gestão de bots que existem, então a maioria das lojas ganha muito mais filtragem de bots na borda do que a Shopify perde em sinal. É o único item da lista da Shopify em que o proxy tem mais chance de ajudar do que de atrapalhar.

O Aviso É Exagerado?

Um pouco, e de forma compreensível. O painel sinaliza uma loja conectada e funcionando com um "Issue" âmbar e a frase seca "not supported", o que soa mais grave do que os modos de falha reais, quase todos evitáveis com a configuração correta. O lojista lê "Issue" e escuta "sua loja está prestes a quebrar", quando o que a Shopify quer dizer é mais próximo de "não vamos responder por isso".

Mas "sem suporte" não é "não funciona", e a distinção importa. Significa que a Shopify não vai garantir, depurar ou assumir responsabilidade pelo comportamento de uma camada que ela não controla. Para uma plataforma que é dona do seu checkout e da sua disponibilidade, essa é uma linha razoável de traçar, mesmo que o banner a trace de forma bruta. O aviso diz que a Shopify não vai respaldar a configuração. Ele não diz que a configuração está falhando.

Existem Muitas Lojas Shopify Rodando Assim

Você não precisa acreditar na palavra de uma única loja de teste. Um proxy Cloudflare na frente da Shopify não é uma configuração marginal: muitas marcas estabelecidas rodam assim em produção, todos os dias. Os nomes abaixo são exemplos reais que verificamos manualmente, cada um servindo hoje a sua vitrine através de um proxy Cloudflare com a Shopify por trás.

Verificado em julho de 2026 requisitando cada domínio e confirmando uma resposta de proxy Cloudflare junto com marcadores de vitrine Shopify. A configuração de uma loja pode mudar a qualquer momento, então trate isto como um retrato do momento, não como um endosso das marcas listadas.

O Que a Borda Oferece e a Shopify Não

A Shopify já entrega CDN, certificados SSL e proteção contra DDoS em todos os planos, como o Hardeep também apontou na discussão da comunidade. Não é o proxy que deixa a sua loja rápida, criptografada ou capaz de absorver uma enxurrada de tráfego, e se era isso que você procurava, você já tem. O que vem a seguir é o conjunto mais estreito de coisas que a Shopify não entrega.

A razão para aceitar o tradeoff não é o proxy em si. É a camada que o proxy coloca na frente da sua loja, uma borda programável que a Shopify não expõe a você. Três capacidades importam mais, e a terceira é uma que a maioria das lojas nunca chega a ver.

Nada disso vem com um plano da Shopify, porque nada disso vive dentro da Shopify. Vive um salto antes, na borda, que é toda a razão pela qual um lojista assumiria um proxy sem suporte em primeiro lugar.

Uma ressalva: cache na borda não é automático. O Cloudflare pode manter arquivos estáticos como folhas de estilo e imagens na sua borda e servi-los de um servidor próximo em vez de buscá-los na Shopify a cada visita, mas uma loja Shopify com proxy não faz cache sozinha, e uma regra de cache padrão ou mal delimitada pode suprimir isso por completo, fazendo com que arquivos marcados como cacheáveis por um ano passem direto, intocados. A própria rede da Shopify mantém a vitrine rápida de qualquer forma, então trate o cache na borda como um bônus de velocidade ao qual você adere por escolha. Você confirma o modo de criptografia que evita os antigos problemas de SSL nas configurações de SSL/TLS, a mesma tela do botão Configure visto antes; o cache fica em uma área própria, então vale conferir os dois enquanto você está no painel, já que o cache é a configuração com maior chance de estar deixando velocidade na mesa.

O Que um Desenvolvedor Vai Questionar

Um bom desenvolvedor não vai aprovar isso sem perguntas, e as perguntas são justas. Nenhuma delas é motivo para evitar a configuração, mas cada uma merece ser confirmada na sua própria loja em vez de aceita por fé. Isso não é trabalho extra: é o mesmo teste que você faria depois de qualquer mudança de infraestrutura, e faz parte de manter uma loja saudável. Testamos os dois pontos abaixo na loja que operamos, e você também deveria.

Latência na passagem de bastão

A primeira pergunta é sobre velocidade: rotear pela sua zona Cloudflare antes da zona da própria Shopify acrescenta tempo perceptível? Não deveria, porque as duas zonas já ficam na mesma rede do Cloudflare, então a passagem acontece dentro dessa rede e não pela internet aberta. Medimos isso em clawmart.digital, a loja de teste com proxy, contra endpoints Shopify puros em myshopify.com a partir da mesma máquina. A loja com proxy respondeu na borda em cerca de 150 a 200 milissegundos, a mesma faixa dos endpoints Shopify sem proxy ao lado. O salto extra se perdeu na variação normal entre execuções.

Quando uma loja Shopify com proxy realmente parece lenta, a causa quase sempre é um tema pesado ou um app de terceiros lento, não o proxy. Meça antes de culpar a borda. Time to first byte, executado várias vezes a partir de um mesmo local, é a leitura mais rápida:

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

Compare com uma linha de base de nuvem cinza (DNS only), ou com o seu endereço myshopify.com, ou com uma execução do WebPageTest. Alguns milissegundos de diferença significam que o proxy não é o seu gargalo. Centenas de milissegundos significam que o tema e a pilha de apps são, e é aí que vale investir o tempo: enxugar o tema, cortar apps que você não usa mais e corrigir o carregamento de imagens vai mexer no número muito mais do que qualquer coisa que você configure na borda.

Apps no checkout

A segunda pergunta é sobre o checkout: o proxy vai interferir em apps de checkout extensibility, em pagamento ou nos scripts que rodam na etapa mais importante? Por projeto, não deveria. O roteamento O2O do Cloudflare desativa Workers e Snippets no caminho /checkout justamente para que nada que você rode na borda toque no pagamento. Nos nossos testes, nenhum dos apps populares de checkout extensibility se comportou mal com essa configuração. Essa é a nossa experiência, não uma garantia para todo app do mercado, então sempre faça um checkout completo você mesmo.

Passe um pedido real com os seus apps ativos: confirme que descontos, lógica de frete, upsells e quaisquer extensões de pós-compra disparam do mesmo jeito que sem o proxy, e que o pedido chega à Shopify com os atributos esperados. Se um app for se comportar mal, é aqui que isso aparece, no seu pedido de teste, muito antes de um cliente encontrar o problema.

Os Recursos da Shopify Vão Continuar Funcionando?

Esta é a pergunta que os lojistas fazem logo antes de desistir: se o Cloudflare fica na frente, as coisas que eu gerencio dentro da Shopify continuam se comportando? A que gera mais ansiedade são os redirecionamentos de URL, porque eles são gerenciados no admin da Shopify, importam para SEO e não é óbvio se um proxy na frente vai armazenar em cache, reescrever ou engolir esses redirecionamentos.

Então testamos na loja com proxy em vez de teorizar. Criamos um 301 no admin da Shopify de /pages/redirect-test-20260727 para a home, confirmamos antes que o caminho devolvia um 404 para que nada real fosse afetado, verificamos por vários ângulos e depois excluímos.

A resposta específica sobre o Cloudflare está naquela última linha. Ele repassou os redirecionamentos direto e nunca os armazenou em cache, então a sua lógica de redirecionamento permanece inteiramente sob controle da Shopify. E isso não é sorte: a Shopify envia cache-control: private, no-store no próprio 301, então o Cloudflare não faria cache dele nem se você pedisse. Query strings sobrevivem, o apex funciona e HTTP puro funciona.

Um detalhe da limpeza vale conhecer, porque parece um problema do Cloudflare e não é. Depois que excluímos o redirecionamento, a URL sem parâmetros continuou servindo o 301 antigo por cerca de trinta segundos, enquanto uma versão da mesma URL com cache-buster já devolvia 404. Era um único nó de borda da Shopify segurando uma cópia desatualizada, não o Cloudflare: o cf-cache-status permaneceu DYNAMIC o tempo todo e a variante com query string estava correta de imediato. Resolveu-se sozinho. Então, depois de alterar ou remover um redirecionamento, espere um minuto antes de concluir que não funcionou, e teste com um cache-buster se estiver em dúvida.

Isso também se conecta à ressalva sobre cache mencionada antes, e vale nos dois sentidos. Com o cache na borda desligado, mudanças de redirecionamento passam a valer instantaneamente, o que é uma vantagem acidental. Se mais tarde você ligar cache de HTML na borda, redirecionamentos também podem ser armazenados ali e as suas edições deixarão de aparecer na hora. Se seguir por esse caminho, exclua os caminhos de redirecionamento da regra de cache ou construa uma etapa de purge na ferramenta que você usa para gerenciar redirecionamentos em lote.

Configurando Antes de a Loja Ficar Pública

Você não precisa de uma vitrine lançada para configurar e testar nada disso. Costuma ser mais inteligente fazer enquanto a loja ainda está privada, para que a detecção do O2O, o provisionamento de SSL e o teste de checkout aconteçam onde nenhum cliente possa esbarrar em uma configuração pela metade. O único requisito é um plano Shopify pago, porque domínios personalizados não estão disponíveis no teste gratuito. Mas você não precisa lançar a loja: um plano pago mantido atrás da página de senha é tudo de que a configuração precisa. Se você estiver em uma loja de desenvolvimento gratuita de Partner, que restringe domínios personalizados, transfira-a antes para um plano pago e siga os mesmos passos.

Então, Você Deve Usar?

Transforme isso de um sim ou não em uma decisão sobre o que você precisa na borda, porque essa é a única coisa que justifica o tradeoff.

Os usuários Steve_TopNewYork e sophia24, da Shopify Community, chegaram a esse terceiro ponto na mesma discussão, e é o custo que os lojistas mais subestimam. O proxy raramente é o que quebra, mas uma vez que ele está no caminho, é mais uma camada que você precisa descartar às duas da manhã, quando o checkout está estranho e você ainda não sabe por quê. Isso é um imposto real sobre um time pequeno, e só vale pagar por um recurso que você consegue nomear.

Se você for usar, trate a lista como inegociável: um CNAME com proxy para shops.myshopify.com, confirme que o ícone da Shopify aparece, deixe Always Use HTTPS desligado, exclua o caminho ACME do seu redirecionamento para HTTPS e verifique a data de renovação do certificado do mesmo jeito que você verificaria se um backup realmente rodou. Configuradas assim, muitas lojas rodam com o Cloudflare na frente da Shopify sem drama. Pule esses passos e você terá montado exatamente a falha silenciosa que o aviso tenta evitar.

A versão curta, em vídeo: Field Notes: Cloudflare in front of Shopify percorre o que o O2O corrigiu e as duas coisas que um serviço de borda mostra e a Shopify não.

Perguntas Frequentes

É seguro colocar o Cloudflare na frente de uma loja Shopify?

É muito mais viável do que já foi, mas a Shopify não oferece suporte oficial, então é uma escolha calculada e não uma opção livre de risco. O problema de roteamento que quebrava lojas, duas zonas Cloudflare colidindo, foi resolvido pelo recurso Orange-to-Orange (O2O) do Cloudflare. Configurado corretamente, ou seja, um CNAME com proxy para shops.myshopify.com, sem Always Use HTTPS e com o caminho do desafio ACME excluído de qualquer redirecionamento para HTTPS, muitas lojas rodam assim de forma confiável. A documentação da própria Shopify ainda afirma que configurações de proxy Cloudflare, incluindo O2O, não têm suporte e podem parar de funcionar a qualquer momento, porque ela não consegue garantir o comportamento de uma camada de proxy que não controla. O resumo honesto: tecnicamente sólido quando bem configurado, oficialmente sem suporte, e mais indicado para lojas que precisam de algo na borda que a Shopify não oferece.

O que é Orange-to-Orange (O2O)?

Orange-to-Orange é o recurso de roteamento do Cloudflare para quando um cliente Cloudflare aponta o seu domínio com proxy para um serviço que também é cliente Cloudflare. O proxy do Cloudflare aparece como uma nuvem laranja no painel, então duas zonas Cloudflare empilhadas formam um orange-to-orange. A Shopify é cliente do Cloudflare for SaaS, então uma loja Shopify é exatamente esse caso. Antes do O2O, o Cloudflare não conseguia determinar com segurança qual zona deveria assumir a requisição e as duas colidiam. O O2O detecta que o destino do CNAME pertence a outro cliente Cloudflare e roteia a requisição primeiro pela sua zona e depois pela zona do provedor, nessa ordem. Você confirma que está funcionando quando um pequeno ícone da Shopify aparece ao lado do registro CNAME no seu painel do Cloudflare.

Por que a Shopify diz que o Cloudflare não tem suporte?

A documentação da Shopify apresenta três motivos principais. Dois se sustentam bem. Primeiro, SSL: a Shopify emite e renova certificados pela Let’s Encrypt usando um desafio ACME em HTTP, e qualquer proxy na frente é mais um elemento capaz de atrapalhar essa validação. Segundo, resposta a incidentes: quando a própria infraestrutura da Shopify tem um problema, proxies extras na frente da loja dificultam que a Shopify redirecione o tráfego para contornar a falha, o que aumenta a exposição a quedas em vez de reduzi-la. O terceiro, detecção de bots, é mais fraco: a Shopify argumenta que o tráfego vindo pelo Cloudflare chega com atributos de requisição alterados, mas o Cloudflare opera uma das maiores redes de gestão de bots do mundo, então a maioria das lojas ganha mais filtragem de bots na borda do que a Shopify perde em sinal. Nada disso significa que a configuração não funciona. Significa que a Shopify não vai assumir responsabilidade pelo comportamento de uma camada que não é dela.

Por que o certificado SSL da minha loja Shopify falha atrás do Cloudflare?

Quase sempre por causa da configuração Always Use HTTPS. A Shopify valida a propriedade do domínio e renova certificados SSL respondendo a um desafio servido no caminho /.well-known/acme-challenge/. Always Use HTTPS força um redirecionamento em toda requisição, inclusive nesse caminho, então o desafio nunca se completa e o certificado não pode ser emitido nem renovado. A loja continua funcionando com o certificado atual até ele expirar, e então o domínio fica inseguro ou para de conectar. A correção documentada pelo Cloudflare é deixar Always Use HTTPS desligado e, no lugar, criar uma regra de redirecionamento que force HTTPS para tudo, exceto para o caminho /.well-known/acme-challenge/.

Preciso criar um lembrete no calendário para conferir a renovação do SSL e evitar que a loja quebre?

Não, não se estiver configurado corretamente. A renovação foi feita para rodar sozinha. O certificado que os seus visitantes realmente veem é o certificado de borda do próprio Cloudflare, validado por DNS e renovado automaticamente pelo Cloudflare, então ele nunca depende do caminho do desafio ACME. Atrás dele, o certificado de origem da Shopify renova pela Let’s Encrypt em segundo plano, e isso continua funcionando enquanto Always Use HTTPS estiver desligado e o caminho /.well-known/acme-challenge/ não for redirecionado. Rode o teste de curl uma única vez após a configuração para confirmar que esse caminho devolve um 404 e não um redirecionamento, e a renovação automática terá tudo o que precisa. Se quiser uma rede de segurança, a ferramenta certa não é um lembrete manual no calendário que depende de você agir, é um monitor automático de expiração de SSL que envia um e-mail se o certificado chegar a duas semanas do vencimento. Assim nada depende de você lembrar de uma data.

Como eu ficaria sabendo antes de um problema de certificado derrubar a loja?

Configure monitoramento para ser avisado, em vez de descobrir por um cliente. Um monitor gratuito de SSL e disponibilidade como UptimeRobot, Better Uptime ou serviço equivalente pode observar o domínio e alertar você dias antes de um certificado expirar, ou no momento em que o HTTPS começar a falhar. O próprio Cloudflare também envia notificações sobre problemas de certificado e de origem pela área de Notifications do painel. Com qualquer um dos dois no lugar, a falha silenciosa de renovação que é o único risco real desta configuração deixa de ser silenciosa: você recebe um e-mail com semanas de antecedência, muito antes de o cadeado quebrar para os compradores.

Os redirecionamentos de URL da Shopify continuam funcionando atrás de um proxy Cloudflare?

Sim. Testamos isso de ponta a ponta em uma loja com proxy: um 301 criado no admin da Shopify entrou no ar imediatamente, sem espera de propagação, devolveu o 301 e o header location corretos, seguiu até um 200 no destino em um único salto, preservou query strings como ?utm_source=test e funcionou a partir do domínio apex e por HTTP puro. O Cloudflare repassou o redirecionamento direto e nunca o armazenou em cache, reportando cf-cache-status: DYNAMIC em toda requisição, então a sua lógica de redirecionamento permanece inteiramente sob controle da Shopify. A Shopify também envia cache-control: private, no-store no próprio 301, então o Cloudflare não faria cache dele nem se você configurasse isso. Uma ressalva: depois de alterar ou excluir um redirecionamento, um nó de borda da Shopify pode servir uma cópia desatualizada por cerca de trinta segundos, então espere um minuto e teste com um cache-buster antes de concluir que não funcionou. Se mais tarde você ativar cache de HTML na borda do Cloudflare, exclua os caminhos de redirecionamento ou adicione uma etapa de purge, porque redirecionamentos também podem ser armazenados em cache ali.

Posso configurar o Cloudflare em uma loja Shopify que ainda não está pública?

Sim, e muitas vezes é a maneira mais inteligente de fazer. Você não precisa de uma vitrine lançada, apenas de um plano Shopify pago, já que domínios personalizados não estão disponíveis no teste gratuito. Mantenha a loja atrás da página de senha em Online Store e depois Preferences, crie no Cloudflare o mesmo CNAME com proxy para shops.myshopify.com usando um host que você não serve em produção, como um subdomínio de staging, e conecte esse host na Shopify em Settings e depois Domains. A Shopify provisiona o SSL e o painel do Cloudflare mostra o ícone da Shopify assim que o Orange-to-Orange entra em ação, tudo isso enquanto o público vê apenas a página de senha. Rode o teste de curl do ACME e um checkout de teste completo com os seus apps ativos e, quando tudo passar, remova a senha e defina o seu domínio real como principal. Você lança sobre uma configuração que já provou funcionar. Se você estiver em uma loja de desenvolvimento gratuita de Partner, que restringe domínios personalizados, transfira-a antes para um plano pago.