A Internet está conectada. O Google abre. O YouTube funciona. Talvez até um teste de velocidade mostre a velocidade contratada. Porém, quando você tenta acessar determinados sites, eles simplesmente não carregam.

Em outro computador ou no celular conectado à mesma rede, esses mesmos sites podem funcionar normalmente.

É um dos problemas de rede mais confusos do Windows 11:

Por que alguns sites abrem normalmente enquanto outros não carregam?

A primeira reação costuma ser culpar o navegador.

Depois aparecem as recomendações tradicionais:

• limpar cache;
• reiniciar o computador;
• reiniciar o roteador;
• trocar o DNS;
• executar ipconfig /flushdns;
• desativar IPv6.

Algumas dessas ações podem fazer sentido em situações específicas.

O problema é executá-las sem descobrir primeiro em qual camada a comunicação está falhando.

Quando apenas alguns sites deixam de funcionar, várias causas são possíveis.

Entre elas:

• falha de resolução DNS;
• registro DNS incorreto ou desatualizado;
• cache DNS;
• problema somente com IPv6;
• problema somente com IPv4;
• MTU incompatível com determinado caminho;
• VPN;
• proxy;
• firewall;
• software de segurança;
• extensão do navegador;
• cache do navegador;
• problema no próprio site;
• CDN;
• rota entre a operadora e determinado destino.

Neste guia da VMIA, vamos investigar cada hipótese separadamente.

O objetivo não será simplesmente fazer o site voltar a abrir.

Queremos descobrir:

Por que ele não estava abrindo?

---

Primeiro: confirme exatamente qual é o problema

Antes de executar qualquer comando, faça uma pequena lista.

Por exemplo:

google.com        abre
youtube.com       abre
site-a.com        não abre
site-b.com        não abre

Depois teste os mesmos endereços em outro dispositivo.

Preferencialmente, compare:

Computador com problema

versus:

outro computador na mesma rede

e, quando possível:

celular no Wi-Fi

versus:

celular usando rede móvel.

Essas comparações fornecem informações extremamente importantes.

---

Se o site não abre em nenhum dispositivo

Se determinado site não funciona:

• no seu computador;
• em outro computador;
• no celular pelo Wi-Fi;
• e talvez nem pela rede móvel;

considere a possibilidade de o problema estar no próprio serviço.

Não altere toda a configuração do Windows antes de verificar isso.

---

Se abre no celular, mas não no computador

Agora o diagnóstico muda.

Se ambos estão conectados ao mesmo roteador e apenas o PC apresenta o problema, devemos investigar algo específico daquele computador.

Possibilidades incluem:

• DNS diferente;
• cache;
• navegador;
• VPN;
• proxy;
• firewall;
• software de segurança;
• IPv4/IPv6;
• arquivo Hosts;
• configuração da interface.

---

Se abre no celular pela rede móvel, mas não pelo Wi-Fi

Essa comparação também é importante.

Agora mudamos simultaneamente:

• dispositivo ou interface;
• caminho;
• provedor;
• endereço público;
• DNS possivelmente utilizado;
• rota até o destino.

Portanto, o teste prova que o site está acessível por algum caminho, mas não identifica sozinho qual componente da sua rede está causando a diferença.

---

Se um navegador abre e outro não

Esse teste reduz bastante o campo de investigação.

Suponha:

Chrome não abre.

Edge abre.

A conexão IP do computador obviamente não está totalmente indisponível.

Agora ganham força hipóteses relacionadas a:

• navegador;
• perfil;
• extensão;
• proxy específico;
• cache;
• cookies;
• configurações;
• software que interfere naquele navegador.

Não comece alterando MTU do roteador.

---

O erro exibido pelo navegador importa

Não trate todas as telas de erro como iguais.

Observe se aparece algo relacionado a:

• DNS;
• tempo limite;
• conexão recusada;
• certificado;
• conexão redefinida;
• endereço inacessível.

Copie a mensagem ou o código de erro antes de alterar configurações.

Esse detalhe pode mudar completamente o diagnóstico.

---

Primeira hipótese: DNS

DNS é frequentemente culpado quando alguns sites não abrem.

Às vezes corretamente.

Às vezes não.

O DNS permite que nomes sejam resolvidos para endereços necessários à comunicação.

Quando digitamos um domínio no navegador, precisamos descobrir para onde aquela conexão deve seguir.

Se essa resolução falha, o site pode não abrir mesmo que a conexão com a Internet esteja funcionando.

---

Comece pelo ipconfig /all

Abra o Terminal ou Prompt de Comando e execute:

ipconfig /all

Procure o adaptador que realmente está sendo utilizado.

Pode ser:

Wi-Fi

ou:

Ethernet.

Observe principalmente:

• endereço IPv4;
• gateway padrão;
• servidores DNS;
• DHCP;
• IPv6.

Não analise uma interface desconectada por engano.

---

Por que olhar o DNS configurado?

Imagine que o computador problemático usa:

DNS: 192.168.1.1

Outro computador utiliza outra configuração.

Essa diferença não prova que encontramos a causa.

Mas cria uma hipótese.

Podemos testá-la.

---

Use nslookup

Agora execute:

nslookup dominio.com

Substitua dominio.com pelo site que apresenta problema.

O comando pode mostrar informações sobre o servidor DNS utilizado e a resposta recebida.

Faça o mesmo com um domínio que funciona.

Por exemplo:

nslookup site-que-funciona.com

e:

nslookup site-com-problema.com

Compare.

---

O que estamos tentando descobrir?

Queremos saber:

O domínio problemático está sendo resolvido?

Se não existe uma resposta adequada, DNS passa a ser uma hipótese forte.

Se a resolução funciona normalmente, não conclua:

“Então o site obrigatoriamente deveria abrir.”

DNS é apenas uma etapa.

Ainda existem:

• conexão TCP;
• TLS;
• IPv4/IPv6;
• rota;
• firewall;
• servidor;
• aplicação.

---

Um nslookup funcionando não prova que o navegador funcionará

Esse é um detalhe importante.

nslookup é uma ferramenta de diagnóstico DNS.

O navegador participa de uma pilha muito maior.

Além disso, navegadores modernos podem possuir comportamentos e recursos próprios relacionados à resolução, segurança e conexão.

Portanto:

nslookup funciona + navegador falha

é uma informação excelente.

Ela reduz algumas hipóteses, mas não encerra o diagnóstico.

---

Teste outro servidor DNS sem mudar a configuração inteira

Uma técnica interessante é consultar diretamente um servidor específico.

Exemplo:

nslookup dominio.com 8.8.8.8

Também podemos comparar com outro resolvedor conhecido.

A intenção não é afirmar que determinado DNS é “mais rápido”.

Estamos fazendo um teste A/B:

Servidores diferentes respondem de forma diferente para esse domínio?

---

Se um DNS responde e outro não

Agora temos uma pista muito mais concreta.

Precisamos investigar:

• servidor DNS atualmente configurado;
• cache;
• roteador;
• encaminhamento DNS;
• problema temporário do resolvedor.

Só agora considerar alterar o DNS fica tecnicamente mais justificável.

---

ipconfig /displaydns

Antes de limpar o cache, podemos observá-lo:

ipconfig /displaydns

Esse comando mostra informações presentes no cache do resolvedor DNS do Windows.

Se a saída for muito grande, podemos salvá-la:

ipconfig /displaydns > "%USERPROFILE%\Desktop\dns-cache.txt"

Agora procure pelo domínio problemático.

---

