A maioria dos times que migra para o Cloudflare trata a escolha entre nuvem laranja e nuvem cinza como detalhe de configuração. Ativam o proxied para tudo, assumem que mais proteção é sempre melhor, e descobrem o erro semanas depois quando um banco de dados começa a retornar timeout sem mensagem de erro nenhuma — ou quando percebem que o IP de origem sempre esteve exposto nos registros que realmente importavam.
O que o modo proxied realmente faz
Quando um registro A ou CNAME está no modo proxied, o DNS autoritativo do Cloudflare não devolve o IP do seu servidor de origem. Ele devolve um IP anycast da própria Cloudflare. O cliente conecta a um dos edge nodes da rede, que termina o TLS, inspeciona a requisição e só então encaminha o tráfego para o seu servidor — opcionalmente com cache ativado, com regras de WAF aplicadas, com Workers interceptando a requisição no meio do caminho.
O IP real do servidor fica oculto do DNS público. Qualquer consulta externa ao registro retorna IPs da Cloudflare, não os seus. Isso tem implicações concretas: um atacante que queira contornar o WAF precisaria descobrir o IP de origem por outro meio — logs vazados, certificados TLS históricos no crt.sh, cabeçalhos de e-mail, ou conexões diretas a serviços auxiliares que ficaram expostos sem proxy.
O TTL visível externamente é sempre 300 segundos, independentemente do que estiver configurado internamente na zona. O Cloudflare controla o que os resolvers externos recebem e cacheiam — a configuração interna serve apenas para sincronização entre os próprios nameservers da Cloudflare.
O que o modo DNS only entrega
Com o ícone cinza, o Cloudflare funciona exclusivamente como DNS autoritativo. A consulta ao nome retorna o IP real do servidor. Não há terminação de TLS no edge, não há WAF, não há cache, não há Workers no caminho. O cliente conecta diretamente ao servidor de origem — e o Cloudflare nunca vê o tráfego.
Para registros MX essa ausência de proxy é obrigatória. O fluxo de entrega de e-mail exige que os servidores remetentes conectem diretamente ao servidor de e-mail indicado no registro MX. Se o registro MX tentasse passar pelo proxy do Cloudflare, o SMTP chegaria a um edge node que não sabe o que fazer com tráfego na porta 25 — e o e-mail simplesmente não chegaria. O Cloudflare sequer permite ativar proxy em registros MX; o padrão é DNS only e não pode ser alterado.
O mesmo se aplica a qualquer serviço TCP que não seja HTTP ou HTTPS nas portas suportadas. O Cloudflare proxy entende HTTP/HTTPS nas portas 80 e 443 e em um conjunto restrito de portas alternativas documentadas — 8080, 8443, e algumas outras. Tudo fora desse conjunto é invisível para o proxy.
A armadilha do banco de dados atrás de um registro proxied
Esse é o cenário que mais aparece silenciosamente em incidentes. Um registro A aponta para um servidor que roda MySQL na porta 3306. O time ativa o modo proxied porque "queremos mais proteção". O cliente tenta conectar na porta 3306 — mas agora está conectando ao edge node da Cloudflare, que não roteia tráfego TCP arbitrário. A conexão abre, espera, e fecha por timeout. Não há mensagem de erro clara. O MySQL nem chega a ver a tentativa de conexão.
O mesmo acontece com PostgreSQL na porta 5432, com Redis na porta 6379, com qualquer protocolo binário que não seja HTTP. O proxy simplesmente descarta o tráfego que não consegue interpretar. Para expor esses serviços, o registro precisa estar no modo DNS only — e a consequência direta é que o IP do servidor fica visível publicamente.
Registros de subdomínio para SSH direto também pertencem a essa categoria. Se o time mantém um registro ssh.exemplo.com apontando para um servidor de bastion, ele precisa ser DNS only. Proxied vai quebrar a conexão da mesma forma.
Auditando o que está exposto na sua zona
A pergunta que vale fazer periodicamente é simples: quais registros da zona estão no modo DNS only, e o tráfego que passa por eles está protegido de alguma outra forma?
Registros DNS only expõem IPs que podem ser usados para atacar a origem diretamente, ignorando qualquer regra de WAF configurada nos registros proxied. Se um servidor aparece tanto em um registro proxied quanto em um registro DNS only diferente — ou se o IP foi exposto em algum momento no passado e está indexado em serviços como o Shodan — o efeito protetor do proxy é parcial.
Para eliminar completamente a exposição do IP de origem em serviços HTTP, o Cloudflare Tunnel resolve o problema de forma definitiva. O servidor de origem estabelece uma conexão de saída para a rede do Cloudflare usando o daemon cloudflared. O tráfego dos usuários chega ao edge, percorre o túnel até o servidor, e o servidor nunca precisa aceitar conexões de entrada — não há porta aberta, não há IP exposto. Para tráfego TCP arbitrário fora do HTTP, o Cloudflare Spectrum cobre esse cenário, mas é exclusivo do plano Enterprise.
O que revisar antes de considerar a configuração encerrada
Zonas que crescem ao longo do tempo acumulam registros criados em contextos diferentes, por pessoas diferentes, com intenções que às vezes não estão documentadas. Um wildcard *.exemplo.com no modo proxied é legítimo e útil para subdomínios criados dinamicamente — mas pode mascarar o fato de que registros específicos dentro desse wildcard foram criados manualmente como DNS only por razões que ninguém lembra mais.
Registros TXT e CAA nunca são proxied — são dados que os clientes precisam ler diretamente, e o Cloudflare não interfere. SRV e NS também ficam fora do proxy. Nesses casos a interface nem apresenta a opção.
A configuração de proxied ou DNS only não é uma decisão tomada uma vez durante a migração. Ela precisa ser revisada quando novos serviços são expostos, quando a topologia de servidores muda, e especialmente quando um IP de origem muda — porque o valor anterior pode continuar circulando em caches ou em registros paralelos que ninguém notou que também precisavam ser atualizados.
Leia também
- DNSSEC com Cloudflare: o que protege, o que não protege e como ativar sem problemas
- Cloudflare Load Balancing e Geo Steering: quando o DNS vira camada de tráfego inteligente
- Cloudflare DNS: infraestrutura de rede que vai muito além de resolver nomes
- Cloudflare Email Routing: receber email no seu domínio — e o que não vem junto
- Cloudflare WAF: o que a proteção gerenciada realmente bloqueia e o que passa
- WAF + Rate Limiting + Bot Management: a trifeta de proteção no edge