Corrigir um domínio personalizado que não funciona
Por que um domínio personalizado não verifica ou para de servir links — proxy da Cloudflare, CAA, DNS conflitante, cache e a suspensão aos 30 dias.

Um domínio personalizado que não verifica quase sempre tem uma entre seis causas. Esta página percorre todas na ordem em que vale conferir, com o comando que diz qual delas é a sua.
Disponibilidade
- Plano: Starter ou superior.
- Onde: Domínios, na barra lateral, e o botão Atualizar no card do domínio.
Comece por aqui
Pergunte à internet para onde o seu domínio resolve, de fora da sua própria rede:
dig +short go.example.com CNAME dig +short example.com A dig +short _vercel.example.com TXT
Um subdomínio deve responder cname.codeqr.io., um domínio raiz deve responder 76.76.21.21, e o registro TXT deve devolver o valor vc-domain-verify=… exibido no card. Qualquer outra coisa é o problema, e as seções abaixo dão nome a ele.
O proxy da Cloudflare está ligado
A causa mais comum, com folga. Se o seu DNS está na Cloudflare e o registro está com a nuvem laranja ativada, a Cloudflare responde pelo seu domínio com os endereços dela. A verificação nunca enxerga o registro que você criou, e o domínio fica preso em verificação pendente ou em Invalid Configuration para sempre.
Correção: abra o registro na Cloudflare e mude o status do proxy para DNS only — a nuvem cinza. O valor do registro continua o mesmo.
Sintomas que já apontam para cá: o dig devolve dois endereços que não são 76.76.21.21, ou o site abre uma página de erro da Cloudflare — 526, 525 ou 1014. Um laço de redirecionamento terminando em ERR_TOO_MANY_REDIRECTS é da mesma família, causado pelo modo SSL Flexible; Full (strict) é a configuração que funciona com uma origem que tem certificado próprio.
Um registro CAA está bloqueando o certificado
O domínio resolve certo, mas o https:// nunca começa a funcionar. Se a emissão do certificado falha com uma mensagem citando CAA — CAA record for example.com prevents issuance — o domínio tem um registro CAA listando quais autoridades certificadoras podem emitir para ele, e a usada aqui não está na lista.
dig +short example.com CAA
Correção: se o comando não devolver nada, CAA não é o seu problema — a ausência de CAA autoriza qualquer autoridade. Se devolver entradas, acrescente letsencrypt.org a elas. Repare que CAA é herdado: um registro em example.com também vale para go.example.com.
O domínio já está em uso em outro lugar
Um domínio fica ligado a um lugar por vez na infraestrutura. Se ele já estiver conectado a outra conta, a verificação é recusada até que a propriedade mude — que é exatamente o papel do registro TXT _vercel. A interface mostra "O domínio já está em uso." quando isso acontece.
Correção: crie o registro TXT exibido no card, na raiz do domínio, e selecione Atualizar. Se o domínio hoje serve um site na mesma infraestrutura, aja com cuidado: essa transferência tira o domínio daquele site.
Existe um registro conflitante
Um nome de host não pode ter um CNAME ao lado de um A, um AAAA ou outro CNAME. Muitos provedores aceitam os dois em silêncio e depois servem o errado.
Correção: apague todos os outros registros daquele nome exato, mantenha o de Apontar seu domínio com CNAME ou registro A e confira com o dig que só volta uma resposta.
Você está vendo uma resposta em cache
O registro está certo, o dig da máquina de um colega concorda, e o seu navegador continua caindo em outro lugar. Os servidores guardam a resposta anterior pelo tempo que o TTL dela mandou, e a sua própria máquina guarda mais uma vez por cima.
Correção: espere — o teto é o TTL antigo, não um número fixo de horas. Para conferir sem o seu cache no caminho, pergunte a um servidor público:
dig +short go.example.com CNAME @1.1.1.1
O registro está certo e os links continuam sem abrir
Dois detalhes pegam gente aqui:
- O ponto final. Alguns painéis exigem
cname.codeqr.io.e outros recusam. Siga o formato que os demais registros da sua zona já usam. - Domínio com acento ou fora do alfabeto latino. Ele precisa ser informado na forma punycode (
xn--…), que é como o registrador exibe no arquivo de zona.
O que acontece se continuar quebrado
A CodeQR confere os domínios configurados a cada hora. Se um domínio permanece inválido, todo mundo do espaço de trabalho recebe um e-mail aos 14 dias e outro aos 28. Aos 30 dias o domínio é suspenso e marcado para revisão manual.
A suspensão não apaga nada. O domínio, os links, os QR codes e as estatísticas continuam onde estão, e corrigir o registro de DNS limpa o estado na verificação seguinte. O e-mail é mais assustador que o comportamento — ele diz que o domínio será excluído, o que não é o que acontece.
Verifique se funcionou
curl -sSI https://go.example.com/verao
HTTP/2 302 location: https://example.com/cardapio
Se vier um 302 com o seu destino, o domínio está saudável, independentemente do que qualquer painel diga. Um 404, uma página de erro da Cloudflare ou um aviso de certificado remetem a alguma seção acima.
Solução de problemas
O status diz Invalid Configuration
O DNS responde, mas com o valor errado. Compare o que o dig devolve com o registro exibido no card. O proxy da Cloudflare é a primeira hipótese a descartar.
Os links do domínio pararam de funcionar de repente
Algo mudou no DNS: uma migração de zona, uma troca de servidores de nomes no registrador ou um registro apagado durante uma manutenção sem relação. Recrie o registro e selecione Atualizar.
Meu domínio venceu no registrador
Nada na CodeQR compensa isso — o domínio deixou de resolver para todo mundo. Renove, e os links voltam quando o DNS voltar. Se o domínio se perdeu de vez, leia Trocar ou remover um domínio sem perder os links antes de mexer no espaço de trabalho.
Está tudo certo e mesmo assim não verifica
Use Atualizar em vez de recarregar a página, e espere alguns minutos entre as tentativas. Verificações repetidas em pouco tempo podem ser limitadas do outro lado, e isso aparece como uma checagem que falha sem motivo visível.