Diagnóstico de DNS no Windows quando o NSLOOKUP funciona, mas o navegador não abre o site. — O nslookup pode resolver um domínio corretamente mesmo quando o navegador apresenta falhas causadas por DoH, VPN, IPv6, proxy ou outras etapas da conexão.

70 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Você abre o navegador, digita o endereço de um site e recebe uma mensagem informando que a página não pode ser acessada. A primeira suspeita é o DNS.

Para verificar, abre o Prompt de Comando e executa:

nslookup exemplo.com

O resultado mostra um endereço IP normalmente.

Então surge uma conclusão aparentemente lógica:

“Se o nslookup encontrou o endereço IP, o DNS está funcionando. Portanto, o problema não pode ser DNS.”

Só que o diagnóstico não é tão simples.

O nslookup conseguir resolver um domínio comprova que aquela consulta realizada pelo nslookup recebeu uma resposta. Isso não garante, sozinho, que o navegador esteja chegando ao mesmo resultado, usando exatamente o mesmo mecanismo de resolução ou sequer falhando na etapa de DNS.

Em computadores modernos podemos ter simultaneamente:

cache DNS do Windows;
servidores DNS configurados no adaptador;
arquivo hosts;
DNS over HTTPS (DoH);
recursos de DNS seguro do navegador;
VPN;
proxy;
IPv4 e IPv6;
políticas corporativas;
caches mantidos por aplicações;
diferentes endereços entregues para um mesmo domínio.

Por isso, este artigo da VMIA parte de uma situação aparentemente contraditória:

o nslookup funciona, mas o site não abre.

Nosso objetivo não será simplesmente executar ipconfig /flushdns e esperar que tudo se resolva. Vamos descobrir quem está resolvendo o domínio, qual endereço está sendo obtido e em qual etapa a comunicação realmente está falhando.

Primeiro: o que o DNS realmente faz?

Antes de comparar Windows e navegador, precisamos entender a função do DNS.

Quando você digita:

vmia.com.br

o computador precisa descobrir qual endereço está associado àquele nome.

De maneira simplificada:

vmia.com.br
      ↓
     DNS
      ↓
endereço IP

Isso permite que aplicações trabalhem com nomes compreensíveis para pessoas enquanto a comunicação de rede utiliza endereços IP.

Porém, essa representação simplificada esconde várias etapas.

Uma consulta pode envolver:

Aplicação
   ↓
Sistema operacional
   ↓
Cache
   ↓
Resolvedor DNS
   ↓
Servidor DNS recursivo
   ↓
Infraestrutura DNS
   ↓
Resposta

Dependendo da aplicação e da configuração, nem sempre todas essas etapas são exatamente iguais.

Resolver o domínio não significa acessar o site

Essa distinção é essencial.

Suponha que:

nslookup exemplo.com

retorne:

Nome: exemplo.com
Address: 203.0.113.50

Isso demonstra que houve uma resposta DNS para aquela consulta.

Mas, para abrir uma página HTTPS, ainda precisamos de outras etapas.

Simplificando:

Nome do site
↓
DNS
↓
Endereço IP
↓
Rota
↓
Conexão com o servidor
↓
TCP ou QUIC
↓
TLS
↓
HTTP
↓
Conteúdo

Portanto, o site pode não abrir mesmo quando o DNS está funcionando perfeitamente.

A falha pode estar em:

roteamento;
firewall;
porta 443;
proxy;
TLS;
certificado;
servidor;
CDN;
VPN;
IPv4;
IPv6;
MTU;
navegador.

A primeira regra deste diagnóstico é:

nslookup funcionando não significa que o site está acessível.

O que exatamente o NSLOOKUP testa?

O nslookup é uma ferramenta utilizada para consultar informações do DNS.

No Windows, podemos executar:

nslookup vmia.com.br

O resultado normalmente mostra o servidor DNS utilizado para a consulta e os registros encontrados.

Também podemos perguntar diretamente a um servidor específico.

Por exemplo:

nslookup vmia.com.br 1.1.1.1

Nesse caso, estamos pedindo explicitamente uma resposta ao servidor informado.

Também poderíamos consultar outro resolvedor:

nslookup vmia.com.br 8.8.8.8

Isso cria uma possibilidade muito útil de diagnóstico:

comparar respostas de diferentes resolvedores DNS.

Mas existe um cuidado importante.

Se você utiliza um DNS específico no nslookup, não está necessariamente reproduzindo a mesma consulta que o navegador realizará.

O navegador precisa obrigatoriamente usar o mesmo DNS?

Não em todos os cenários.

Historicamente, aplicações dependiam fortemente do resolvedor fornecido pelo sistema operacional.

Hoje, a situação pode ser mais complexa.

Navegadores modernos podem oferecer recursos como:

DNS seguro

ou:

DNS over HTTPS — DoH

Nesse modelo, consultas DNS podem ser transportadas através de HTTPS para um resolvedor compatível.

Assim, dependendo das configurações, podemos encontrar algo conceitualmente parecido com:

Windows
↓
DNS configurado no adaptador
↓
Servidor A

enquanto o navegador pode utilizar:

Navegador
↓
DNS over HTTPS
↓
Servidor B

Agora temos duas consultas potencialmente seguindo caminhos diferentes.

O que é DNS over HTTPS?

O DNS over HTTPS, abreviado como DoH, transporta consultas DNS utilizando HTTPS.

O objetivo inclui melhorar a privacidade e proteger as consultas contra determinados tipos de observação ou alteração no caminho.

Em uma resolução DNS convencional, podemos simplificar:

Computador
↓
Consulta DNS
↓
Resolvedor

Com DoH:

Computador / navegador
↓
HTTPS
↓
Resolvedor DoH

Para o usuário, a experiência continua parecendo a mesma:

digita um domínio e o site abre.

Por baixo, porém, o mecanismo utilizado para obter o endereço pode ser diferente.

Por que isso importa no diagnóstico?

Imagine o seguinte cenário.

O Windows está configurado para utilizar:

DNS da rede corporativa

Esse servidor conhece um domínio interno:

sistema.empresa.local

Você executa:

nslookup sistema.empresa.local

e recebe o endereço correto.

Mas o navegador utiliza um resolvedor público através de DoH.

Esse resolvedor público não conhece o domínio interno.

Agora temos:

NSLOOKUP
↓
DNS corporativo
↓
domínio encontrado

enquanto:

NAVEGADOR
↓
resolvedor externo
↓
domínio não encontrado

Esse é um exemplo de como duas ferramentas no mesmo computador podem apresentar comportamentos aparentemente contraditórios.

Isso significa que DoH é ruim?

Não.

DoH possui objetivos legítimos relacionados a segurança e privacidade.

O problema não é simplesmente:

DoH ligado = erro.

A questão é compatibilidade com a arquitetura da rede.

Em ambientes domésticos comuns, pode funcionar sem que o usuário perceba qualquer diferença.

Em ambientes empresariais, VPNs e redes com resolução interna, precisamos entender:

quem deve resolver cada domínio?

O diagnóstico técnico não deve começar desativando recursos aleatoriamente.

Primeiro precisamos identificar o caminho real da consulta.

Windows também pode utilizar DNS over HTTPS

Outro ponto importante: DoH não é exclusividade do navegador.

Versões modernas do Windows também possuem suporte a DNS criptografado em determinadas configurações.

Portanto, não devemos simplificar o problema para:

Windows = DNS tradicional

navegador = DoH

O ambiente precisa ser verificado.

O objetivo deste artigo é justamente evitar essas generalizações.

Primeiro teste: descubra quais servidores DNS o Windows conhece

Abra o Prompt de Comando e execute:

ipconfig /all

Localize o adaptador utilizado.

Pode ser:

Ethernet;
Wi-Fi;
VPN.

Procure:

Servidores DNS

Você poderá encontrar algo semelhante a:

192.168.1.1

ou endereços de resolvedores públicos.

Esse é nosso primeiro mapa.

Queremos responder:

quais servidores DNS estão associados à interface utilizada pelo Windows?

Cuidado com vários adaptadores

Um computador moderno pode possuir:

Ethernet
Wi-Fi
Bluetooth
VPN
Hyper-V
VMware
VirtualBox
adaptadores virtuais

Cada interface pode apresentar configurações diferentes.

Por isso, não basta localizar a primeira linha contendo “Servidores DNS”.

Identifique primeiro qual interface está efetivamente envolvida na conexão.

Podemos complementar o diagnóstico no PowerShell:

Get-DnsClientServerAddress

Esse comando permite visualizar os servidores DNS associados às diferentes interfaces.

Teste com NSLOOKUP

Agora execute:

nslookup dominio.com

Observe duas coisas:

qual servidor respondeu;
qual endereço foi retornado.

Suponha:

Servidor: 192.168.1.1
Address: 192.168.1.1

Nome: dominio.com
Address: 203.0.113.20

Registre o resultado.

Não conclua ainda que tudo está funcionando.

Estamos apenas coletando evidências.

Consulte outro DNS deliberadamente

Agora podemos comparar.

Por exemplo:

nslookup dominio.com 1.1.1.1

nslookup dominio.com 8.8.8.8

Os resultados podem ser iguais.

Mas também podem ser diferentes.

Isso não significa necessariamente que algum DNS esteja errado.

Serviços modernos utilizam:

CDN;
balanceamento;
geolocalização;
Anycast;
políticas de distribuição.

O mesmo domínio pode legitimamente possuir múltiplos endereços.

DNS não significa necessariamente “um domínio = um IP”

Esse conceito é importante.

Muitos usuários imaginam:

google.com = IP X

como uma relação fixa.

Na Internet moderna, um domínio pode retornar vários registros.

Por exemplo:

dominio.com
↓
IP A
IP B
IP C

Também podemos encontrar:

registros A;
registros AAAA;
CNAME;
diferentes respostas conforme localização;
respostas diferentes conforme resolvedor.

Portanto, comparar apenas um endereço sem entender o contexto pode gerar conclusões erradas.

Registro A e registro AAAA

Em termos simples:

A normalmente associa um nome a um endereço IPv4.

AAAA associa um nome a um endereço IPv6.

Podemos consultar especificamente:

nslookup -type=A dominio.com

nslookup -type=AAAA dominio.com

Agora podemos descobrir se o serviço possui:

IPv4

IPv6

Essa diferença será muito importante mais adiante.

NSLOOKUP funciona, mas o IPv6 está com problema

Imagine:

Registro A → funciona
Registro AAAA → existe

O navegador pode tentar utilizar IPv6 quando disponível.

Mas o caminho IPv6 da rede possui algum problema.

Agora temos:

nslookup
↓
mostra registros corretamente

mas:

navegador
↓
tenta conexão IPv6
↓
falha

Nesse caso, DNS respondeu corretamente.

O problema está depois da resolução.

Por isso, novamente:

resolver nome e alcançar o serviço são coisas diferentes.

Testando IPv4 e IPv6 separadamente

Podemos comparar:

ping -4 dominio.com

ping -6 dominio.com

Também:

tracert -4 dominio.com

tracert -6 dominio.com

Esses comandos não garantem que o servidor aceite ping, mas ajudam quando o destino responde.

Para HTTPS, podemos avançar posteriormente com ferramentas que testam a porta 443.

O cache DNS do Windows

O Windows mantém um cache de resolução para evitar consultas repetidas desnecessárias.

Podemos visualizar parte desse cache com:

ipconfig /displaydns

Esse comando pode mostrar entradas armazenadas pelo sistema.

O cache melhora desempenho e reduz consultas.

Mas também cria outra variável no diagnóstico.

Imagine:

DNS atual → endereço novo

enquanto algum componente ainda possui:

cache → endereço antigo

Agora respostas podem parecer inconsistentes.

Limpar o cache DNS resolve tudo?

Não.

O famoso comando:

ipconfig /flushdns

limpa o cache do resolvedor DNS do Windows.

Ele pode ser útil quando existe uma entrada em cache que precisa ser descartada.

Mas ele não corrige:

servidor DNS fora do ar;
rota;
firewall;
proxy;
VPN;
problema no servidor;
certificado;
MTU;
configuração de DoH do navegador.

Portanto, executar flushdns em qualquer problema de Internet é semelhante a reiniciar o roteador sem saber por quê.

Pode funcionar em determinado caso, mas não constitui diagnóstico.

NSLOOKUP e cache do Windows merecem uma distinção

Aqui existe um detalhe técnico importante.

O nslookup é uma ferramenta de consulta DNS e não deve ser tratado simplesmente como uma reprodução perfeita de tudo que uma aplicação comum faz através do resolvedor do Windows.

Por isso, para investigar como o sistema operacional está resolvendo nomes, podemos complementar o teste com outras ferramentas.

No PowerShell:

Resolve-DnsName dominio.com

Essa ferramenta oferece informações úteis sobre os registros encontrados e permite análises mais detalhadas.

Compare NSLOOKUP e Resolve-DnsName

Execute:

nslookup dominio.com

Depois:

Resolve-DnsName dominio.com

Compare:

registros;
IPv4;
IPv6;
servidor;
erros.

Se os resultados divergem, temos uma pista.

Se são iguais, avançamos para a próxima camada.

Essa é a lógica correta:

cada teste elimina ou fortalece uma hipótese.

O arquivo HOSTS pode mudar a resolução

O Windows possui um arquivo chamado:

hosts

Ele permite associar nomes a endereços localmente.

Seu caminho padrão é:

C:\Windows\System32\drivers\etc\hosts

Uma entrada pode ter formato semelhante a:

192.168.1.50 sistema.exemplo

Dependendo da forma como uma aplicação utiliza a resolução do sistema, essa associação local pode influenciar o resultado.

Isso cria outro cenário interessante.

O servidor DNS pode responder:

sistema.exemplo → 203.0.113.50

enquanto o computador possui:

hosts → 192.168.1.50

Agora existe uma divergência local.

Por que o NSLOOKUP pode confundir nesse caso?

Porque consultar diretamente o DNS e perguntar:

"Qual é o IP deste nome?"

não é exatamente a mesma coisa que perguntar:

"Qual endereço uma aplicação neste Windows utilizará?"

O segundo cenário pode envolver mecanismos locais do sistema.

É por isso que nslookup deve ser tratado como uma ferramenta do diagnóstico, e não como prova absoluta de que toda a resolução de nomes do computador está correta.

Como verificar o arquivo HOSTS

Abra o Bloco de Notas como administrador e examine:

C:\Windows\System32\drivers\etc\hosts

Não apague entradas sem saber por que estão ali.

Softwares, administradores ou ambientes de desenvolvimento podem utilizar esse arquivo legitimamente.

Procure apenas entradas relacionadas ao domínio problemático.

Se existir algo como:

127.0.0.1 dominio.com

ou:

0.0.0.0 dominio.com

essa configuração merece investigação.

Malware também pode modificar o HOSTS?

Historicamente, softwares maliciosos e programas indesejados podem modificar configurações relacionadas à resolução de nomes, inclusive o arquivo hosts.

Mas não devemos concluir:

entrada no hosts = vírus.

Existem usos legítimos.

O importante é descobrir:

quem criou a entrada;
para onde ela aponta;
se faz sentido naquele computador.

Diagnóstico técnico evita conclusões precipitadas.

Navegador também possui cache

