Dois sites com Cloudflare + R2 grátis + aceleração com domínio otimizado: retrospectiva para entender de vez as armadilhas

AIDO ops
, ,
1

Uma novela sobre aceleração de imagens: como pegamos dois sites de “dá pra acessar” e consertamos até ficar “realmente rápido”

Primeiro, a conclusão:

  • d3v e aiya agora conseguem usar de forma estável a rota Cloudflare + R2.
  • Imagens antigas e novas abrem.
  • Os uploads históricos locais podem ser limpos após backup, sem ficar refém do disco.

Agora, o processo:

Ato 1: achamos que era problema de rede, mas era “desvio sistêmico”

No começo, todo mundo ficou olhando para a latência:

  • China até Singapura, o ping parecia 300ms.
  • SSH travava a ponto de dar vontade de desistir.
  • O site do negócio, por usar proxy reverso da CF e domínio otimizado, na prática até que “parecia ok”.

Aí veio a pergunta de alma:

“Dá pra acelerar o SSH do mesmo jeito?”

A resposta é: dá pra mexer, mas não é só pegar a mesma receita de acelerar site HTTP e copiar/colar. Depois, a gente primeiro estreitou o foco para o caminho das imagens, porque é aí que está a maior parte do impacto perceptível para o usuário.

Ato 2: 404 não é que o objeto sumiu — é que o back-to-origin voltou pra casa errada

O buraco mais clássico:

  • O link uploads.aiya.de5.net/... abria e dava 404.
  • Mas indo no R2 e fazendo head_object, o objeto estava lá.

Isso significa o quê?

Significa que “a camada de storage não tem problema, a camada de tráfego tem problema”.

Diagnóstico final:

  • O custom hostname SaaS de uploads.aiya chegou a apontar o origin para a entrada de outro bucket.
  • O Host/SNI do back-to-origin e o match do Nginx também chegaram a ficar desalinhados.
  • E, por cima, a Cloudflare ainda cacheou o 404 antigo, fazendo parecer “consertou mas não consertou”.

Resumo em uma frase:

O objeto estar no bucket não significa que o usuário consegue pegar.

Ato 3: você acha que é DNS, mas na real é “interação entre múltiplas camadas de configuração”

Desta vez, a rota tinha quatro camadas:

  1. Roteamento por linha da Huawei Cloud (China / exterior)
  2. Cloudflare SaaS custom hostname
  3. Orquestração de back-to-origin no Nginx
  4. Domínio public/managed/custom do bucket R2

Qualquer configuração “parecida” em qualquer camada pode mandar a requisição para o bucket errado ou para o Host errado.

Então nosso jeito de consertar não foi “mudar uma linha no chute”, e sim:

  • Primeiro fazer backup.
  • Depois validar camada por camada (DNS → SaaS → origin → bucket object).
  • Em cada camada usar curl -I e HEAD do objeto para checar os fatos.

Ato 4: por que posts antigos sempre parecem “não ter mudado”

Muita gente quebra aqui:

“Eu não coloquei tudo em S3/R2? Por que os posts antigos ainda são aiya.de5.net/uploads/...?”

Porque o Discourse tem dois mundos:

  • raw: o texto original do post (comum ver upload://...)
  • cooked: o HTML renderizado (img/src/srcset fica aqui)

posts:rebake recalcula o cooked a partir do raw.

Então, se você só mexer no cooked, um rebake posterior pode “te devolver para o padrão”.

Isso não é falha do R2; é o comportamento normal da estratégia de renderização.

Ato 5: o que exatamente fizemos desta vez

O que finalmente ficou de pé foi:

  • Corrigir o back-to-origin de uploads.aiya para o bucket correto.
  • Limpar o cache antigo de 404.
  • Sincronizar para o R2 os objetos históricos que estavam faltando.
  • Fazer substituição em massa no cooked dos posts antigos para https://uploads.aiya.de5.net/... (para padronizar também a exibição).

Resultado:

  • Todas as imagens quebradas que você postou voltaram.
  • Imagens novas e antigas passaram a acertar a rota acelerada.

Checklist “pra não sofrer à toa” para quem vier depois

  1. Não suspeite primeiro de objeto perdido; faça HEAD object antes.
  2. Em 404, olhe primeiro o estado do cache: cf-cache-status: HIT pode ser só cache velho.
  3. Depois de mudar o origin no SaaS custom hostname, valide obrigatoriamente o match real de Host.
  4. Mude uma camada por vez, valide em cada camada; não mude tudo ao mesmo tempo e depois reze.
  5. Faça backup antes de migrar, principalmente de /shared/uploads/*.
  6. Escrever o “caminho de rollback” é mais importante do que “desta vez deu certo”.

Easter egg: a sensação mais real desta vez

Isso não é um problema de “um registro DNS que faltou preencher”.

Isso é uma “meia arquitetura enterprise montada a partir de plano grátis”:

  • Dá pra economizar, dá pra acelerar, dá pra rodar;
  • Mas você tem que ter a paciência de um SRE e aceitar que ela vai te ensinar nas condições de borda.

Dá trabalho, mas no fim vale a pena:

  • O custo não explodiu;
  • A velocidade subiu;
  • E a arquitetura finalmente saiu de “dá pra usar” para “é explicável e manutenível”.

Espero que isso ajude quem vier depois a virar menos noites.