Como Conectar um Site ao Cloudflare

Como Conectar um Site ao Cloudflare

O Cloudflare pode ficar na frente de um site de duas formas bem diferentes. Você pode mover todo o domínio para o DNS e o proxy do Cloudflare, ou pode manter uma configuração mais limitada e ativar apenas um recurso por vez. Se você está se perguntando como mudar o DNS para o Cloudflare, essa escolha muda os passos, o risco e o plano de reversão.

Comece por aí. Um site institucional com poucas páginas tem necessidades diferentes de um domínio corporativo com muito uso de e-mail, e um domínio que já sustenta um site de empresa exige um cuidado maior com os registros do que um lançamento totalmente novo. Se você também está pensando em segurança do site, o Cloudflare costuma entrar na conversa justamente por esse motivo primeiro, e entender como configurar o Cloudflare no site ajuda a evitar erros nessa etapa.

1. Decida se você precisa de controle total do DNS ou apenas de um recurso do Cloudflare

O Cloudflare não é um único botão. Ele pode gerenciar DNS, fazer proxy do tráfego web, armazenar conteúdo em cache, filtrar requisições e ficar entre os visitantes e o servidor de origem. Se você quer apenas um recurso, como gerenciamento de DNS ou uma camada de segurança, ainda assim precisa entender que os nameservers do domínio costumam ser o ponto em que o Cloudflare assume o controle.

Para um site simples de apresentação, o controle total geralmente funciona bem. Já em uma configuração com roteamento de e-mail, serviços de verificação e vários subdomínios, a decisão fica mais sensível. Uma infraestrutura de rede privada, por exemplo, pode precisar que certos hostnames fiquem fora do caminho do proxy, enquanto as páginas web podem passar pelo Cloudflare sem problemas.

Faça uma pergunta prática: o que precisa continuar funcionando no primeiro dia? Se a resposta inclui e-mail, callbacks de API ou fluxo de pagamento, você não está apenas “conectando um site ao Cloudflare”; está mudando a forma como o domínio é resolvido. Essa diferença importa.

Uma regra curta ajuda: não chute. Se o site depende de qualquer serviço fora do servidor web, liste tudo antes de tocar nos nameservers. Essa lista vira sua rede de segurança.

2. Faça uma auditoria da configuração atual do domínio antes de trocar os nameservers

Antes de mover qualquer coisa, verifique onde o DNS é gerenciado hoje. O registrador e o provedor de DNS nem sempre são a mesma empresa, e essa diferença gera erros evitáveis. Consulte os nameservers atuais e depois examine os registros da zona que existem lá.

Você precisa do quadro completo: registros A e AAAA para o site, registros CNAME para subdomínios, registros MX para e-mail, registros TXT para verificação e quaisquer registros incomuns usados por ferramentas de terceiros. A falta de um TXT pode quebrar um fluxo de login. Um MX errado pode interromper o e-mail.

Não confie na memória. Um domínio no ar há anos pode ter registros adicionados por pessoas diferentes em momentos diferentes, e alguns deles talvez nem estejam documentados em outro lugar. Se o responsável pelo site não consegue explicar um registro, isso é motivo para mantê-lo até entender para que serve.

Este também é o momento de listar redirecionamentos e hostnames antigos. Se o tráfego ainda chega por um subdomínio antigo, anote isso agora. Um redirecionamento que funciona na origem pode falhar depois se o hostname não tiver sido copiado para o Cloudflare.

Mantenha uma cópia da zona atual fora da conta do registrador. Um arquivo de texto simples basta. Uma planilha também serve. O objetivo é recuperação.

3. Crie o site no Cloudflare e importe os registros DNS existentes

Depois da auditoria, adicione o domínio ao Cloudflare. O Cloudflare vai verificar os registros DNS existentes e tentar importá-los para a zona dele. Essa varredura economiza tempo, mas não garante que tudo tenha sido importado corretamente.

Revise os registros importados linha por linha. Um registro pode estar ausente, um subdomínio pode estar duplicado ou um valor pode estar desatualizado. A primeira passada é sobre precisão, não velocidade. Se você ver um hostname que deveria apontar para o seu servidor web, mas agora aponta para outro lugar, corrija antes de tocar no registrador.