Só depois pense em flushdns

Se existe uma hipótese coerente envolvendo cache local, execute:

ipconfig /flushdns

Depois teste novamente.

Não use esse resultado de maneira simplista.

Se o site voltou a funcionar depois do flushdns, pergunte:

O que havia mudado na resolução e por que aquela entrada estava causando o problema?

---

Flushdns não corrige MTU

Essa distinção é fundamental.

ipconfig /flushdns não:

• aumenta velocidade;
• corrige Wi-Fi;
• altera MTU;
• corrige rota;
• repara IPv6;
• reinicia a placa de rede.

Ele limpa o cache do resolvedor DNS.

---

Segunda hipótese: IPv6

Agora chegamos a um diagnóstico muito mais interessante.

Um site moderno pode possuir registros DNS relacionados a IPv4 e IPv6.

O computador pode ter conectividade IPv6 configurada e tentar utilizá-la quando apropriado.

Se a conectividade IPv6 estiver parcialmente quebrada, podemos encontrar um comportamento estranho:

alguns destinos funcionam e outros apresentam demora ou falha.

---

Por que alguns sites funcionariam?

Porque nem todos os destinos são alcançados exatamente da mesma maneira.

Podemos ter diferenças envolvendo:

• disponibilidade IPv6;
• disponibilidade IPv4;
• CDN;
• endereços retornados;
• rota;
• preferência do sistema;
• mecanismos de fallback.

Portanto, uma falha parcial pode afetar determinados destinos e deixar outros aparentemente normais.

---

Não desative IPv6 como primeira solução

Essa recomendação aparece em muitos tutoriais:

“Alguns sites não abrem? Desative IPv6.”

Isso pode fazer o sintoma desaparecer em determinados casos.

Mas existe uma diferença enorme entre:

contornar um problema

e:

descobrir o problema.

Se IPv6 está falhando, queremos saber por quê.

---

Verifique IPv6 no ipconfig

Execute:

ipconfig /all

Procure o adaptador ativo.

Você pode encontrar:

• endereços IPv6;
• endereço link-local;
• gateway relacionado à configuração IPv6;
• outras informações.

Não interprete a simples presença de:

fe80::...

como prova de conectividade IPv6 com a Internet.

Um endereço link-local possui escopo específico.

---

Teste IPv4 e IPv6 separadamente

O ping do Windows permite direcionar testes por família de endereços em cenários apropriados.

Podemos utilizar:

ping -4 dominio.com

e:

ping -6 dominio.com

O objetivo é comparar.

Mas existe uma ressalva:

Nem todo servidor responde ICMP.

Portanto, falha de ping não significa automaticamente que o site está fora do ar.

Ainda assim, comparar resolução e caminho IPv4/IPv6 pode produzir pistas importantes.

---

Teste a resolução

Use:

nslookup dominio.com

Observe se aparecem endereços IPv4 e/ou IPv6 conforme os registros disponibilizados.

Agora temos uma pergunta melhor:

O site problemático possui conectividade por uma família que está apresentando falha no meu computador ou na minha rede?

---

Test-NetConnection também pode ajudar

No PowerShell, podemos utilizar:

Test-NetConnection dominio.com -Port 443

A porta 443 é normalmente utilizada por HTTPS.

Esse teste pode ajudar a responder:

Consigo estabelecer conectividade TCP até esse destino nessa porta?

Isso é diferente de simplesmente perguntar se o domínio responde a ping.

---

Site não responder ping e abrir normalmente é possível

Sim.

Um servidor ou firewall pode não responder às solicitações ICMP utilizadas pelo ping e ainda aceitar normalmente conexões HTTPS.

Por isso:

ping é teste, não veredito.

---

Terceira hipótese: MTU

Agora chegamos à parte que costuma confundir até usuários mais experientes.

MTU significa:

Maximum Transmission Unit.

De forma simplificada, representa o tamanho máximo de pacote que uma interface pode transmitir em determinado contexto sem precisar de tratamento adicional relacionado ao tamanho.

Em Ethernet, um valor muito conhecido é:

1500 bytes

Mas isso não significa que 1500 seja obrigatoriamente o valor correto em todos os caminhos e tecnologias.

---

Como MTU pode fazer apenas alguns sites falharem?

Imagine que pacotes pequenos passam normalmente.

Consultas DNS funcionam.

O início da comunicação também parece funcionar.

Mas em determinado momento, pacotes maiores encontram um problema ao longo do caminho.

Dependendo do cenário, isso pode produzir sintomas como:

• site começa a carregar e trava;
• página fica parcialmente carregada;
• determinado serviço não abre;
• VPN apresenta comportamento estranho;
• upload trava;
• alguns destinos funcionam e outros não.

Esse tipo de problema é muito mais traiçoeiro que uma Internet completamente offline.

---

Path MTU Discovery

Os sistemas precisam lidar com o fato de que diferentes segmentos do caminho podem aceitar tamanhos diferentes.

Mecanismos de descoberta de MTU do caminho ajudam os hosts a ajustar a comunicação.

Problemas podem surgir quando informações necessárias para esse processo não chegam corretamente ou quando existe configuração inadequada no caminho.

---

O famoso teste com ping -f -l

No IPv4, o ping do Windows oferece parâmetros que podem ajudar em testes relacionados a fragmentação.

Exemplo:

ping -f -l 1472 destino

Mas existe um detalhe extremamente importante:

1472 não significa MTU 1472.

No cenário clássico IPv4 sem opções adicionais, precisamos considerar os cabeçalhos IPv4 e ICMP.

Por isso, 1472 bytes de payload ICMP + 28 bytes de cabeçalhos resulta em 1500 bytes.

Essa é a origem do número muito utilizado nesses testes.

---

Não transforme 1472 em número mágico

O teste precisa ser interpretado no contexto.

Se o pacote precisa atravessar um caminho com MTU menor, podemos reduzir progressivamente o tamanho e observar o comportamento.

Mas isso não significa que devemos sair alterando MTU do Windows até o site abrir.

Primeiro:

meça.

Depois:

compare.

Só então:

formule uma hipótese.

---

Exemplo conceitual

Teste:

ping -f -l 1472 destino

Se houver indicação de necessidade de fragmentação ou comportamento compatível com limitação do caminho, tente um tamanho menor.

Por exemplo:

ping -f -l 1464 destino

Depois continue ajustando de maneira controlada.

O objetivo é identificar o maior tamanho que atravessa o caminho naquele teste.

---

Mas cuidado novamente com ICMP

O destino pode:

• bloquear ping;
• limitar respostas;
• tratar ICMP de forma diferente.

Portanto, um teste isolado não prova sozinho um problema de MTU.

Precisamos correlacionar com o sintoma.

---

Quando suspeitar mais fortemente de MTU?

Alguns sinais aumentam a suspeita:

• vários sites funcionam e alguns travam;
• conexão VPN apresenta problema;
• determinadas páginas começam a carregar e param;
• upload falha em situações específicas;
• mudança de roteador, VPN ou tecnologia de conexão precedeu o problema;
• pacotes menores funcionam enquanto maiores apresentam comportamento consistente.

Mesmo assim, investigue antes de alterar.

---

PPPoE pode mudar o cenário

Determinadas conexões utilizam encapsulamentos ou protocolos que reduzem o espaço disponível para o tráfego IP dentro do quadro.

PPPoE é um exemplo conhecido.

Por isso, não existe uma regra universal:

“Toda Internet deve usar MTU 1500.”

