DNS no Cloudflare: nuvem laranja vs cinza e quando usar cada

O problema

Quando tentei conectar meu primeiro domínio personalizado (meudominio.com.br) a um Cloudflare Worker (um pequeno programa que roda direto na nuvem da Cloudflare), dei de cara com várias colunas no painel de DNS: Type, Name, Content, e um botão de “Proxy status” com uma nuvenzinha que mudava entre as cores laranja e cinza.

Eu não tinha a menor ideia do que aquela nuvem fazia. Então, deixei como estava e segui em frente.

O resultado? O Worker não funcionou. Fiquei uma hora inteira achando que o problema era a propagação de DNS (aquele tempo normal que a internet leva para espalhar um endereço novo pelo mundo). Mas não era. O culpado era o tal interruptor da nuvem.

Este artigo é exatamente o guia que eu gostaria de ter lido no meu primeiro dia: o que é cada registro, quando usar a nuvem laranja (Proxied) ou a cinza (DNS only), e por que essa simples escolha define se o seu Worker vai funcionar ou ficar fora do ar.

A anatomia de um registro

Para apontar um site para serviços como o Cloudflare Worker ou Pages, você geralmente cria um registro do tipo CNAME (que funciona como um “apelido” ou atalho que aponta um endereço para outro):

Type: CNAME (o tipo de registro que cria esse “apelido”).
Name: o subdomínio que o seu visitante vai digitar no navegador (por exemplo: app para acessar app.meudominio.com.br, ou o símbolo @ para representar o seu domínio principal/raiz).
Content: o endereço de destino real que a Cloudflare gerou para você (exemplo: seu-projeto.pages.dev).

Até aqui é bem simples. O segredo (e a armadilha) está no tal Proxy status.

Nuvem laranja (Proxied) vs cinza (DNS only)

Trocar esse botão muda totalmente o caminho que a navegação do seu usuário vai fazer. É o erro mais comum de quem está começando.

Proxied (nuvem laranja)

Aqui, a Cloudflare funciona como um porteiro ou intermediário. O acesso do usuário vai primeiro para os datacenters da Cloudflare (a rede global de servidores deles) e, só depois de ser checado, é enviado internamente para o seu destino final.

Vantagens desse “porteiro”:

Esconde o seu endereço IP real (trazendo segurança contra ataques DDoS, que tentam derrubar seu site com acessos falsos).
Aplica regras de segurança (WAF), limites de acesso (rate limiting) e redirecionamentos de páginas.
Coloca o certificado de segurança SSL (o famoso “cadeado” do navegador) de forma automática e gratuita.
Guarda cópias (cache) de imagens e arquivos para seu site carregar bem mais rápido.

Regra obrigatória: se o seu endereço está apontando para um serviço da própria Cloudflare (como Workers ou Pages), a nuvem precisa estar laranja (Proxied). Se você desligar, a Cloudflare não consegue interceptar e organizar a rota lá dentro — e foi exatamente por isso que o meu primeiro Worker não respondeu. Deixar como DNS only em registros CNAME para .pages.dev ou .workers.dev simplesmente não vai funcionar.

DNS only (nuvem cinza)

Neste modo, o tráfego não passa por nenhum “porteiro”. A Cloudflare só informa o endereço e o visitante vai direto para o servidor final (o endereço que está em Content).

Quando você deve usar:

Serviços que não funcionam com intermediários de navegação web (HTTP), como servidores de e-mail (registros MX).
Quando você precisa acessar seu servidor diretamente via SSH ou FTP (ferramentas para comandar o servidor ou enviar arquivos), onde é necessário ver o IP real sem nada no caminho.
Serviços hospedados fora (exemplo: um servidor EC2 da AWS) onde você quer usar a Cloudflare apenas como um “catálogo de endereços” (DNS), sem a proteção do proxy deles.

Risco: o IP real do seu servidor fica totalmente exposto na internet. Para coisas que não são da Cloudflare, pode ser necessário — mas é preciso saber que você abre mão das proteções.

A regra prática que fixei

Para não errar mais, criei este resumo mental:

Apontando para Cloudflare Worker ou Pages? Nuvem laranja (Proxied). Sempre. Sem isso não roda.
Configurando registro MX (e-mail)? Nuvem cinza (DNS only). Sempre. O proxy estraga a entrega de e-mails.
Apontando para um servidor externo (EC2, VPS) e quer proteção/velocidade extra (CDN)? Nuvem laranja.
Apontando para um servidor externo onde precisa de acesso direto via SSH/FTP? Nuvem cinza.

A pergunta decisiva é: “O meu destino é um serviço da Cloudflare ou eu preciso de proteção e cache?” → Nuvem laranja. “O destino é externo e um intermediário vai quebrar a conexão?” → Nuvem cinza.

Nameservers (NS): a etapa que ninguém pula

Antes de qualquer uma das configurações acima funcionar, os servidores de nome (Nameservers ou NS — que são os servidores mestres que dizem quem cuida do seu domínio) precisam apontar para a Cloudflare. No painel da Cloudflare, lá embaixo, aparecem dois endereços (por exemplo: alec.ns.cloudflare.com e mira.ns.cloudflare.com).

Você precisa ir no painel onde comprou o seu domínio (como Registro.br, GoDaddy ou HostGator) e trocar os Nameservers padrão por esses dois da Cloudflare. Sem fazer essa troca, nada do que você configurar na Cloudflare vai funcionar, pois a internet continuará consultando a sua empresa antiga de domínios.

Assim que você salva essa alteração, a atualização costuma espalhar (propagar) em menos de 10 minutos na maioria dos casos. A partir daí, seu Worker estará acessível no seu endereço bonito e com o certificado de segurança (SSL) ativo.

Como verificar se a mudança funcionou: Abra o terminal do seu computador e digite dig NS meudominio.com.br +short. O comando deve mostrar os dois servidores NS da Cloudflare. Se ainda mostrarem os antigos, significa que você precisa aguardar mais um pouquinho.

O que aprendi

A maior lição que tirei de tudo isso é: botão que você ignora por não entender vira um problema no futuro. Eu deixei a opção do Proxy do jeito que veio porque achei que “já devia estar certo” — e acabei perdendo uma hora inteira achando que o site estava demorando para atualizar. Em painéis de tecnologia, cada opção tem uma consequência. Hoje, antes de salvar qualquer configuração de DNS, eu pergunto: o que essa opção faz? Se não sei, pesquiso. Isso me toma 2 minutos e me economiza horas de dor de cabeça.

E o segundo aprendizado: conectar seu domínio a um serviço externo funciona diferente de conectar a um serviço da própria Cloudflare. Quando o destino já é da Cloudflare (Workers/Pages), o proxy interno deles precisa estar ligado para fazer o roteamento dos dados lá dentro. Quando o destino é um servidor fora da Cloudflare, o proxy é opcional (e em alguns casos, proibido). Confundir essas duas situações é o erro mais comum de quem está aprendendo a mexer na Cloudflare.