Dois testes simples pegam muitos erros. Primeiro, compare os registros importados com sua lista de auditoria. Segundo, confirme que o domínio raiz e o hostname comum “www” resolvem para o lugar certo. Esses são os registros que os usuários vão acessar primeiro.

Se você administra um site com comportamento de site corporativo, acompanhe os subdomínios de perto. Um portal de suporte, um hostname de homologação e um host de arquivos costumam ficar ao lado do site principal, e um único registro ausente já pode causar uma indisponibilidade difícil de diagnosticar.

Uma observação prática: a importação do Cloudflare ajuda, mas não substitui sua própria revisão. A varredura é um ponto de partida. Sua auditoria é a verificação final.

4. Escolha quais registros devem ficar com proxy e quais devem permanecer apenas em DNS

O Cloudflare oferece essa escolha em muitos registros. A nuvem laranja significa que o tráfego passa pelo proxy do Cloudflare. A nuvem cinza significa apenas DNS. Essa escolha não é estética. Ela muda o caminho das requisições.

O tráfego web do site público costuma ser proxied. Registros de e-mail, não. Registros de verificação, não. Alguns subdomínios que servem APIs ou ferramentas especializadas também devem permanecer apenas em DNS, a menos que você tenha testado o caminho completo com cuidado. Se quiser uma regra rápida, faça proxy do site e deixe os serviços não web em paz, a menos que haja um motivo para mudar.

Um erro comum é colocar tudo atrás do proxy porque fica “organizado”. Não fica organizado por muito tempo. Um registro MX atrás do proxy vai falhar. Um hostname de verificação pode deixar de ser reconhecido por outro serviço. Um endpoint de transferência de arquivos pode se comportar de forma estranha porque nunca foi feito para passar pelo proxy web.

Pense em função, não em aparência. O site pode usar proxy para desempenho e segurança. O e-mail geralmente deve permanecer apenas em DNS. Se sua configuração inclui pixels de rastreamento, webhooks ou hosts de verificação de terceiros, teste cada um separadamente.

O tráfego que precisa continuar sendo DNS puro muitas vezes é justamente o que você menos quer quebrar. Guarde essa frase antes de clicar na nuvem laranja muitas vezes.

5. Atualize os nameservers do domínio no seu registrador

O Cloudflare vai atribuir dois nameservers ao domínio. Você substitui os nameservers atuais no registrador por esses dois valores. Este é o passo que entrega a autoridade do DNS ao Cloudflare, então copie exatamente como foi mostrado.

No registrador, encontre a seção de nameservers e remova o par antigo. Depois insira o par atribuído pelo Cloudflare. Salve a alteração.

Não entre em pânico se o site não mudar imediatamente. Alterações de DNS não são sincronizadas em um único relógio. Um visitante ainda pode chegar pelo caminho antigo por um tempo, e isso é normal. Se o host DNS antigo continuar ativo durante a transição, você reduz o risco de falhas de resolução.

Uma frase curta aqui: seja exato. Um único caractere errado no nameserver pode impedir o funcionamento da delegação.

Também não altere mais de uma coisa ao mesmo tempo. Se você renomear registros, trocar de host e editar os nameservers na mesma sessão, a resolução de problemas fica muito mais difícil do que precisa ser.

6. Confirme que o domínio está ativo no Cloudflare e teste caminhos reais de tráfego

Depois da troca dos nameservers, o Cloudflare deve mostrar o domínio como ativo. Se isso não acontecer, o problema geralmente é um destes três: a mudança no registrador não foi salva, os nameservers foram inseridos incorretamente ou o registrador ainda está com dados em cache. Verifique isso antes de culpar o servidor de origem.

Depois teste caminhos reais, não apenas a página inicial. Abra o domínio principal, a versão “www”, uma subpágina importante e quaisquer subdomínios relevantes. Se o site tiver uma página de login, teste também. Se houver download de arquivo ou envio de formulário, teste essas ações. As páginas podem carregar enquanto um endpoint escondido está quebrado.