A configuração depende da tecnologia e do caminho.

---

VPN também pode afetar MTU

Uma VPN adiciona encapsulamento.

Isso pode reduzir o tamanho útil disponível antes que o pacote precise de tratamento adicional.

Se o problema começou imediatamente após instalar ou ativar uma VPN, faça um teste controlado:

VPN ligada

versus:

VPN desligada.

Se o comportamento muda consistentemente, temos uma pista.

---

Quarta hipótese: proxy

Um proxy também pode criar um cenário curioso:

• alguns programas funcionam;
• navegador funciona parcialmente;
• determinados destinos falham.

Verifique se existe proxy configurado quando houver motivo para suspeitar.

No Windows, configurações de proxy podem ser utilizadas por diferentes componentes de maneiras distintas.

Também existe o contexto WinHTTP utilizado por determinados serviços e aplicativos.

---

Quinta hipótese: arquivo Hosts

O Windows possui um arquivo Hosts que pode associar nomes a endereços localmente.

Uma entrada incorreta pode fazer apenas um domínio específico apontar para o lugar errado.

Isso cria exatamente o sintoma:

“Todo o resto funciona, menos aquele site.”

Não altere o arquivo sem necessidade.

Mas, se apenas domínios específicos falham persistentemente naquele computador, vale incluí-lo na investigação.

---

Sexta hipótese: firewall ou antivírus

Softwares de segurança podem interferir em:

• conexões;
• inspeção HTTPS;
• DNS;
• filtragem de conteúdo;
• certificados;
• aplicativos.

Não significa que devemos desativar toda proteção como primeira medida.

Isso seria um teste ruim e pode reduzir a segurança do computador.

Procure:

• logs;
• bloqueios;
• notificações;
• regras;
• correlação temporal.

---

Sétima hipótese: o próprio navegador

Se:

Edge abre

e:

Chrome não abre

o diagnóstico deve começar perto do navegador.

Teste:

• janela privada;
• extensões;
• perfil;
• configurações;
• atualização;
• cache.

Mas faça alterações uma de cada vez.

---

O modo privado é um teste útil

Abrir uma janela privada pode reduzir a influência de alguns elementos da sessão normal.

Se o site funciona nela, isso é uma pista.

Ainda não é a causa definitiva.

Pode haver diferença envolvendo:

• cookies;
• cache;
• extensões;
• sessão;
• perfil.

---

O problema pode ser certificado

Se a página apresenta erro relacionado a certificado ou TLS, não trate isso como problema de DNS simplesmente porque o site não abriu.

Verifique:

• data e hora do computador;
• mensagem exata;
• certificado apresentado;
• software de inspeção HTTPS;
• rede utilizada.

Erros de segurança merecem investigação própria.

---

Não ignore data e hora do Windows

Uma data ou hora muito incorreta pode causar problemas de validação de certificados e autenticação.

O usuário percebe:

“Alguns sites não abrem.”

Mas a causa pode não ter relação com DNS ou MTU.

---

O problema também pode estar fora do seu computador

Suponha:

• DNS resolve;
• IPv4 funciona;
• IPv6 funciona;
• navegador está normal;
• outro site funciona;
• apenas determinado destino apresenta falha.

Ainda podemos ter:

• servidor indisponível;
• CDN;
• rota;
• problema de peering;
• bloqueio regional;
• falha temporária do serviço.

Não existe comando local capaz de corrigir um servidor remoto indisponível.

---

Tracert pode ajudar

Execute:

tracert dominio.com

O comando ajuda a observar o caminho até o destino.

Mas cuidado ao interpretar.

Um salto intermediário sem resposta não significa necessariamente falha.

Da mesma forma, um salto intermediário com latência alta isolada não prova que ele está atrasando todo o tráfego.

O importante é observar o comportamento do caminho como conjunto.

---

Compare um site funcional com um problemático

Essa metodologia é excelente.

Execute testes semelhantes para:

Site A — funciona

e:

Site B — não funciona.

Compare:

• DNS;
• IPv4;
• IPv6;
• conectividade TCP;
• rota;
• navegador.

Agora temos um experimento controlado.

---

A pergunta correta não é “qual comando conserta?”

A pergunta correta é:

Em qual etapa os resultados começam a ficar diferentes?

Essa diferença frequentemente revela onde devemos investigar.

---

Árvore inicial de diagnóstico

Quando alguns sites abrem e outros não:

1. O site funciona em outro dispositivo?

Se não:

investigue o serviço ou a rede.

Se sim:

continue.

2. Funciona em outro navegador no mesmo PC?

Se sim:

investigue navegador/perfil/extensões.

Se não:

continue.

3. DNS resolve?

Use:

nslookup dominio.com

Se não:

investigue DNS.

Se sim:

continue.

4. IPv4 e IPv6 apresentam comportamento diferente?

Compare quando aplicável.

Se sim:

investigue a pilha ou conectividade da família problemática.

5. A porta HTTPS está acessível?

Use ferramentas como:

Test-NetConnection dominio.com -Port 443

6. Existe VPN ou proxy?

Faça comparação controlada.

7. Há indícios de MTU?

Teste somente depois de eliminar hipóteses mais simples.

---

DNS, IPv6 ou MTU: como diferenciar?

Podemos resumir assim:

Suspeite de DNS quando:

• o domínio não resolve;
• servidores DNS diferentes respondem de maneira diferente;
• IP funciona, nome não;
• cache contém informação problemática;
• outro dispositivo utiliza DNS diferente e funciona.

Suspeite de IPv6 quando:

• destinos com determinadas características falham;
• IPv4 e IPv6 apresentam resultados consistentemente diferentes;
• o problema acompanha a conectividade IPv6;
• há evidência de configuração ou rota IPv6 inadequada.

Suspeite de MTU quando:

• conexões começam mas travam;
• pacotes pequenos funcionam;
• há relação com VPN/PPPoE/túnel;
• mudança de infraestrutura precedeu o problema;
• testes controlados de tamanho apontam limitação consistente.

---

Não altere os três de uma vez

Imagine:

1. troca DNS;
2. desativa IPv6;
3. muda MTU;
4. reinicia.

O site abre.

Qual era a causa?

Você não sabe.

Além disso, pode ter criado uma configuração desnecessária que permanecerá no computador por meses.

---

Metodologia VMIA

Prefira:

Estado original

↓

Teste

↓

Uma alteração

↓

Novo teste

↓

Comparação

↓

Conclusão

Esse método pode parecer mais demorado no começo.

Na prática, evita horas tentando corrigir efeitos colaterais criados por alterações aleatórias.

---

Antes de alterar qualquer configuração de rede

Registre:

ipconfig /all

Você também pode salvar:

ipconfig /all > "%USERPROFILE%\Desktop\rede-antes.txt"

Se precisar alterar algo posteriormente, terá uma referência do estado inicial.

Isso é especialmente importante ao mexer em:

• DNS;
• IPv4;
• IPv6;
• proxy;
• VPN;
• MTU.

Na primeira parte estabelecemos uma regra importante:

Não altere DNS, IPv6 e MTU ao mesmo tempo.

Quando apenas alguns sites não abrem, precisamos descobrir em qual ponto a comunicação começa a falhar.

Para isso, vamos transformar o problema em uma sequência de testes.

---

Caso 1: o site abre no celular, mas não no computador

Este é provavelmente um dos cenários mais comuns.

Você tenta acessar determinado site no Windows 11.

Não funciona.

Pega o celular.

O site abre imediatamente.

