A maioria dos sites agora opera com dual-stack. O mesmo servidor, API ou página de checkout responde tanto via IPv4 quanto IPv6 ao mesmo tempo. Essa configuração mantém você acessível à medida que os endereços IPv4 se tornam escassos, mas também divide seu tráfego entre duas redes que falham de forma independente.
Aqui está o problema que isso cria. Se seu monitoramento testar apenas via IPv4, ele reporta verde enquanto os usuários nativos IPv6 enfrentam um gateway inacessível, um registro DNS ausente ou uma regra de firewall que nunca foi atualizada. O painel mostra 100% de uptime. Uma parcela crescente do seu público diz que o site está quebrado.
Este artigo explica como a Dotcom-Monitor testa o caminho IPv6 em seus próprios termos: nós nativos somente IPv6 sem tunelamento, scripts em navegador que carregam todos os recursos de terceiros via IPv6 e verificações de protocolo que isolam uma falha IPv6 enquanto o caminho IPv4 permanece limpo.
O que é Monitoramento IPv6?
Monitoramento IPv6 é a prática de testar se seu site, API e serviços respondem corretamente pelo IPv6, do ponto de vista de um usuário real IPv6. Ele executa as mesmas verificações de disponibilidade e desempenho que você já usa no IPv4 — resolução DNS, carregamento de páginas, transações e respostas de protocolo — mas pelo caminho IPv6, que tem seus próprios registros DNS, rotas e regras de firewall.
Em um site dual-stack que serve ambos os protocolos, o monitoramento IPv6 é a única forma de confirmar que a metade IPv6 funciona. Um teste IPv4 passa independentemente da saúde do IPv6, então sem um teste de monitoramento dedicado para IPv6, uma interrupção que afeta somente usuários IPv6 permanece invisível. As seções abaixo mostram como a Dotcom-Monitor executa essa verificação a partir de nós nativos somente IPv6, cobrindo uptime, transações, DNS e verificações de protocolo em ambas as redes.
Por que Redes Dual-Stack Criam um Ponto Cego de Monitoramento
Um serviço dual-stack responde em dois protocolos, mas IPv4 e IPv6 não compartilham o mesmo caminho. São dois planos de roteamento. O tráfego resolve através de diferentes registros DNS, passa por diferentes regras de firewall e circula por diferentes provedores de trânsito antes de chegar à mesma origem.
Então, uma requisição pode ter sucesso em um plano e falhar no outro. O cliente IPv4 resolve seu registro A, passa por um firewall IPv4 que sua equipe já ajustou por anos e carrega a página. O cliente IPv6 resolve seu registro AAAA, atinge um gateway nunca totalmente configurado e esgota o tempo. Ambos os usuários digitam a mesma URL. Um deles acha que seu site está fora do ar.
Os dois planos diferem por dentro também. IPv6 usa um cabeçalho base fixo de 40 bytes, um campo Traffic Class de 8 bits e um Flow Label de 20 bits, então os roteadores de trânsito tratam os pacotes IPv6 de forma diferente do modelo best-effort IPv4 que existe há décadas. E uma única sub-rede IPv6 contém muito mais endereços do que toda a internet IPv4 legada, o que altera como rotas se propagam e os filtros são aplicados. O ponto para o monitoramento é simples: um resultado IPv4 não diz nada confiável sobre o caminho IPv6. Você precisa testar cada um onde ele vive.
Como a Dotcom-Monitor Executa Monitoramento Nativo Somente IPv6
A Dotcom-Monitor executa suas verificações de uma rede global de monitoramento com nós em backbones reais IPv4 e IPv6. Alguns desses nós são dual-stack e podem acessar um alvo via qualquer protocolo. Outros são somente IPv6.
As localizações somente IPv6 são a parte que importa aqui, por causa do que elas se recusam a fazer. Muito do equipamento de rede que suporta IPv6 também pode traduzir o tráfego de volta para IPv4 usando mecanismos de transição como tunelamento 6to4 ou NAT64. Essa tradução é conveniente em produção e enganosa em um teste. Um agente dual-stack pode reportar um resultado limpo enquanto silenciosamente recua para IPv4, ocultando a falha exata que você está tentando encontrar.
Um nó somente IPv6 não usa tradução. Ele envia e recebe somente IPv6. Quando uma verificação passa a partir desse nó, o alvo realmente respondeu via IPv6 nativo. Quando falha, você detectou uma falha real no IPv6 em vez de um fallback disfarçando uma.
Executar a mesma verificação de um nó nativo IPv4 e de um nó nativo somente IPv6 te dá um antes e depois limpo para cada plano. Qualquer diferença entre os dois resultados é um problema específico do IPv6, não ruído de medição.
Essa linha de base dividida funciona em todos os tipos de dispositivos da plataforma. O monitoramento Web Applications dirige um navegador real por uma transação scriptada. O monitoramento Web Pages carrega uma única página da mesma forma. O monitoramento Internet Infrastructure executa verificações de protocolo contra seus servidores. E o monitoramento Web Services valida suas APIs. Todos podem ser configurados em locais somente IPv6, e os dois dispositivos de navegador gravam com a ferramenta de script EveryStep, para que você capture um caminho uma vez e o reproduza a partir de qualquer nó.
Detectando Fantasmas AAAA de Terceiros com Monitoramento em Navegador Real
Sua origem pode suportar IPv6 perfeitamente e suas páginas ainda podem falhar para usuários IPv6. A razão é tudo o que você não hospeda. Uma página moderna puxa um CDN, fontes web, uma tag de analytics, um widget de chat e um processador de pagamento. Quando um usuário só IPv6 carrega essa página, o navegador tenta buscar cada um desses recursos via IPv6 também.
Se um terceiro nunca publicou um registro AAAA ou descarta pacotes IPv6, o navegador trava nesse recurso. Ele espera a conexão expirar, e pode paralisar o restante do carregamento enquanto espera. O resultado visível é uma página parcialmente renderizada: navegação ausente, quadros de recursos vazios, botão de checkout que nunca funciona. Seu painel interno de saúde permanece verde o tempo todo, porque sua origem está ok. A falha está na rede de outra pessoa.
O monitoramento Web Applications detecta isso carregando a página completa em um navegador real a partir de um nó somente IPv6 e gravando cada requisição no waterfall. Para uma única página em vez de uma transação completa, o monitoramento Web Pages funciona igual. Em vez de dar apenas um aprovado/reprovado, você vê qual recurso específico resolveu, qual expirou e onde o carregamento travou. A tabela abaixo mostra o padrão que ele revela.
| Perfil de teste | HTML principal | Recursos CDN e mídia | Scripts de terceiros | O que o usuário vê |
|---|---|---|---|---|
| Monitoramento IPv4 | Resolve (registro A) | Resolve | Resolve | Página completa carrega normalmente. |
| Monitoramento somente IPv6 | Resolve (registro AAAA) | Falha ao resolver | Expira | Carregamento parcial: layout quebrado, quadros vazios, checkout travado. |
Considere um fluxo de checkout como exemplo. Um script do Web Applications faz login, adiciona um item e chega à etapa de pagamento. Via IPv4 o caminho todo passa. A partir do nó somente IPv6, o script do processador de pagamento não tem registro AAAA, então o navegador trava antes do formulário ficar utilizável. O script falha nessa etapa e indica qual recurso causou o problema. Um ping de uptime no seu próprio domínio nunca teria detectado o problema no checkout. Scriptar a transação com monitoramento sintético transforma “o site está no ar” em “os clientes realmente podem pagar.”
Como o Monitoramento de Infraestrutura de Internet Isola Falhas de Protocolo IPv6
Verificações em navegador capturam o que os usuários veem. Você também precisa da camada abaixo. O monitoramento Internet Infrastructure executa verificações de protocolo contra seus servidores, tão frequentemente quanto uma vez por minuto, e realiza essas verificações a partir de locais somente IPv6 da mesma forma que os dispositivos de navegador.
Essa frequência e esse isolamento são a parte útil. Se seu endpoint HTTP/S ou DNS responde via IPv4 mas falha via IPv6, o monitoramento Internet Infrastructure reporta o erro de protocolo IPv6 isoladamente em vez de diluí-lo junto ao resultado saudável IPv4. O monitoramento Web Services faz o mesmo para seus endpoints de API. Você recebe um alerta com o nome do protocolo e do caminho, não um genérico “tempo de resposta aumentou.”
DNS merece uma verificação dedicada. Um site dual-stack precisa que ambos registro A e AAAA resolvam globalmente com velocidade similar, e um registro AAAA desatualizado ou faltante é uma das falhas IPv6 mais frequentes. O monitoramento DNS confirma que ambos os registros respondem em todos os lugares e monitora valores de TTL para que uma mudança de rota durante uma migração não deixe usuários IPv6 presos a uma entrada inválida. Quando um alerta dispara, um traceroute IPv6 automático mostra se a queda está na sua origem ou dentro da tabela de roteamento de um provedor de trânsito a montante.
Como a Dotcom-Monitor Expõe Latência do Happy Eyeballs
Alguns problemas IPv6 nunca aparecem como uma interrupção. Eles aparecem como um site lento por razões que ninguém consegue identificar. A causa é frequentemente o Happy Eyeballs.
Happy Eyeballs (RFC 8305) é um fallback do navegador. O navegador inicia sua conexão IPv6 primeiro, depois aguarda um curto intervalo (o atraso da tentativa de conexão, cerca de 250 milissegundos por padrão) antes de também tentar competir via IPv4. Se o caminho IPv6 estiver quebrado ou lento, a tentativa IPv4 vence e carrega a requisição. A conexão ainda consegue ser feita, então o usuário raramente vê um erro.
Isso é bom para o usuário e ruim para sua visibilidade. A espera antes do navegador desistir do IPv6 e usar IPv4 é somada ao tempo real até o Primeiro Byte e ao Maior Conteúdo Visível. Cada usuário IPv6 paga essa taxa de latência em uma conexão que eventualmente funciona via IPv4. Ferramentas passivas e análises de usuários reais registram o carregamento bem-sucedido e seguem adiante, então a falha estrutural permanece invisível enquanto a experiência degrada silenciosamente.
Monitoramento nativo somente IPv6 mede essa taxa diretamente, porque o fallback não está disponível para se esconder atrás. O caminho IPv6 ou funciona ou não, e o número aparece no relatório. Relatórios em waterfall lado a lado mostram os tempos IPv4 e IPv6 um ao lado do outro, assim uma diferença de 250 milissegundos que os usuários sentem mas não sabem explicar vira uma linha que você pode apontar. Se quiser uma revisão para ler esses gráficos, veja nosso guia sobre gráficos waterfall.
Como Configurar Monitoramento Dual-Stack no Dotcom-Monitor
Aqui está a configuração que oferece ambos os planos sem dobrar seu trabalho de manutenção.
- Passo 1: Crie a verificação uma vez no EveryStep. Grave seu caminho crítico ou verificação de protocolo uma única vez. O mesmo script EveryStep roda em todas as localidades, então você não mantém versões separadas IPv4 e IPv6.
- Passo 2: Atribua locais nativos IPv4 e somente IPv6. Adicione a verificação tanto a um nó nativo IPv4 quanto a um nó somente IPv6. Evite locais 6to4 e NAT64 para a linha de base IPv6, assim nenhuma tradução fica entre o nó e seu alvo.
- Passo 3: Ajuste a frequência das verificações. Execute verificações de protocolo Internet Infrastructure até uma vez por minuto. Agende verificações de navegador Web Applications na frequência que seu SLA exigir.
- Passo 4: Adicione verificações DNS para registros A e AAAA. Confirme que ambos os registros resolvam globalmente em velocidades semelhantes e monitore valores de TTL para que uma migração não deixe usuários IPv6 presos a uma rota desatualizada.
- Passo 5: Dispare um traceroute IPv6 em caso de desvio. Configure alertas para acionar um traceroute no momento em que a disponibilidade ou tempo de resposta cair, para que você possa separar imediatamente uma falha na origem de uma falha em um provedor de trânsito a montante.
- Passo 6: Compare os dois gráficos waterfall. Analise os relatórios IPv4 e IPv6 lado a lado. Qualquer recurso, salto ou protocolo que diferir entre eles é seu problema específico IPv6.
Conclusão
Dual-stack significa que cada requisição tem dois caminhos para te alcançar e duas formas de falhar. Monitoramento apenas IPv4 observa um deles e reporta sobre ambos, que é como um site pode ter um recorde perfeito de uptime enquanto usuários IPv6 enfrentam timeouts, páginas parcialmente carregadas e uma penalidade de latência que ninguém consegue rastrear.
A Dotcom-Monitor fecha essa lacuna testando o caminho IPv6 em seus próprios termos. Nós nativos só IPv6 sem tunelamento, scripts de navegador Web Applications que carregam todos os recursos de terceiros via IPv6, verificações de protocolo Internet Infrastructure com até uma vez por minuto, e relatórios waterfall lado a lado que separam falhas de origem e de provedores a montante. Você para de adivinhar sobre a metade do seu tráfego que testes IPv4 nunca alcançaram.
Teste Seu Caminho IPv6 Antes de Seus Usuários
Implemente nós nativos somente IPv6 e veja exatamente o que seus usuários dual-stack experimentam, até o recurso de terceiros. Comece um teste gratuito de 30 dias com a Dotcom-Monitor.