Além do cache do Windows, navegadores mantêm diferentes tipos de dados relacionados às conexões e aos sites.

Dependendo do navegador e da versão, podem existir caches e estados internos que influenciam novas tentativas.

Isso explica por que às vezes:

um navegador abre

outro navegador não abre.

Esse teste é muito útil.

Chrome funciona e Edge não: é DNS?

Pode ser.

Mas não necessariamente.

Os navegadores podem diferir em:

cache;
DNS seguro;
proxy;
extensões;
HTTP/3;
certificados;
perfil;
políticas;
configuração corporativa.

Portanto:

Chrome funciona
Edge não

é uma evidência de que o problema provavelmente não é uma queda completa da Internet.

Agora precisamos descobrir qual diferença entre os dois está causando o comportamento.

Teste em outro navegador

Se determinado site não abre, teste:

Microsoft Edge;
Google Chrome;
Firefox, quando disponível.

Se nenhum abre, aumenta a suspeita de algo no sistema ou na rede.

Se somente um falha, investigue primeiro as particularidades daquele navegador.

Esse teste simples reduz bastante o espaço de busca.

Modo anônimo resolve?

O modo privado pode ajudar a eliminar alguns elementos relacionados à sessão, cookies e extensões dependendo do navegador e das configurações.

Mas não deve ser interpretado como:

modo anônimo = sem cache, sem DNS e sem interferência de qualquer configuração.

É apenas mais um teste comparativo.

DNS seguro no navegador

Navegadores modernos podem apresentar configurações com nomes como:

Usar DNS seguro

ou equivalentes.

Dependendo da configuração, o navegador pode:

utilizar o provedor atual;
utilizar um resolvedor específico;
seguir políticas do sistema;
desabilitar DoH em determinadas condições.

Esses comportamentos também mudam com versões e políticas.

Por isso, o objetivo não é decorar a posição exata de um botão.

É entender o conceito:

o caminho de resolução utilizado pelo navegador pode não ser idêntico ao teste feito manualmente.

VPN adiciona outra camada

Agora imagine que instalamos uma VPN.

Ela pode modificar:

servidores DNS;
rotas;
adaptadores;
métricas;
políticas;
domínios internos.

Em uma VPN corporativa, isso pode ser necessário.

Por exemplo:

Internet pública
↓
DNS público

enquanto:

sistema.interno
↓
DNS corporativo pela VPN

O Windows precisa saber qual resolvedor utilizar para cada situação.

É aqui que entra outro conceito avançado:

Split DNS.

O que é Split DNS?

Split DNS, em termos gerais, descreve cenários em que a resolução depende de onde a consulta é realizada ou de qual infraestrutura está sendo utilizada.

Um mesmo nome pode inclusive possuir respostas diferentes em redes diferentes.

Exemplo conceitual:

Dentro da empresa:
portal.empresa.com → 10.0.0.20

Internet:
portal.empresa.com → endereço público

Isso pode ser completamente intencional.

O problema aparece quando o computador consulta o resolvedor errado.

VPN conecta, mas domínio interno não resolve

Esse é um chamado bastante típico.

O usuário diz:

“A VPN está conectada, mas o sistema não abre.”

Executamos:

ipconfig /all

e verificamos os DNS.

Depois:

nslookup sistema.interno

Agora precisamos descobrir:

qual servidor recebeu a consulta?

Se o domínio interno deveria ser resolvido pelo DNS corporativo, mas a consulta foi enviada para um DNS público, encontramos uma pista importante.

Alterar para 8.8.8.8 pode piorar o problema

Muitos tutoriais recomendam imediatamente:

8.8.8.8

ou:

1.1.1.1

quando qualquer problema de DNS aparece.

Resolvedores públicos são úteis em muitos cenários, mas podem não conhecer domínios privados de uma empresa.

Imagine:

DNS corporativo
↓
conhece sistema.interno

Você substitui por:

DNS público

Agora:

sistema.interno → não existe publicamente

O usuário pode corrigir a navegação pública e quebrar o acesso corporativo.

Por isso, trocar DNS não deve ser um reflexo automático.

O primeiro mapa do diagnóstico

Até aqui já conseguimos criar uma árvore inicial:

SITE NÃO ABRE
      ↓
NSLOOKUP FUNCIONA?
      ↓
     SIM
      ↓
Qual endereço retornou?
      ↓
Resolve-DnsName concorda?
      ↓
Arquivo HOSTS interfere?
      ↓
Navegador usa DNS seguro?
      ↓
VPN está ativa?
      ↓
Existe IPv4 e IPv6?
      ↓
O IP realmente é alcançável?

Perceba que ainda não alteramos nenhuma configuração.

Estamos construindo evidências.

Esse é o padrão que deve orientar qualquer diagnóstico de rede.

O que veremos

Na próxima parte, vamos aprofundar justamente o ponto em que muitos diagnósticos param cedo demais.

O domínio resolve.

Temos um endereço IP.

E agora?

Vamos investigar:

Resolve-DnsName;
cache DNS;
TTL;
registros A e AAAA;
CNAME;
DNS over HTTPS;
Edge, Chrome e Firefox;
arquivo hosts;
VPN e Split DNS;
NRPT do Windows;
Test-NetConnection;
porta 443;
proxy;
curl;
como descobrir o IP realmente utilizado pela conexão;
diferença entre falha de DNS e falha depois do DNS.

O objetivo será responder com precisão:

“Se o NSLOOKUP funciona, em qual etapa o navegador está realmente falhando?”

DoH, cache, VPN e como descobrir onde está a falha

o nslookup conseguir resolver um domínio não significa que o navegador conseguirá abrir o site.

O nslookup responde uma pergunta relativamente específica:

“Qual resposta DNS estou recebendo para esta consulta?”

O navegador precisa fazer muito mais.

Depois de obter um endereço, ainda pode precisar estabelecer uma conexão, negociar TLS, enviar uma requisição HTTP, receber conteúdo de diferentes servidores e lidar com IPv4, IPv6, proxy, VPN e outras tecnologias.

Agora vamos descobrir como separar essas etapas.

Comece comparando NSLOOKUP e Resolve-DnsName

Execute:

nslookup exemplo.com

Depois abra o PowerShell:

Resolve-DnsName exemplo.com

Não estamos procurando apenas:

funcionou / não funcionou.

Observe os registros retornados.

Podemos encontrar, por exemplo:

Name       Type   IPAddress
exemplo.com A     203.0.113.20

Também pode existir:

Name       Type   IPAddress
exemplo.com AAAA  2001:db8::20

Ou ainda um CNAME apontando para outro nome.

Essa diferença começa a mostrar que a resolução DNS moderna pode envolver muito mais do que um único domínio apontando para um único IPv4.

O que é um registro A?

Um registro A associa um nome DNS a um endereço IPv4.

Exemplo conceitual:

site.exemplo
      ↓
      A
      ↓
203.0.113.20

Podemos consultar especificamente esse tipo:

Resolve-DnsName exemplo.com -Type A

ou:

nslookup -type=A exemplo.com

Se encontramos um registro A válido, sabemos que existe uma resposta IPv4 para aquela consulta.

Ainda não sabemos se o servidor está acessível.

O que é um registro AAAA?

O registro AAAA associa um nome a um endereço IPv6.

Podemos consultar:

Resolve-DnsName exemplo.com -Type AAAA

ou:

nslookup -type=AAAA exemplo.com

Um domínio pode possuir simultaneamente:

A    → IPv4
AAAA → IPv6

Agora surge uma situação importante.

O DNS pode estar funcionando perfeitamente nos dois casos, mas um dos caminhos de rede pode estar com problema.

O site possui IPv4 e IPv6, mas apenas um funciona

Imagine:

DNS
├── A    → IPv4 válido
└── AAAA → IPv6 válido

O computador possui IPv4 e IPv6 habilitados.

Porém:

IPv4 → Internet funcionando
IPv6 → caminho com problema

O navegador tenta estabelecer a conexão utilizando os endereços disponíveis e seus mecanismos de seleção/conexão.

O resultado para o usuário pode ser:

atraso para abrir;
comportamento intermitente;
site que funciona em alguns momentos;
falha em determinadas aplicações.

O nslookup, entretanto, continua mostrando os registros corretamente.

Nesse caso:

DNS não deixou de resolver o domínio.

A falha está depois da resolução.

Como testar IPv4 e IPv6 separadamente

Quando o destino aceita ICMP, podemos utilizar:

ping -4 exemplo.com

ping -6 exemplo.com

Também:

tracert -4 exemplo.com

tracert -6 exemplo.com

Esses testes ajudam a observar se existe diferença entre os caminhos.

Mas lembre:

servidor não responder ao ping não significa necessariamente que esteja indisponível.

Por isso, para um site HTTPS, precisamos também testar a aplicação ou pelo menos a porta utilizada.

Testando a porta 443

No PowerShell:

Test-NetConnection exemplo.com -Port 443

Observe principalmente:

TcpTestSucceeded

Se retornar:

True

significa que o teste conseguiu estabelecer a conexão TCP com aquela porta nas condições verificadas.

Isso é uma informação muito diferente de:

nslookup exemplo.com

Agora sabemos que não apenas encontramos um endereço: conseguimos chegar a um serviço TCP naquela porta.

NSLOOKUP funciona, mas Test-NetConnection falha

Esse resultado é extremamente útil.

Temos:

DNS
↓
RESOLVEU

mas:

TCP 443
↓
FALHOU

Agora nossa prioridade deixa de ser simplesmente “limpar DNS”.

Precisamos investigar:

rota;
firewall;
proxy;
VPN;
IPv4/IPv6;
servidor;
bloqueio;
caminho da rede.

O problema está provavelmente depois da resolução do nome.

Test-NetConnection funciona, mas o navegador não

Agora temos outro cenário:

DNS → OK
TCP 443 → OK
Navegador → FALHA

A investigação muda novamente.

Podemos olhar para:

TLS;
certificado;
proxy;
navegador;
extensão;
política;
HTTP;
HTTP/3;
cache;
conteúdo externo;
autenticação.

É justamente esse processo de eliminação que evita trocar DNS sem necessidade.

CURL: aproximando o teste da aplicação

O curl pode ser extremamente útil.

Execute:

curl -I https://exemplo.com

A opção -I solicita os cabeçalhos da resposta.

Podemos receber algo semelhante a:

HTTP/1.1 200 OK

ou:

HTTP/2 200

Também podemos receber:

ou:

indicando redirecionamento.

O resultado depende do servidor.

Utilize CURL em modo detalhado

Para enxergar melhor as etapas:

curl -v https://exemplo.com

O modo verbose pode fornecer informações úteis sobre:

resolução do nome;
tentativa de conexão;
endereço utilizado;
TLS;
certificado;
protocolo;
resposta HTTP.

Isso nos permite responder uma pergunta importante:

até onde a comunicação conseguiu chegar?

O CURL resolve, conecta e recebe HTTP

Imagine:

Resolve-DnsName → OK
Test-NetConnection → OK
curl → HTTP 200
Chrome → não abre

Agora a probabilidade de uma falha geral da conexão diminui bastante.

A investigação deve se concentrar mais no navegador:

perfil;
extensões;
proxy;
políticas;
DNS seguro;
cache;
dados do site;
segurança.

Compare outro navegador antes de modificar a rede inteira.

Chrome não abre, Edge abre

Esse teste é muito valioso.

Temos:

Internet → funciona
DNS → funciona
Servidor → funciona
Edge → funciona
Chrome → falha

Seria pouco lógico começar reiniciando o roteador.

A diferença está muito mais próxima da aplicação.

Agora compare:

extensões;
perfil;
DNS seguro;
proxy;
políticas;
configurações experimentais;
cache.

Os navegadores podem utilizar DNS seguro

Dependendo da versão e das políticas aplicadas, navegadores modernos podem oferecer configurações relacionadas a Secure DNS / DNS over HTTPS.

Isso cria alguns cenários.

Cenário A

Windows
↓
DNS do roteador
↓
resolvedor da operadora

Navegador:

Navegador
↓
DoH
↓
resolvedor escolhido

Cenário B

O navegador acompanha a configuração do sistema e utiliza mecanismos compatíveis com o resolvedor configurado.

Cenário C

Uma política corporativa controla o comportamento.

Portanto, não devemos presumir automaticamente qual resolvedor o navegador está usando.

Precisamos verificar.

Por que um resolvedor diferente pode entregar outro endereço?

Muitos serviços utilizam CDNs.

Imagine dois resolvedores.

DNS A

site.com → servidor 1

DNS B

site.com → servidor 2

Ambas as respostas podem ser legítimas.

Mas os caminhos até esses servidores podem ser diferentes.

Agora imagine que:

Servidor 1 → caminho funcionando
Servidor 2 → problema de rota

Trocar DNS aparentemente “resolve” o problema.

Mas a causa real pode estar no caminho até determinado servidor da CDN.

Isso explica por que devemos interpretar cuidadosamente o resultado de uma troca de DNS.

Google DNS ou Cloudflare resolveram: era DNS?

Talvez.

Mas não obrigatoriamente.

A mudança pode ter alterado:

resposta DNS;
servidor da CDN;
IPv4/IPv6 recebido;
caminho até o conteúdo.

O diagnóstico correto compara os resultados.

Antes:

nslookup exemplo.com SERVIDOR_DNS_ANTIGO

Depois:

nslookup exemplo.com 1.1.1.1

nslookup exemplo.com 8.8.8.8

Compare os registros.

Se os endereços mudaram, existe outra variável na experiência.

TTL: por que uma resposta antiga pode permanecer?

Registros DNS possuem um valor conhecido como:

TTL — Time To Live

Ele indica por quanto tempo determinada informação pode permanecer em cache conforme as regras do DNS.

Imagine:

site.com
↓
IP antigo
↓
TTL

O administrador altera o endereço.

Alguns resolvedores já conhecem:

IP novo

enquanto caches que ainda respeitam uma resposta anterior podem continuar temporariamente utilizando:

IP antigo

Isso ajuda a explicar por que alterações DNS não aparecem simultaneamente em todos os lugares.

Como observar TTL no PowerShell

Execute:

Resolve-DnsName exemplo.com

Dependendo do tipo de consulta e resposta, podemos visualizar informações relacionadas ao TTL.

Também podemos especificar:

Resolve-DnsName exemplo.com -Type A

O TTL não deve ser interpretado como um cronômetro global indicando quando “a Internet inteira será atualizada”.

Caches diferentes podem ter sido preenchidos em momentos diferentes.

O famoso “DNS demora 48 horas para propagar”

Essa frase é uma simplificação.

Quando registros DNS são alterados, o comportamento observado depende de fatores como:

TTL anterior;
caches;
delegação;
servidores autoritativos;
resolvedores;
configuração correta da zona.

Portanto, não existe uma regra universal dizendo que toda alteração DNS obrigatoriamente levará exatamente 24 ou 48 horas.

Para diagnóstico, precisamos descobrir:

qual servidor está retornando qual informação agora?

Cache DNS do Windows

Podemos observar entradas com:

ipconfig /displaydns

E limpar o cache do resolvedor com:

ipconfig /flushdns

Depois, uma nova resolução poderá exigir nova consulta conforme o comportamento do sistema e da aplicação.

Mas existe uma limitação:

isso não significa que todos os caches possíveis foram eliminados.

Ainda podemos ter cache:

no navegador;
no resolvedor;
em uma aplicação;
em um proxy;
em infraestrutura intermediária.

Reiniciar o navegador pode produzir resultado diferente

Se o navegador mantém estados próprios relacionados à resolução ou às conexões, simplesmente executar:

ipconfig /flushdns

e manter todas as sessões abertas pode não reproduzir um ambiente totalmente novo.

Em testes comparativos, pode ser útil:

registrar o comportamento;
limpar somente o que faz sentido;
fechar o navegador;
abrir novamente;
repetir exatamente o mesmo teste.

O importante é mudar poucas variáveis de cada vez.

CNAME: o site pode depender de outro nome

Um domínio pode não apontar diretamente para um endereço.

Podemos encontrar:

www.exemplo.com
↓
CNAME
↓
servidor.cdn.exemplo.net
↓
A / AAAA
↓
IP

Agora o navegador precisa chegar ao destino final dessa cadeia.

Podemos consultar:

Resolve-DnsName www.exemplo.com

e observar os registros.

Isso é particularmente relevante em:

CDNs;
hospedagem;
SaaS;
balanceadores;
serviços em nuvem.

Um site não é apenas um domínio

Outro detalhe frequentemente ignorado.

Você acessa:

www.exemplo.com

Mas a página pode carregar conteúdo de:

static.exemplo.com
api.exemplo.com
cdn.exemplo.net
fonts.outroservico.com

O domínio principal pode resolver e funcionar perfeitamente.

Se a API não resolver, a página pode ficar incompleta.

Se a CDN falhar, imagens podem não aparecer.

Se um script externo falhar, determinada função pode parar.

Por isso:

“O site abriu pela metade.”

não significa necessariamente que o domínio principal está com problema.

Como descobrir quais domínios a página utiliza?

Os navegadores possuem ferramentas de desenvolvedor.

Normalmente, a guia Network/Rede permite observar as requisições feitas durante o carregamento.

Ali podemos identificar:

domínio solicitado;
status;
tempo;
protocolo;
requisições que falharam.

Isso pode revelar algo como:

www.exemplo.com → OK
api.exemplo.com → FALHA
cdn.exemplo.com → OK

Agora temos um alvo muito mais específico para investigar.

Teste o domínio que realmente falhou

Se a guia de rede mostra:

api.exemplo.com

falhando, execute:

nslookup api.exemplo.com

Depois:

Resolve-DnsName api.exemplo.com

E, se apropriado:

Test-NetConnection api.exemplo.com -Port 443

Agora estamos investigando o componente que realmente falhou, não apenas a página principal.

Proxy pode fazer o navegador seguir outro caminho

Um proxy adiciona outra possibilidade.

Sem proxy:

Navegador
↓
Servidor do site

Com proxy:

Navegador
↓
Proxy
↓
Servidor

Dependendo da arquitetura, o próprio proxy pode participar da resolução de nomes ou controlar o acesso.

Assim:

nslookup exemplo.com

pode funcionar localmente, enquanto o navegador falha porque sua comunicação depende de um proxy com outro problema.

Como verificar proxy no Windows

Podemos verificar as configurações em:

Configurações → Rede e Internet → Proxy

Também existe o WinHTTP.

No Prompt:

netsh winhttp show proxy

Podemos encontrar:

Acesso direto

ou uma configuração de proxy.

Importante: diferentes aplicações podem utilizar mecanismos de proxy diferentes.

Por isso, novamente, não devemos tratar uma única configuração como representação de todos os programas.

Script PAC pode tornar o problema ainda mais específico

Ambientes corporativos podem utilizar arquivos PAC — Proxy Auto-Configuration.

Eles podem decidir:

site A → proxy
site B → conexão direta
site C → outro comportamento

Agora temos um cenário em que:

alguns sites funcionam e outros não

por causa da política de proxy, não do DNS.

O nslookup continuará funcionando normalmente.

VPN e Split DNS

Vamos aprofundar o cenário corporativo.

Imagine:

Internet pública
↓
DNS público

mas:

VPN corporativa
↓
DNS da empresa
↓
sistema.interno

Queremos que consultas internas utilizem a infraestrutura corporativa, sem necessariamente enviar todas as consultas públicas pelo mesmo resolvedor.

Esse tipo de arquitetura pode envolver Split DNS.

Quando funciona corretamente, o usuário nem percebe.

Quando falha:

google.com → funciona
sistema.interno → não resolve

ou o inverso.

NRPT no Windows

Em ambientes Windows, existe um mecanismo chamado:

Name Resolution Policy Table — NRPT

Ele permite definir políticas de resolução de nomes para determinados namespaces.

Isso é especialmente relevante em cenários corporativos, VPNs e tecnologias que precisam controlar como determinados domínios são resolvidos.

Podemos consultar políticas no PowerShell:

Get-DnsClientNrptPolicy

Se houver regras, elas podem ajudar a explicar por que determinado domínio recebe tratamento diferente.

Por que trocar o DNS manualmente pode quebrar uma VPN corporativa?

Imagine que a VPN configure corretamente:

empresa.local
↓
DNS corporativo

O usuário lê um tutorial e altera manualmente a interface para:

8.8.8.8

Agora o DNS público recebe uma consulta sobre um nome que só existe internamente.

Resultado:

Internet pública → funciona
Sistema interno → não funciona

O usuário conclui:

“A VPN está com problema.”

Mas foi a alteração do DNS que rompeu a arquitetura planejada.

Descubra o servidor consultado antes de trocar qualquer coisa

Execute:

nslookup dominio

Observe o servidor apresentado.

Depois:

Get-DnsClientServerAddress

E, quando houver ambiente corporativo:

Get-DnsClientNrptPolicy

Agora temos informações suficientes para começar a entender a arquitetura.

E se o NSLOOKUP usar um DNS diferente do esperado?

Esse é um sinal importante.

Suponha que a VPN deveria fornecer:

10.10.10.10

mas a consulta aparece indo para:

192.168.1.1

Precisamos investigar:

configuração da VPN;
interfaces;
políticas;
DNS;
métricas;
split DNS.

Não comece alterando todos os servidores manualmente.

Primeiro descubra por que o DNS esperado não está sendo utilizado.

Firewall também pode bloquear DNS seletivamente

DNS tradicional utiliza normalmente UDP e, em determinadas situações, TCP na porta 53.

DoH utiliza HTTPS.

Isso cria um cenário interessante:

DNS tradicional → bloqueado
DoH → funciona

ou:

DNS corporativo → funciona
DoH externo → bloqueado

Assim, navegador e nslookup podem apresentar comportamentos diferentes devido à política da rede.

DNS por UDP e TCP

Existe outra simplificação comum:

“DNS usa UDP 53.”

Frequentemente, sim, mas DNS também pode utilizar TCP.

Existem situações em que uma resposta ou operação precisa utilizar TCP.

Por isso, permitir apenas um comportamento muito restrito pode produzir falhas específicas.

Novamente, redes modernas exigem mais cuidado do que decorar uma única porta e protocolo.

DNSSEC também entra no diagnóstico?

Pode entrar em casos específicos.

DNSSEC permite validar autenticidade e integridade de determinadas informações DNS através de uma cadeia de confiança.

Problemas de configuração podem causar falhas de validação.

Entretanto, DNSSEC não deve ser nossa primeira hipótese para um usuário doméstico cujo navegador não abre um site.

Começamos sempre pelo mais provável e avançamos conforme as evidências.

Como descobrir o IP realmente usado pelo CURL

O modo detalhado pode mostrar o endereço ao qual a ferramenta está tentando se conectar:

curl -v https://exemplo.com

Compare esse endereço com:

nslookup exemplo.com

Resolve-DnsName exemplo.com

Se forem diferentes, investigue por quê.

Pode ser:

múltiplos registros;
IPv4/IPv6;
CDN;
cache;
mecanismo de resolução;
mudança ocorrida entre as consultas.

Forçando IPv4 ou IPv6 no CURL

Podemos realizar testes separados:

curl -4 -v https://exemplo.com

curl -6 -v https://exemplo.com

Agora temos um teste muito mais próximo da aplicação.

Imagine:

curl -4 → funciona
curl -6 → falha

Temos uma forte indicação de que precisamos investigar o caminho IPv6.

Isso é muito melhor do que simplesmente desabilitar IPv6 e declarar o problema resolvido.

O mesmo raciocínio vale para MTU

No artigo anterior da VMIA sobre MTU, vimos que uma conexão pode:

resolver DNS;
conectar;
começar a transferir;
travar com determinados tamanhos de pacote.

Portanto:

nslookup → OK

não elimina MTU.

Mas também não aponta automaticamente para MTU.

Precisamos observar o padrão da falha.

Esse é o valor de trabalhar o diagnóstico por camadas.

Árvore de diagnóstico até aqui

Agora conseguimos ampliar nosso mapa:

SITE NÃO ABRE
      ↓
DOMÍNIO RESOLVE?
   ↙       ↘
 NÃO       SIM
 ↓          ↓
DNS       Testar TCP 443
            ↓
        TCP funciona?
         ↙       ↘
       NÃO       SIM
        ↓         ↓
 rota/firewall   curl
 VPN/IPv4/IPv6    ↓
               HTTP/TLS funciona?
                 ↙       ↘
               NÃO       SIM
                ↓         ↓
           investigar   navegador
           TLS/MTU/etc. proxy/cache/
                       DoH/extensões

Essa árvore não cobre todas as possibilidades, mas já evita grande parte das tentativas aleatórias.

Um caso prático: NSLOOKUP funciona e Chrome não

Imagine o chamado:

“O site do banco não abre no Chrome, mas minha Internet está normal.”

Etapa 1

nslookup site

Funciona.

Etapa 2

Test-NetConnection site -Port 443

Funciona.

Etapa 3

curl -I https://site

Recebe resposta.

Etapa 4

Abrimos Edge.

Site funciona.

Agora temos:

DNS → OK
Rede → OK
TCP → OK
HTTPS → aparentemente OK
Outro navegador → OK
Chrome → falha

A prioridade deve ser o Chrome e suas particularidades.

Trocar o DNS do roteador inteiro seria uma intervenção desproporcional.

Outro caso: NSLOOKUP funciona, mas nenhum navegador abre

Agora:

NSLOOKUP → OK
Edge → falha
Chrome → falha
Firefox → falha

Testamos:

Test-NetConnection dominio -Port 443

e recebemos:

TcpTestSucceeded: False

Agora o problema provavelmente está abaixo do navegador.

Investigue:

firewall;
rota;
VPN;
bloqueio;
IPv4/IPv6;
servidor;
conectividade.

O mesmo sintoma inicial levou a uma direção completamente diferente.

Outro caso: navegador abre com VPN

Sem VPN:

site → não abre

Com VPN:

site → abre

O que mudou?

Possivelmente:

DNS;
IP público;
rota;
MTU;
IPv4/IPv6;
CDN;
caminho.

Não podemos concluir apenas:

“é bloqueio da operadora.”

A VPN altera muitas variáveis simultaneamente.

Precisamos comparar cada uma delas.

Diagnóstico é comparação controlada

Essa é uma das regras mais importantes deste artigo.

Compare:

com VPN / sem VPN

IPv4 / IPv6

Chrome / Edge

DNS A / DNS B

nslookup / Resolve-DnsName

TCP 443 / navegador

Mas altere uma variável por vez sempre que possível.

Quando modificamos cinco configurações simultaneamente, perdemos a capacidade de saber qual delas realmente interferiu no resultado.

O que veremos

Na próxima parte, vamos fechar o diagnóstico avançado e transformar tudo em um procedimento completo.

Vamos abordar:

como identificar o DNS realmente utilizado;
DoH no navegador versus DNS do Windows;
cache e arquivo hosts;
DNS corporativo;
VPN e Split DNS;
NRPT;
proxy;
IPv4 versus IPv6;
como interpretar erros do navegador;
quando flushdns realmente faz sentido;
quando trocar DNS faz sentido;
quando o problema definitivamente não é DNS;
checklist técnico completo;
erros comuns;
FAQ;
conclusão;
CTA da VMIA.

Ao final, teremos uma árvore de diagnóstico capaz de responder à pergunta central deste artigo:

se o nslookup funciona, por que o site ainda não abre?

Diagnóstico final, erros comuns e checklist completo

Nas duas primeiras partes, vimos que o fato de o nslookup funcionar não encerra o diagnóstico. Ele apenas comprova que determinada consulta DNS recebeu uma resposta.

A partir desse ponto, ainda precisamos verificar se:

o Windows está usando o mesmo caminho de resolução;
o navegador está usando DNS seguro;
existe IPv4 e IPv6;
a porta 443 está acessível;
o TLS consegue negociar;
há proxy ou VPN;
o arquivo hosts interfere;
existe cache antigo;
o domínio depende de outras APIs ou CDNs;
uma política corporativa está modificando a resolução.

Agora vamos transformar tudo isso em um procedimento prático e organizado.

A pergunta correta: “onde exatamente o site está falhando?”

Quando alguém diz:

“O site não abre.”

isso ainda é uma descrição muito genérica.

Precisamos separar o processo:

Nome do domínio
↓
Resolução DNS
↓
Endereço IP
↓
Rota
↓
Conexão TCP ou QUIC
↓
TLS
↓
HTTP
↓
Conteúdo da página
↓
APIs, scripts, CDN e serviços externos

Se sabemos em qual etapa ocorreu a falha, o diagnóstico fica muito mais rápido.

Etapa 1: confirme o que o NSLOOKUP está realmente resolvendo

Execute:

nslookup exemplo.com

Observe:

qual servidor respondeu;
quais endereços foram retornados;
se aparecem registros IPv4;
se aparecem registros IPv6;
se existe CNAME.

Depois compare com:

Resolve-DnsName exemplo.com

Se os resultados forem diferentes, temos uma primeira pista.

Se forem iguais, seguimos em frente.

Etapa 2: veja os DNS configurados no Windows

No Prompt:

ipconfig /all

No PowerShell:

Get-DnsClientServerAddress

Isso mostra quais servidores DNS estão associados às interfaces.

Em computadores com:

Wi-Fi;
Ethernet;
VPN;
Hyper-V;
VMware;
adaptadores virtuais;

não basta olhar apenas a primeira interface.

É preciso descobrir qual delas está realmente envolvida na comunicação.

Etapa 3: verifique se existe política de resolução

Em ambientes corporativos ou com VPN, execute:

Get-DnsClientNrptPolicy

Se houver regras, elas podem direcionar determinados domínios para servidores DNS específicos.

Exemplo conceitual:

*.empresa.local
↓
DNS corporativo

enquanto:

outros domínios
↓
DNS padrão

Essa arquitetura pode ser totalmente intencional.

Etapa 4: teste o domínio em DNS diferentes

Compare:

nslookup exemplo.com 1.1.1.1

nslookup exemplo.com 8.8.8.8

Também compare com o DNS da rede.

Se as respostas forem diferentes, não conclua imediatamente que alguma está errada.

Pode existir:

CDN;
geolocalização;
Anycast;
balanceamento;
diferentes políticas de distribuição.

O importante é registrar quais endereços foram retornados.

Etapa 5: teste IPv4 e IPv6 separadamente