A primeira conclusão costuma ser:

“Então o problema está no Windows.”

Talvez.

Mas precisamos observar como o teste foi realizado.

Se o celular estava usando 5G/4G e o computador estava no Wi-Fi, você alterou várias variáveis ao mesmo tempo.

Mudaram:

• dispositivo;
• conexão;
• operadora;
• endereço público;
• rota;
• DNS possivelmente utilizado.

Faça outro teste.

Conecte o celular ao mesmo Wi-Fi utilizado pelo computador.

Agora tente novamente.

---

Monte uma matriz simples

Dispositivo	Conexão	Site abre?
PC	Wi-Fi	Não
Celular	mesmo Wi-Fi	Sim
Celular	rede móvel	Sim

Agora a evidência contra um problema geral no roteador ou na operadora fica mais forte.

Se o celular funciona no mesmo Wi-Fi, concentre a investigação no computador.

---

Compare o DNS

No Windows:

ipconfig /all

Localize o adaptador Wi-Fi.

Veja os servidores DNS.

Depois:

nslookup dominio.com

Se o domínio resolve normalmente, registre o endereço retornado.

Não execute flushdns ainda.

---

Teste o mesmo domínio mais de uma vez

Serviços modernos podem utilizar:

• múltiplos endereços;
• balanceamento;
• CDN;
• respostas DNS diferentes.

Portanto, uma única resposta não deve ser tratada automaticamente como o único endereço possível daquele serviço.

O objetivo é descobrir se existe uma diferença consistente.

---

Consulte outro resolvedor

Por exemplo:

nslookup dominio.com 8.8.8.8

e, como comparação:

nslookup dominio.com 1.1.1.1

Estamos perguntando diretamente a resolvedores diferentes.

Se todos retornam respostas coerentes, a hipótese de uma falha simples do servidor DNS configurado perde força.

Se apenas o DNS atual falha repetidamente, a hipótese ganha força.

---

Não compare apenas os números retornados

Duas respostas diferentes não significam necessariamente que uma esteja errada.

CDNs e balanceamento podem retornar endereços diferentes dependendo de:

• localização;
• resolvedor;
• disponibilidade;
• infraestrutura do serviço.

A pergunta é:

A resposta permite chegar ao serviço corretamente?

---

Caso 2: nslookup funciona, mas o navegador não abre

Esse cenário é extremamente importante.

Execute:

nslookup dominio.com

O domínio resolve.

Mesmo assim, o navegador apresenta erro.

Isso significa que:

A resolução feita pelo nslookup funcionou.

Não significa que toda a cadeia necessária ao navegador esteja funcionando.

Ainda precisamos investigar:

• conectividade TCP;
• TLS;
• navegador;
• proxy;
• VPN;
• firewall;
• IPv4;
• IPv6;
• servidor.

---

Teste a porta 443

Abra o PowerShell e execute:

Test-NetConnection dominio.com -Port 443

Procure principalmente o resultado relacionado ao teste TCP.

Se a conexão TCP à porta 443 funciona, sabemos que existe conectividade até aquele serviço nessa porta no contexto daquele teste.

Se falha, precisamos investigar mais abaixo.

---

Ping funcionar não substitui Test-NetConnection

Um erro comum é:

ping dominio.com

responde.

Então:

“A Internet está perfeita.”

Não necessariamente.

O ping testa ICMP.

O navegador normalmente precisa estabelecer conexões utilizando outros protocolos, como TCP para HTTPS em muitos cenários.

Um pode funcionar enquanto o outro falha.

---

O inverso também acontece

O site abre normalmente.

Mas:

ping dominio.com

não responde.

Isso também é possível.

O servidor ou infraestrutura pode bloquear ou limitar ICMP.

Portanto:

site não responder ping não significa site offline.

---

Caso 3: o site abre no Edge, mas não abre no Chrome

Agora temos uma pista muito forte.

O mesmo:

• computador;
• adaptador;
• roteador;
• conexão;
• sistema operacional;

consegue acessar o destino usando outro navegador.

Antes de alterar MTU, investigue o navegador problemático.

---

Teste uma janela privada

Abra uma janela privada/anônima e tente acessar o site.

Se funciona, temos evidência de que algo relacionado ao perfil normal pode participar do problema.

Investigue:

• extensões;
• cookies;
• dados armazenados;
• perfil;
• configurações específicas.

---

Desative todas as extensões?

Não precisa começar assim.

Se você desativa quinze extensões simultaneamente e o problema desaparece, ainda não sabe qual delas interferia.

Prefira testes controlados.

---

Limpar todo o navegador também destrói evidências

Outro erro:

“Limpe tudo.”

Cookies, cache, sessões, dados salvos.

Talvez funcione.

Mas você perdeu a oportunidade de descobrir o componente responsável e ainda pode desconectar contas e alterar a experiência do usuário.

Comece pelo menos invasivo.

---

Caso 4: site abre com VPN, mas não abre sem VPN

Esse é um caso extremamente interessante.

Quando você ativa uma VPN, várias coisas podem mudar:

• rota;
• endereço público;
• DNS;
• caminho até o destino;
• MTU efetiva;
• política de rede.

Portanto:

“Funciona com VPN” não significa automaticamente que a operadora está bloqueando o site.

É apenas uma evidência de que o caminho alternativo funciona.

---

Como investigar?

Faça:

VPN desligada

nslookup dominio.com

Registre o resultado.

Depois observe:

ipconfig /all

e, quando apropriado:

tracert dominio.com

Agora repita a comparação com a VPN ativa.

Procure diferenças.

---

A VPN pode esconder um problema de rota

Sem VPN:

PC → roteador → operadora → rota A → destino

Com VPN:

PC → roteador → operadora → servidor VPN → rota B → destino

Se apenas a segunda funciona, pode existir diferença no caminho.

---

A VPN também pode mudar DNS

Isso é fundamental.

Talvez o site não tenha começado a funcionar porque o tráfego “saiu por outro país”.

Talvez a VPN simplesmente tenha configurado outro resolvedor DNS.

Por isso, compare:

ipconfig /all

antes e depois.

---

Caso 5: site começa a carregar e trava

Esse comportamento merece atenção especial.

Imagine:

• DNS resolve;
• conexão começa;
• título aparece;
• parte da página carrega;
• depois fica esperando.

Isso é diferente de:

“O domínio não existe.”

Agora ganham força hipóteses como:

• recursos hospedados em outros domínios;
• CDN;
• conexão específica;
• IPv6;
• MTU;
• firewall;
• inspeção HTTPS;
• navegador.

---

Uma página não vem de um único servidor

Sites modernos podem carregar recursos de vários lugares.

Por exemplo:

www.exemplo.com
static.exemplo.com
cdn.exemplo.net
api.exemplo.com

O domínio principal pode funcionar enquanto um recurso essencial hospedado em outro destino falha.

Resultado:

página incompleta ou travada.

---

Isso explica por que “o site responde ping” não basta

Você pode estar testando:

www.exemplo.com

enquanto o navegador está travando ao tentar alcançar:

cdn.exemplo.net

São conexões diferentes.

---

Caso 6: DNS funciona, TCP funciona, mas a página apresenta erro de certificado

Agora não estamos diante de um problema simples de DNS.

Leia a mensagem exata do navegador.

Verifique primeiro:

• data;
• hora;
• fuso horário;
• certificado;
• software de segurança;
• proxy;
• inspeção HTTPS.

---

Nunca ignore o relógio do computador

Certificados possuem períodos de validade.