É aqui que uma ferramenta de monitoramento ajuda. Se você usa uma plataforma de análise e monitoramento de sites, compare as primeiras requisições ao vivo após a troca com o padrão normal. Um aumento repentino de erros em um hostname costuma ser o primeiro sinal de que um registro DNS ou uma configuração de proxy precisa de atenção.

Use outro navegador ou uma janela anônima para um teste limpo. Dados em cache podem esconder problemas. Uma sessão antiga de login também.

Se algo falhar, teste o caminho do domínio para fora: DNS, resposta da borda, resposta da origem e depois a lógica da aplicação. Essa ordem economiza tempo.

7. Configure as primeiras opções seguras do Cloudflare para uma nova conexão

Quando o domínio estiver ativo, mantenha as primeiras configurações conservadoras. Escolha um modo SSL/TLS que corresponda ao que a sua origem realmente suporta e não adivinhe. Se o certificado da origem não estiver pronto, o navegador pode mostrar erros ou o Cloudflare pode recusar a conexão. Isso seria uma surpresa ruim no dia do lançamento.

As configurações básicas de segurança devem ser o próximo passo. Se você já se preocupa com a segurança do site, é aqui que o Cloudflare começa a ajudar além do DNS. Comece pelos controles óbvios e teste o site de novo. Ajustes agressivos podem esperar até você confirmar que a base está funcionando corretamente.

O comportamento de cache também merece uma análise inicial cuidadosa. Uma página que muda com frequência não deve ser tratada da mesma forma que uma página que quase não muda. Se você não tiver certeza, mantenha o comportamento padrão primeiro, observe como o site responde e depois faça uma mudança por vez.

Um hábito útil é separar “seguro agora” de “bom depois”. Seguro agora inclui acertar o caminho do SSL e confirmar que o site ainda abre. Bom depois inclui ajustar cabeçalhos de cache ou endurecer regras depois que você tiver logs para analisar. Essa ordem evita indisponibilidades causadas por você mesmo.

Mantenha esta fase pequena. Mudanças pequenas são mais fáceis de desfazer.

8. Verifique casos especiais: e-mail, subdomínios, redirecionamentos e problemas de conteúdo misto

É aqui que muitos sites tropeçam. O e-mail geralmente depende de registros DNS que devem continuar apenas em DNS. Verifique se os registros MX ainda apontam para o host correto e se os registros TXT de SPF, DKIM ou DMARC foram preservados. Se o e-mail parar, o site pode continuar aparentemente normal enquanto mensagens de negócio desaparecem.

Subdomínios merecem sua própria lista de verificação. Um hostname de homologação, um host de imagens e um endpoint de upload podem precisar de tratamentos diferentes. Se um deles foi proxied por engano, você pode ver comportamento estranho apenas naquele hostname. Esse tipo de bug consome tempo porque a página inicial funciona.

Os redirecionamentos também podem expor erros. Se o site antigo enviava visitantes de um hostname para outro, teste esse caminho novamente depois da troca. Uma cadeia de redirecionamento que antes funcionava pode agora apontar para um hostname que nunca foi adicionado ao Cloudflare. Um único registro ausente pode quebrar o caminho inteiro.

Problemas de conteúdo misto aparecem quando o site carrega alguns recursos por HTTP enquanto a página em si é servida por HTTPS. Os navegadores não gostam dessa combinação. Imagens podem sumir, scripts podem falhar e um formulário pode parar de ser enviado. Corrija as URLs na origem da aplicação, e não apenas no navegador.

Se o seu domínio sustenta um fluxo de suporte ao site após o lançamento, mantenha uma lista curta dos hosts mais frágeis: e-mail, homologação, uploads, redirecionamentos e verificação de terceiros. Essas cinco áreas são onde os primeiros chamados costumam aparecer.

Uma última verificação prática: teste o site a partir de uma rede que você normalmente não usa. Uma conexão móvel pode revelar um problema de cache ou um atraso de DNS que a rede do escritório esconde. Caminhos diferentes mostram problemas diferentes.

E, se você estiver conectando um site que já tem exigências operacionais rígidas, documente todos os registros DNS que você alterou. Não depois. Agora.