Se o domínio possuir registros A e AAAA, compare:

ping -4 exemplo.com

ping -6 exemplo.com

e, quando apropriado:

tracert -4 exemplo.com

tracert -6 exemplo.com

Se um protocolo funciona e o outro não, investigue a pilha correspondente.

Não desative IPv6 permanentemente apenas porque ele parece ser o caminho problemático.

Primeiro descubra a causa.

Etapa 6: teste a porta HTTPS

No PowerShell:

Test-NetConnection exemplo.com -Port 443

Se:

TcpTestSucceeded : True

a conexão TCP com a porta 443 foi estabelecida.

Se:

TcpTestSucceeded : False

a investigação deve considerar:

rota;
firewall;
VPN;
servidor;
bloqueio;
IPv4/IPv6;
rede.

Isso já nos afasta de um problema puramente DNS.

Etapa 7: teste com CURL

Execute:

curl -I https://exemplo.com

Depois:

curl -v https://exemplo.com

O modo detalhado ajuda a mostrar:

resolução;
endereço usado;
tentativa de conexão;
TLS;
resposta HTTP.

Também podemos separar IPv4 e IPv6:

curl -4 -v https://exemplo.com

curl -6 -v https://exemplo.com

Esse teste é muito útil para descobrir se a falha está antes ou depois da resolução.

Etapa 8: compare navegadores

Teste:

Edge;
Chrome;
Firefox, se disponível.

Se apenas um falhar, investigue mais perto da aplicação.

Possíveis causas:

cache;
perfil;
extensão;
DNS seguro;
proxy;
política;
dados do site;
HTTP/3;
certificado.

Se todos falharem, a causa provavelmente está em uma camada mais baixa.

DNS seguro pode explicar a diferença

Em navegadores modernos, recursos de DNS seguro podem alterar o resolvedor utilizado.

Isso pode gerar:

nslookup
↓
DNS do sistema

enquanto:

navegador
↓
DoH
↓
outro resolvedor

Em redes corporativas ou com domínios internos, isso pode fazer grande diferença.

O importante é verificar a configuração real do navegador.

Quando desativar temporariamente o DNS seguro faz sentido?

Somente como teste controlado.

Se:

nslookup resolve corretamente;
o navegador não;
outro navegador funciona;
DoH está ativo;

desativar temporariamente o DNS seguro pode ajudar a confirmar se ele está relacionado ao problema.

Se o site passar a funcionar, ainda precisamos entender:

por que o resolvedor DoH estava entregando comportamento diferente?

Cache: quando o flushdns realmente faz sentido?

O comando:

ipconfig /flushdns

é útil quando existe suspeita de cache DNS incorreto no Windows.

Exemplos:

domínio mudou recentemente;
endereço antigo permanece;
uma entrada incorreta está sendo reaproveitada;
resolução mudou após alteração de DNS.

Mas ele não resolve:

falha na porta 443;
proxy;
rota;
firewall;
TLS;
VPN;
servidor fora do ar.

Por isso, deve ser usado dentro de um diagnóstico, não como comando universal.

O arquivo HOSTS continua sendo importante

Confira:

C:\Windows\System32\drivers\etc\hosts

Procure entradas relacionadas ao domínio problemático.

Exemplos:

127.0.0.1 exemplo.com

0.0.0.0 exemplo.com

192.168.1.50 exemplo.com

Essas linhas podem alterar localmente a resolução.

Não remova entradas sem entender sua finalidade.

NSLOOKUP pode funcionar mesmo com HOSTS incorreto

Esse é um dos melhores exemplos da diferença entre ferramentas.

O nslookup consulta DNS.

O arquivo hosts é um mecanismo local.

Então podemos ter:

nslookup exemplo.com
→ IP público correto

e ao mesmo tempo:

hosts
→ 127.0.0.1

Uma aplicação que usa a resolução do sistema pode tentar acessar o endereço definido localmente.

Esse é exatamente o tipo de situação em que dizer “o DNS está bom porque o nslookup funcionou” pode ser enganoso.

Proxy: outro culpado comum

Execute:

netsh winhttp show proxy

Também verifique:

Configurações → Rede e Internet → Proxy

Dependendo da aplicação, o proxy pode alterar:

caminho;
resolução;
autenticação;
acesso;
inspeção TLS.

Se o navegador utiliza um proxy, mas o nslookup consulta diretamente o DNS local, temos novamente dois caminhos diferentes.

Script PAC pode afetar apenas alguns sites

Em redes corporativas, um script PAC pode decidir:

site A → proxy
site B → direto
site C → outro proxy

Assim:

alguns sites abrem;
outros não;
DNS funciona em todos.

O problema pode estar na regra do PAC.

VPN: sempre compare com e sem

Faça testes nos dois cenários.

Sem VPN

DNS;
Test-NetConnection;
curl;
navegador.

Com VPN

Repita exatamente os mesmos testes.

Compare:

DNS;
IP retornado;
rota;
porta;
IPv4/IPv6;
resultado do navegador.

A VPN pode modificar muitas coisas simultaneamente.

Por isso, ela é ótima para comparação, mas ruim para conclusões simplistas.

Quando o problema está no Split DNS

Um domínio interno pode existir apenas na rede corporativa.

Exemplo:

intranet.empresa.local

O DNS público não conhece esse nome.

Se a VPN deveria enviar a consulta ao DNS corporativo, mas não envia, teremos:

nslookup usando DNS público
→ falha

ou respostas inconsistentes.

Nesse caso, o diagnóstico deve olhar para:

DNS da VPN;
NRPT;
rota;
split DNS;
configuração do cliente VPN.

Quando trocar para Google DNS ou Cloudflare faz sentido?

Pode fazer sentido se:

o DNS atual apresenta falhas;
respostas estão incorretas;
existe instabilidade;
o teste comparativo comprova comportamento melhor em outro resolvedor.

Mas não faça isso automaticamente em:

domínio corporativo;
VPN;
Active Directory;
redes com Split DNS;
ambientes com políticas específicas.

Nesses casos, um DNS público pode quebrar a resolução interna.

Quando o problema definitivamente não é DNS?

Se temos:

Resolve-DnsName → OK
nslookup → OK
curl mostra IP correto

e a falha ocorre:

depois da conexão

então a prioridade deve mudar.

Possíveis causas:

TLS;
HTTP;
proxy;
MTU;
firewall;
servidor;
CDN;
aplicação.

DNS pode estar completamente correto.

Mensagens de erro do navegador ajudam?

Sim, desde que interpretadas com cuidado.

Mensagens relacionadas a:

nome não resolvido;
conexão recusada;
timeout;
certificado;
proxy;
conexão resetada;

apontam para etapas diferentes.

Não trate todas como “erro de Internet”.

O texto do erro pode indicar onde começar.

Erro de nome não resolvido

Esse cenário normalmente coloca DNS mais alto na lista de suspeitos.

Investigue:

DNS configurado;
DoH;
hosts;
VPN;
NRPT;
cache;
registro inexistente.

Erro de conexão recusada

Isso significa algo diferente.

Pode indicar que o host foi alcançado, mas o serviço recusou a conexão.

Possíveis causas:

serviço parado;
porta fechada;
firewall;
aplicação não ouvindo.

Nesse caso, DNS já pode ter funcionado perfeitamente.

Timeout

Timeout é mais amplo.

Pode indicar:

rota;
firewall;
servidor;
perda;
MTU;
rede;
bloqueio.

Timeout sozinho não comprova DNS.

Erro de certificado

Se o navegador chegou ao ponto de validar um certificado, muita coisa já funcionou antes:

resolução;
conectividade;
transporte;
parte da negociação TLS.

A prioridade passa a ser:

certificado;
relógio;
cadeia;
interceptação;
proxy;
inspeção HTTPS.

O relógio errado pode parecer problema de Internet

Se data e hora do Windows estão incorretas, certificados HTTPS podem ser considerados inválidos.

O usuário pode dizer:

“Nenhum site seguro abre.”

Mas o DNS está funcionando.

Nesse caso, a causa pode ser o relógio.

Isso mostra novamente por que precisamos observar a etapa real da falha.

Extensões podem bloquear sites

Bloqueadores, antivírus, filtros e extensões podem interferir em:

scripts;
cookies;
requisições;
redirecionamentos;
conteúdo externo.

Se apenas um navegador apresenta falha, teste um perfil limpo ou outro navegador antes de alterar a rede.

HTTP/3 e QUIC

Alguns navegadores podem utilizar HTTP/3 sobre QUIC/UDP.

Isso significa que uma página pode se comportar de maneira diferente entre:

TCP;
UDP;
HTTP/2;
HTTP/3.

Se a rede bloqueia ou trata UDP de maneira inadequada, o navegador pode apresentar comportamento diferente de ferramentas que usam TCP.

Esse é um diagnóstico mais avançado, mas vale lembrar em casos persistentes.

Quando MTU entra novamente na análise?

Se:

DNS resolve;
TCP conecta;
página começa a carregar;
tráfego maior trava;
comportamento muda com VPN;
pacotes menores funcionam;

então MTU/PMTUD merece investigação.

Esse cenário é bem diferente de um domínio que simplesmente não resolve.

Um caso completo: domínio resolve, mas site continua inacessível

Imagine:

nslookup exemplo.com → OK

Resolve-DnsName exemplo.com → OK

Test-NetConnection exemplo.com -Port 443 → True

curl -v https://exemplo.com → falha durante TLS

Agora sabemos que:

DNS funciona;
porta TCP está acessível;
a falha ocorre depois.

A prioridade pode ser:

TLS;
proxy;
certificado;
inspeção HTTPS;
MTU.

Isso é muito mais preciso que apenas “site não abre”.

Outro caso: apenas domínio interno falha

Temos:

google.com → funciona

empresa.local → falha

VPN conectada.

Agora investigamos:

DNS corporativo;
Split DNS;
NRPT;
interface VPN;
política.

Trocar para DNS público pode piorar.

Outro caso: apenas um navegador falha

Temos:

Edge → funciona

Chrome → falha

curl → funciona

A rede está muito provavelmente funcional.

Prioridade:

Chrome;
DoH;
perfil;
extensão;
proxy;
cache.

Outro caso: VPN faz o site funcionar

Sem VPN:

site → falha

Com VPN:

site → funciona

A VPN pode ter mudado:

DNS;
rota;
IP público;
CDN;
MTU;
IPv4/IPv6.

Então a conclusão correta é:

o caminho mudou.

Não necessariamente:

a operadora bloqueou o site.

Checklist técnico completo

Quando nslookup funciona mas o site não abre, siga esta ordem:

Execute nslookup dominio.
Execute Resolve-DnsName dominio.
Veja os DNS com ipconfig /all.
Confira Get-DnsClientServerAddress.
Verifique políticas com Get-DnsClientNrptPolicy.
Compare DNS diferentes.
Consulte registros A e AAAA.
Teste IPv4 e IPv6 separadamente.
Verifique a porta 443 com Test-NetConnection.
Teste com curl -v.
Teste outro navegador.
Verifique DNS seguro/DoH.
Examine o arquivo hosts.
Confira proxy.
Compare com e sem VPN.
Observe APIs/CDNs nas ferramentas do navegador.
Só depois limpe cache ou altere DNS.

Erros comuns durante o diagnóstico

1. Concluir que DNS está perfeito só porque o NSLOOKUP respondeu

Ele comprovou apenas uma parte da resolução.

2. Executar flushdns como primeira solução

Isso pode resolver cache antigo, mas não problemas de rota, proxy ou TLS.

3. Trocar para 8.8.8.8 sem entender a rede

Pode quebrar domínios corporativos.

4. Ignorar DoH

O navegador pode utilizar um caminho diferente.

5. Ignorar IPv6

O DNS pode entregar AAAA e a falha estar no caminho IPv6.

6. Ignorar HOSTS

Uma entrada local pode modificar o destino usado pelas aplicações.

7. Culpar a operadora porque VPN funciona

A VPN altera várias variáveis ao mesmo tempo.

8. Reiniciar o roteador sem coletar evidências

Pode apagar temporariamente o sintoma sem explicar a causa.

Perguntas frequentes

Se o NSLOOKUP funciona, o DNS está funcionando?

A consulta realizada pelo nslookup recebeu resposta. Isso não garante que todas as aplicações estejam usando exatamente o mesmo caminho de resolução nem que o site esteja acessível.

O navegador pode usar DNS diferente do Windows?

Sim, dependendo da configuração, suporte a DNS over HTTPS, políticas e ambiente.

O que é DNS over HTTPS?

É um mecanismo que transporta consultas DNS através de HTTPS para um resolvedor compatível.

Flushdns resolve site que não abre?

Somente se a causa estiver relacionada ao cache DNS do Windows. Não corrige problemas de rota, proxy, VPN, TLS ou servidor.

Posso trocar para Google DNS ou Cloudflare?

Pode ser útil em determinados cenários, mas não deve ser feito automaticamente, especialmente em redes corporativas e VPNs.

IPv6 pode causar site que não abre?

Pode existir falha no caminho IPv6 enquanto IPv4 funciona normalmente. Isso não significa que IPv6 seja o problema em todos os casos.

HOSTS pode interferir mesmo se NSLOOKUP estiver correto?

Sim. O nslookup consulta DNS, enquanto o arquivo hosts pode alterar localmente a resolução usada por aplicações.

VPN pode mudar o DNS?

Sim. VPNs podem configurar DNS próprios, políticas de resolução, rotas e split DNS.

Proxy pode afetar apenas alguns sites?

Sim. Regras de proxy e scripts PAC podem direcionar destinos diferentes por caminhos diferentes.

Se Test-NetConnection na porta 443 funciona, o site deveria abrir?

Não necessariamente. A conexão TCP pode funcionar e a falha ocorrer depois, durante TLS, HTTP, proxy ou aplicação.

Conclusão

Quando o nslookup funciona mas o site não abre, a pior abordagem é concluir imediatamente que “o DNS está bom” ou, no extremo oposto, trocar os servidores DNS sem investigar.

A resolução de nomes é apenas uma etapa.

O caminho completo envolve:

DNS → IP → rota → transporte → TLS → HTTP → aplicação

Além disso, o próprio processo de resolução pode variar entre:

Windows;
navegador;
VPN;
proxy;
DoH;
políticas corporativas.

Por isso, o diagnóstico correto precisa responder uma pergunta simples:

em qual etapa a comunicação parou?

Quando fazemos isso, o problema deixa de ser “misterioso” e passa a ser uma sequência técnica verificável.

Precisa descobrir por que um site não abre no seu computador?

A VMIA – Manutenção e Configuração realiza diagnóstico de problemas de Internet, DNS, Windows, VPN, navegadores, Wi-Fi, roteadores e redes.

Situações como:

nslookup funciona, mas o site não abre;
alguns navegadores funcionam e outros não;
VPN conecta, mas sistemas internos não resolvem;
sites funcionam apenas em IPv4;
DNS seguro interfere na navegação;
proxy ou rede corporativa causa comportamento diferente;

podem exigir uma análise por camadas para identificar a verdadeira causa.

A VMIA oferece atendimento técnico com agendamento, incluindo suporte remoto quando a falha pode ser analisada à distância e atendimento presencial quando é necessário verificar a infraestrutura local.