Se o relógio do computador está significativamente incorreto, validações podem falhar.

O sintoma pode parecer:

“Alguns sites não entram.”

Quando o problema real está na validação de segurança.

---

Não ignore avisos de certificado

Não transforme:

“Clique em continuar mesmo assim”

em procedimento padrão.

Um aviso pode indicar:

• configuração incorreta;
• interceptação;
• certificado inválido;
• problema no servidor;
• relógio incorreto.

Investigue antes de ignorar a proteção.

---

Caso 7: IPv4 funciona e IPv6 parece falhar

Vamos aprofundar essa hipótese.

Comece:

nslookup dominio.com

Procure respostas IPv4 e IPv6 quando existirem.

Depois compare:

ping -4 dominio.com

e:

ping -6 dominio.com

Novamente:

ICMP pode ser bloqueado.

Use o resultado apenas como parte da investigação.

---

O endereço IPv6 existe, mas isso não prova conectividade IPv6

Esse detalhe é fundamental.

ipconfig /all

pode mostrar:

fe80::...

Isso não prova que o computador possui conectividade IPv6 global com a Internet.

O endereço link-local serve a um contexto específico.

---

Teste rotas separadamente

O tracert também possui formas de direcionar a família IP.

Em sistemas que oferecem essas opções, consulte:

tracert /?

e utilize a sintaxe apropriada para comparar IPv4 e IPv6.

A ajuda local é importante porque mostra exatamente os parâmetros disponíveis naquela versão do Windows.

---

O objetivo não é provar que “IPv6 é ruim”

A pergunta é:

IPv4 e IPv6 apresentam comportamento consistentemente diferente para o mesmo problema?

Se sim, encontramos uma área para aprofundar.

---

Não desative IPv6 permanentemente como teste inicial

Imagine que você desativa IPv6.

O site volta a funcionar.

Isso é uma pista.

Mas a conclusão correta não é:

“IPv6 não presta.”

A conclusão é:

Quando removemos IPv6 daquele cenário, o comportamento mudou. Precisamos descobrir por quê.

---

Caso 8: suspeita de MTU

MTU deve entrar mais tarde na investigação.

Não porque seja irrelevante.

Mas porque:

• DNS;
• navegador;
• VPN;
• proxy;

costumam ser mais fáceis de comparar primeiro.

---

Como fazer um teste IPv4 relacionado ao tamanho

No Prompt de Comando:

ping -f -l 1472 destino

Nesse exemplo:

-f

solicita que o pacote IPv4 não seja fragmentado.

-l

define o tamanho dos dados enviados no eco ICMP.

---

Por que 1472?

No caso clássico:

1472 bytes de dados
+ 20 bytes de cabeçalho IPv4
+ 8 bytes de cabeçalho ICMP
= 1500 bytes

Por isso esse valor aparece em muitos testes relacionados a uma MTU de 1500.

---

Mas não assuma MTU 1500

Faça o teste.

Se o tamanho não atravessa o caminho, reduza.

Exemplo:

ping -f -l 1464 destino

Depois:

ping -f -l 1452 destino

Os valores são exemplos de investigação.

Você pode refinar progressivamente o teste.

---

Como calcular a MTU a partir do teste?

No cenário IPv4 tradicional sem opções adicionais, se o maior payload ICMP que passa com DF for, por exemplo:

1464

podemos considerar:

1464 + 28 = 1492

Isso sugere uma MTU de caminho de aproximadamente:

1492

naquele teste.

O número 1492 aparece frequentemente em contextos relacionados a PPPoE.

Mas não use essa associação como prova automática.

---

Teste também um destino funcional

Isso é muito importante.

Suponha:

site-a.com

funciona.

site-b.com

não.

Faça testes comparáveis para os dois destinos.

Se apenas o caminho problemático apresenta limitação consistente, isso fortalece a hipótese.

---

MTU errada pode gerar “Internet pela metade”

É justamente isso que torna esse problema tão interessante.

Pacotes pequenos podem funcionar.

DNS pode funcionar.

Ping pequeno pode funcionar.

Mas determinadas comunicações maiores podem falhar ou travar.

O usuário vê:

“Tenho Internet, mas algumas coisas não funcionam.”

---

Por que Path MTU Discovery importa?

Em condições normais, mecanismos de rede ajudam os hosts a descobrir limitações no caminho.

Problemas podem ocorrer quando mensagens necessárias a esse processo são filtradas ou quando algum equipamento trata incorretamente a situação.

Esse tipo de cenário é frequentemente chamado de problema de Path MTU Discovery.

---

ICMP bloqueado pode contribuir para problemas de PMTUD

Isso mostra por que a velha recomendação:

“Bloqueie todo ICMP por segurança”

pode ser problemática.

ICMP não serve apenas para ping.

Ele possui funções importantes para o funcionamento e diagnóstico das redes IP.

---

Caso 9: problema começou depois de instalar VPN

Agora MTU merece atenção maior.

Uma VPN adiciona encapsulamento.

Isso consome espaço.

Dependendo da tecnologia, configuração e caminho, o tamanho útil disponível para o tráfego interno pode precisar ser menor.

---

Não copie MTU de tutorial

Você encontra na Internet recomendações como:

1400

1420

1472

1492

1500

Qual está correta?

Sem conhecer:

• tecnologia;
• túnel;
• interface;
• caminho;

não podemos escolher apenas pelo número mais popular.

Meça.

---

Descubra o MTU configurado nas interfaces

O Windows oferece ferramentas de rede que permitem consultar informações das interfaces.

Uma opção tradicional é utilizar comandos netsh apropriados para a pilha IP.

Antes de alterar qualquer valor, consulte a ajuda:

netsh interface ipv4 show subinterfaces

Isso pode mostrar informações das interfaces, incluindo MTU no contexto correspondente.

Registre os valores antes de qualquer alteração.

---

Não altere MTU ainda

Encontrar:

1500

não significa:

“Achei o problema.”

Esse pode ser exatamente o valor esperado.

Precisamos primeiro demonstrar que existe incompatibilidade entre a configuração e o caminho.

---

Caso 10: site abre depois de reiniciar o roteador

Isso também não prova a causa.

Reiniciar o roteador pode alterar:

• estado de conexões;
• sessão com a operadora;
• endereço público;
• caches;
• rotas externas percebidas;
• processos internos.

Portanto:

“Reiniciei e voltou”

é um resultado.

Não necessariamente um diagnóstico.

---

Caso 11: problema acontece em todos os dispositivos do Wi-Fi

Agora olhamos menos para o Windows.

Se:

• PC falha;
• notebook falha;
• celular no Wi-Fi falha;

mas o celular na rede móvel funciona, investigue:

• roteador;
• DNS da rede;
• operadora;
• caminho;
• configuração WAN;
• MTU;
• filtros.

---

Caso 12: apenas um domínio específico não funciona em toda a rede

Faça:

nslookup dominio.com

em mais de um dispositivo quando possível.

Compare DNS.

Depois teste usando rede móvel.

Se funciona pela rede móvel, mas não pela conexão fixa, pode existir diferença de:

• DNS;
• rota;
• endereço público;
• filtragem;
• infraestrutura do serviço.

Não conclua automaticamente que existe bloqueio intencional.

---

Caso 13: alguns sites funcionam somente depois de várias tentativas

Esse cenário pode apontar para comportamento intermitente.

Registre:

• horário;
• domínio;
• endereço resolvido;
• IPv4/IPv6;
• VPN ativa ou não;
• navegador;
• resultado TCP.

O padrão temporal pode revelar muito.

---

Automatize apenas a coleta, não a conclusão

Você pode salvar resultados em arquivos.

Por exemplo:

ipconfig /all > rede.txt

nslookup dominio.com > dns.txt

tracert dominio.com > rota.txt

Isso cria evidências para comparação.

---

Cuidado com informações pessoais nos relatórios

Antes de publicar esses arquivos na Internet, revise-os.

Eles podem conter:

• nome do computador;
• configuração interna;
• endereços;
• informações sobre a rede.

Compartilhe apenas o necessário.

---

Um fluxo técnico mais completo

Quando determinado site não abre:

Etapa 1 — disponibilidade

Funciona em outro dispositivo?

Etapa 2 — navegador

Funciona em outro navegador no mesmo PC?

Etapa 3 — configuração

ipconfig /all

Etapa 4 — DNS

nslookup dominio.com

Etapa 5 — TCP

Test-NetConnection dominio.com -Port 443

Etapa 6 — famílias IP

Compare IPv4 e IPv6 quando aplicável.

Etapa 7 — caminho

tracert dominio.com

Etapa 8 — intermediários

VPN, proxy, firewall, segurança.

Etapa 9 — MTU

Investigue quando os sintomas e testes anteriores apontarem nessa direção.

---

Não existe um único “comando para consertar a Internet”

Essa talvez seja a principal conclusão até aqui.

ipconfig /flushdns

responde a uma hipótese.

nslookup

responde a outra.

ping

testa outra característica.

tracert

mostra outra dimensão.

Test-NetConnection

responde outra pergunta.

O diagnóstico nasce quando combinamos as respostas.

---

Exemplo completo: DNS

Sintoma:

alguns sites não abrem.

Teste:

nslookup dominio.com

Falha usando DNS atual.

Consulta direta a outro resolvedor funciona repetidamente.

Outros dispositivos com outro DNS funcionam.

Agora temos várias evidências apontando para resolução DNS.

Essa é uma hipótese muito melhor do que simplesmente:

“Troque o DNS porque disseram que melhora Internet.”

---

Exemplo completo: IPv6

Sintoma:

determinados destinos demoram e falham.

DNS retorna IPv4 e IPv6.

Testes e conectividade mostram comportamento consistente:

IPv4 funciona.

IPv6 apresenta problema.

Agora temos evidência para investigar a conectividade IPv6 da rede.

Não apenas desativá-la e esquecer.

---

Exemplo completo: MTU

Sintoma:

páginas começam a carregar e ficam travadas, especialmente depois de uma mudança de VPN ou rede.

DNS funciona.

TCP básico funciona.

Testes de tamanho apontam consistentemente uma limitação menor no caminho.

Agora MTU/PMTUD se torna uma hipótese tecnicamente plausível.

---

O poder do diagnóstico por comparação

A metodologia inteira pode ser resumida em pares:

funciona / não funciona

Wi-Fi / rede móvel

VPN ligada / desligada

IPv4 / IPv6

DNS A / DNS B

Chrome / Edge

pacote pequeno / pacote grande

PC A / PC B

Cada comparação elimina possibilidades.

árvore de diagnóstico, FAQ, conclusão e checklist final

Quando apenas alguns sites deixam de abrir, o maior erro é procurar uma solução única.

Esse problema pode nascer em camadas completamente diferentes.

Pode ser:

• DNS;
• navegador;
• IPv4;
• IPv6;
• proxy;
• VPN;
• firewall;
• certificado;
• rota;
• MTU;
• operadora;
• servidor remoto.

Por isso, a melhor estratégia não é executar dez comandos.

É seguir uma sequência lógica.

---

O que testar primeiro quando alguns sites não abrem

Se você chegou diretamente a esta parte procurando uma resposta rápida, use esta ordem:

1. Teste o site em outro dispositivo

Se não funciona em nenhum dispositivo, investigue o próprio serviço ou a conexão da rede.

2. Teste outro navegador no mesmo computador

Se funciona em outro navegador, concentre-se no navegador problemático.

3. Execute

ipconfig /all

Confirme:

• adaptador correto;
• IPv4;
• gateway;
• DNS;
• IPv6.

4. Teste o DNS

nslookup dominio.com

5. Teste a porta HTTPS

No PowerShell:

Test-NetConnection dominio.com -Port 443

6. Compare IPv4 e IPv6

Quando aplicável:

ping -4 dominio.com

ping -6 dominio.com

Use o resultado com cautela porque ICMP pode ser bloqueado.

7. Verifique VPN e proxy

Compare com eles ligados e desligados.

8. Só depois investigue MTU

Principalmente se:

• a página começa a carregar e trava;
• o problema apareceu depois de VPN;
• existe PPPoE;
• pacotes pequenos funcionam e maiores falham.

---

Árvore completa de diagnóstico

Podemos organizar todo o processo assim:

ALGUNS SITES NÃO ABREM
        |
        v
O site abre em outro dispositivo?
        |
   +----+----+
   |         |
  NÃO       SIM
   |         |
   v         v
Investigue   O problema pode
rede/site    estar no PC
             |
             v
O site abre em outro navegador?
             |
        +----+----+
        |         |
       SIM       NÃO
        |         |
        v         v
 Navegador      ipconfig /all
 perfil/cache        |
 extensões           v
                 DNS resolve?
                    |
               +----+----+
               |         |
              NÃO       SIM
               |         |
               v         v
             DNS      Porta 443 funciona?
                         |
                    +----+----+
                    |         |
                   NÃO       SIM
                    |         |
                    v         v
             rota/firewall   IPv4/IPv6?
             VPN/proxy       navegador
             servidor        TLS/MTU

Essa árvore não substitui análise.

Ela serve para evitar que você pule diretamente para uma hipótese avançada.

---

Tabela rápida: sintoma, hipótese e próximo teste

Sintoma	Hipótese inicial	Próximo teste
Nome do site não resolve	DNS	nslookup
Site abre por IP, mas não pelo nome	DNS	comparar resolvedores
Site abre no Edge, não no Chrome	navegador	modo privado/extensões
Site abre com VPN	rota/DNS/VPN	comparar antes/depois
Site abre no 4G, não no Wi-Fi	rede/operadora/DNS	testar outro dispositivo no Wi-Fi
Página começa e trava	MTU/CDN/TLS	comparar recursos e MTU
IPv4 funciona, IPv6 não	conectividade IPv6	testes separados
Porta 443 falha	rota/firewall/servidor	Test-NetConnection
Só um PC apresenta problema	configuração local	ipconfig /all
Todos os dispositivos falham	rede/operadora/site	comparar outra conexão

---

Como saber se o problema é realmente DNS

DNS é uma hipótese forte quando:

• nslookup falha;
• outro servidor DNS responde;
• outro computador com DNS diferente funciona;
• o domínio não resolve;
• cache local apresenta comportamento suspeito.

Mas não confunda:

“o navegador não abriu”

com:

“o DNS falhou”.

São coisas diferentes.

---

Diagnóstico DNS mais organizado

Comece:

ipconfig /all

Anote o DNS configurado.

Depois:

nslookup dominio.com

Em seguida teste outro resolvedor:

nslookup dominio.com 8.8.8.8

ou:

nslookup dominio.com 1.1.1.1

Compare.

Se necessário:

ipconfig /displaydns

Somente depois, com hipótese coerente:

ipconfig /flushdns

---

O que não fazer com DNS

Evite:

• trocar DNS sem medir;
• executar flushdns repetidamente;
• concluir que 8.8.8.8 sempre será melhor;
• trocar DNS do computador e do roteador ao mesmo tempo;
• usar DNS como solução para qualquer problema de Internet.

DNS resolve nomes.

Não corrige sinal Wi-Fi, perda de pacotes ou problemas físicos.

---

Como saber se IPv6 merece investigação

Suspeite mais de IPv6 quando:

• determinados destinos falham enquanto outros funcionam;
• IPv4 funciona de maneira consistente;
• IPv6 apresenta falha consistente;
• o problema surgiu após alteração de roteador ou provedor;
• a rede possui IPv6 parcialmente configurado.

---

Não use apenas a existência de IPv6 no ipconfig

Ver um endereço IPv6 não prova que toda a conectividade IPv6 está funcionando.

Da mesma forma, um endereço link-local:

fe80::

não representa sozinho acesso IPv6 à Internet.

---

Compare IPv4 e IPv6

Use testes equivalentes sempre que possível.

Exemplo:

ping -4 dominio.com

ping -6 dominio.com

Se um funciona e outro não, isso é uma pista.

Não é sentença final.

---

Teste o caminho

Em cenários avançados, compare rotas.

O tracert pode ajudar a observar diferenças.

Mas lembre-se:

• roteadores podem não responder ICMP;
• um salto pode mostrar timeout e o destino funcionar;
• latência alta em um salto intermediário isolado não prova gargalo.

---

Não interprete tracert como velocímetro da Internet

O tracert mostra o caminho lógico observado pelas respostas recebidas.

Ele não mede diretamente:

• banda;
• capacidade do link;
• qualidade absoluta de cada roteador.

Use-o para comparação.

---

Quando MTU se torna uma hipótese forte

MTU deve subir na lista quando os sintomas incluem:

• página abre parcialmente;
• download inicia e trava;
• upload falha;
• VPN altera o comportamento;
• PPPoE está envolvido;
• aplicações específicas falham;
• pacotes pequenos atravessam e maiores apresentam problemas consistentes.

---

Um detalhe importante: MTU local e MTU do caminho não são exatamente a mesma coisa

Sua interface pode estar configurada com determinado MTU.

Mas o caminho até o destino pode conter um segmento com limite menor.

Por isso existe o conceito de:

Path MTU.

É o menor tamanho suportado ao longo daquele caminho, no contexto daquela comunicação.

---

Teste controlado de MTU no IPv4

Exemplo:

ping -f -l 1472 destino

Se não funcionar por limitação relacionada ao tamanho, reduza.

Por exemplo:

ping -f -l 1464 destino

Depois:

ping -f -l 1452 destino

Refine até identificar um valor funcional consistente.

---

Como interpretar o resultado

No cenário IPv4 clássico:

Payload ICMP
+ 20 bytes IPv4
+ 8 bytes ICMP
= tamanho total

Por isso:

1472 + 28 = 1500

---

Não aplique o resultado automaticamente

Encontrar um tamanho menor não significa que você deve editar imediatamente o MTU da placa.

Primeiro pergunte:

• o teste foi consistente?
• outro destino apresenta o mesmo comportamento?
• existe VPN?
• existe PPPoE?
• o problema começou após mudança de rede?
• o sintoma é compatível?

---

Teste MTU contra mais de um destino

Esse é um ótimo refinamento.

Compare:

• site que funciona;
• site que falha.

Se ambos mostram a mesma limitação, talvez a característica pertença à conexão.

Se apenas o caminho problemático se comporta diferente, o diagnóstico muda.

---

Quando o problema pode estar no roteador

Suspeite mais do roteador quando:

• vários dispositivos apresentam o mesmo problema;
• o comportamento começou após troca de roteador;
• DNS configurado pelo roteador falha;
• VPN ou MTU da WAN alteram os sintomas;
• reiniciar o roteador muda temporariamente o comportamento;
• existe configuração de filtro ou segurança ativa.

---

Quando o problema pode estar na operadora

Suspeite mais da operadora ou do caminho externo quando:

• todos os dispositivos da sua rede apresentam a falha;
• a rede móvel acessa o site normalmente;
• DNS local funciona;
• o serviço está online;
• a falha desaparece por VPN;
• rotas apresentam diferenças consistentes.

Mas não conclua automaticamente:

“A operadora está bloqueando.”

Pode existir:

• falha de rota;
• peering;
• problema de CDN;
• DNS;
• IPv6;
• MTU.

---

Quando o problema pode estar no próprio site

Considere o servidor quando:

• o domínio resolve;
• vários usuários apresentam problema;
• diferentes conexões falham;
• o serviço está indisponível;
• apenas aquele destino apresenta falha.

O computador não consegue corrigir um servidor remoto fora do ar.

---

Caso avançado: site abre pelo endereço IP

Esse teste parece simples, mas precisa ser interpretado com muito cuidado.

Sites modernos utilizam:

• HTTPS;
• certificados;
• virtual hosts;
• CDN;
• múltiplos domínios.

Digitar diretamente o IP pode não produzir o mesmo comportamento de acessar o domínio.

Portanto, não trate:

“abriu pelo IP”

como prova absoluta de que apenas DNS está errado.

Use esse resultado dentro do contexto.

---

Caso avançado: mesmo domínio retorna vários IPs

Isso é normal em muitos serviços.

Pode existir:

• balanceamento;
• CDN;
• infraestrutura distribuída.

Um endereço pode estar acessível e outro não.

Se o problema parecer intermitente, registre os endereços retornados em cada tentativa.

---

Caso avançado: site funciona em alguns horários

Isso pode indicar:

• congestionamento;
• rota;
• CDN;
• DNS;
• servidor;
• comportamento intermitente.

Registre:

• horário;
• DNS retornado;
• IP;
• navegador;
• conexão utilizada;
• resultado de porta 443.

Diagnóstico sem registro vira memória subjetiva.

---

Caso avançado: página HTML abre, mas imagens não carregam

Muito provavelmente existem múltiplos destinos envolvidos.

Inspecione a hipótese de:

• CDN;
• domínio secundário;
• firewall;
• DNS;
• IPv6;
• bloqueio de conteúdo.

O domínio principal estar funcionando não significa que todos os recursos associados estão acessíveis.

---

Caso avançado: apenas downloads grandes falham

Nesse cenário, MTU merece mais atenção.

Também investigue:

• VPN;
• segurança;
• proxy;
• perda de pacotes;
• servidor.

Não atribua automaticamente a MTU.

---

Caso avançado: apenas upload trava

Upload pode revelar problemas que navegação comum não evidencia.

A comunicação pode funcionar para páginas leves, mas apresentar falhas em transferências maiores.

Novamente, investigue:

• MTU;
• VPN;
• perda;
• caminho;
• firewall;
• aplicação.

---

Caso avançado: depois de instalar antivírus

Se o problema começou imediatamente depois de instalar ou atualizar software de segurança, verifique:

• proteção web;
• filtragem;
• inspeção HTTPS;
• firewall;
• logs.

Não desative a proteção inteira sem critério.

Prefira verificar registros e configurações específicas.

---

Caso avançado: depois de atualizar o Windows

Correlação temporal é importante, mas não prova causalidade.

Registre:

• data da atualização;
• quando o problema começou;
• adaptador;
• driver;
• VPN;
• software de segurança.

Depois faça testes comparativos.

---

Caso avançado: só acontece no Wi-Fi

Teste a mesma máquina por Ethernet, se possível.

Se:

Wi-Fi falha

e:

Ethernet funciona

concentre a investigação em:

• adaptador Wi-Fi;
• driver;
• roteador;
• banda;
• estabilidade;
• configuração específica da interface.

---

Caso avançado: Ethernet falha, Wi-Fi funciona

Mesma lógica.

Agora investigue:

• cabo;
• porta;
• adaptador Ethernet;
• driver;
• DHCP daquela interface;
• configuração manual.

---

Não altere a pilha inteira do Windows como primeiro passo

Existem tutoriais que recomendam imediatamente:

• reset de Winsock;
• reset de TCP/IP;
• desativar IPv6;
• alterar MTU;
• trocar DNS;
• reinstalar driver.

Esse tipo de procedimento pode até resolver.

Mas também pode apagar pistas importantes.

Antes:

meça.

---

O que você deve registrar antes de alterar

Salve:

ipconfig /all

Anote:

• DNS;
• IPv4;
• IPv6;
• gateway;
• DHCP;
• VPN ativa;
• navegador;
• site problemático.

Também registre resultados de:

nslookup dominio.com

Test-NetConnection dominio.com -Port 443

e, quando necessário:

tracert dominio.com

---

Checklist final de diagnóstico

Quando alguns sites não abrem no Windows 11:

Configuração

• adaptador correto;
• IPv4 válido;
• gateway existente;
• DNS identificado;
• IPv6 observado.

Comparação

• outro computador;
• outro navegador;
• celular no Wi-Fi;
• celular na rede móvel.

DNS

• nslookup;
• comparar resolvedores;
• observar cache antes de limpar.

Conectividade

• testar porta 443;
• comparar IPv4 e IPv6;
• observar rota.

Software

• VPN;
• proxy;
• firewall;
• antivírus;
• extensões.

MTU

• testar apenas se os sintomas indicarem;
• usar comparação;
• não alterar números aleatoriamente.

---

Erros que devem ser evitados

Não faça tudo de uma vez.

Evite:

• trocar DNS imediatamente;
• desativar IPv6 sem diagnóstico;
• mudar MTU por tutorial;
• executar flushdns repetidamente;
• reiniciar roteador sem registrar o estado;
• desativar antivírus como primeira tentativa;
• ignorar mensagens de certificado;
• interpretar ping como teste definitivo;
• interpretar tracert de forma isolada;
• assumir que VPN funcionando prova bloqueio da operadora.

---

FAQ — Alguns sites abrem e outros não no Windows 11

Por que alguns sites abrem e outros não?

Porque diferentes sites podem utilizar DNS, IPv4, IPv6, CDN, rotas e servidores diferentes. Uma falha parcial pode afetar apenas alguns destinos.

DNS pode causar isso?

Sim.

Principalmente quando determinados domínios não são resolvidos corretamente.

Trocar DNS resolve?

Às vezes.

Mas deve ser feito quando os testes apontarem DNS como causa provável.

Flushdns resolve?

Pode ajudar quando existe problema relacionado ao cache DNS local.

Não corrige MTU, Wi-Fi ou rota.

IPv6 pode impedir alguns sites de abrir?

Uma conectividade IPv6 parcialmente quebrada pode causar comportamento inconsistente em determinados destinos.

Isso não significa que IPv6 deva ser desativado permanentemente.

O que significa MTU?

É o Maximum Transmission Unit, relacionado ao tamanho máximo de unidade transmitida em determinado contexto de rede.

MTU errada pode fazer alguns sites travarem?

Pode contribuir para esse tipo de comportamento em determinados cenários, especialmente quando há VPN, PPPoE ou problemas de Path MTU.

Qual MTU devo usar?

Não existe um número universal.

O valor depende da interface, tecnologia e caminho.

1500 é sempre o melhor valor?

Não.

É comum em Ethernet, mas outros contextos podem utilizar valores diferentes.

1492 é sempre PPPoE?

É um valor frequentemente associado a determinados cenários PPPoE, mas não deve ser assumido sem verificar a conexão real.

O que faz ping -f -l?

No IPv4, esses parâmetros permitem testar tamanho de payload ICMP com a solicitação de não fragmentar.

Por que usar 1472 no teste?

No cenário IPv4 clássico:

1472 + 28 bytes de cabeçalhos = 1500 bytes.

Se ping não responde, o site está fora do ar?

Não.

ICMP pode estar bloqueado ou limitado.

Se nslookup funciona, DNS está perfeito?

Não necessariamente.

Ele mostra que aquela consulta DNS funcionou naquele contexto.

O navegador ainda depende de outras etapas.

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

Não obrigatoriamente.

Ainda podem existir problemas de TLS, navegador, aplicação ou conteúdo.

Por que o site abre com VPN?

Porque a VPN pode mudar DNS, rota, endereço público, caminho e MTU.

O teste não identifica sozinho qual desses fatores resolveu.

Por que funciona no celular?

Depende.

Se o celular estava na rede móvel, ele utiliza outro caminho.

Se estava no mesmo Wi-Fi, a comparação é mais útil para investigar o computador.

Um site pode abrir no Edge e falhar no Chrome?

Sim.

Isso pode apontar para configurações, extensões, perfil ou cache específicos do navegador.

Vale desativar IPv6?

Não como solução genérica.

Faça isso apenas dentro de um teste controlado e com motivo técnico.

Posso mudar MTU do Windows?

É possível, mas não deve ser a primeira tentativa.

Registre o valor atual e confirme a hipótese antes de alterar.

Qual é o melhor primeiro comando?

ipconfig /all

Ele ajuda a entender a configuração de rede antes de qualquer mudança.

---

Conclusão: alguns sites não abrirem não significa que “a Internet está ruim”

Quando apenas alguns sites falham, a conexão pode estar funcionando em várias camadas.

Por isso esse problema exige mais raciocínio do que simplesmente reiniciar o roteador.

O diagnóstico correto deve tentar separar:

• DNS;
• IPv4;
• IPv6;
• navegador;
• VPN;
• proxy;
• firewall;
• TLS;
• rota;
• MTU;
• operadora;
• servidor.

A sequência mais eficiente é:

observar

↓

comparar

↓

testar

↓

formular hipótese

↓

alterar uma coisa

↓

testar novamente

Esse método reduz tentativas aleatórias e preserva evidências.

Quando o problema é DNS, os testes mostram.

Quando é IPv6, as diferenças aparecem.

Quando MTU entra em cena, o comportamento dos pacotes ajuda a revelar.

E quando o problema está fora do computador, os testes também ajudam a evitar uma formatação ou reinstalação completamente desnecessária.

---

Precisa de ajuda para diagnosticar problemas de Internet no Windows?

Se alguns sites abrem e outros não, a VMIA pode ajudar a identificar se a causa está no Windows, DNS, IPv4/IPv6, roteador, Wi-Fi, VPN, MTU ou na própria conexão.

A VMIA – Manutenção e Configuração trabalha com diagnóstico de computadores Windows, redes domésticas, Wi-Fi, roteadores, impressoras e problemas de conectividade.

Atendimento com agendamento e possibilidade de suporte remoto conforme o caso.

VMIA – Manutenção e Configuração

Site: https://vmia.site

Blog: https://vmia.com.br

WhatsApp: https://whats.vmia.com.br

Telefone/WhatsApp: (11) 99779-7772

Antes de alterar DNS, desativar IPv6, mexer em MTU ou formatar o computador, descubra qual camada está realmente causando a falha.