Você olha para o canto inferior direito do Windows e percebe alguma coisa estranha.
O computador está conectado ao Wi-Fi ou ao cabo de rede, mas o Windows informa:
“Sem Internet”
ou apresenta um ícone indicando ausência de acesso à Internet.
O primeiro pensamento é óbvio: a conexão caiu.
Então você abre o navegador.
Google funciona.
YouTube funciona.
WhatsApp funciona.
Você abre o Prompt de Comando e consegue executar um ping para um endereço externo.
A Internet claramente está funcionando.
Então surge a pergunta:
como o Windows pode afirmar que não existe Internet enquanto o computador está acessando a Internet normalmente?
A resposta está em um componente pouco conhecido chamado NCSI — Network Connectivity Status Indicator.
O Windows não testa a Internet tentando navegar aleatoriamente em algum site conhecido. O sistema possui mecanismos próprios para determinar o estado da conectividade.
Quando essa verificação falha, podemos encontrar uma situação aparentemente contraditória:
a Internet funciona, mas o Windows acredita que não funciona.
Isso pode parecer apenas um problema visual no ícone da barra de tarefas.
Nem sempre é.
Alguns programas e componentes do próprio Windows podem consultar o estado de conectividade calculado pelo sistema. Por isso, uma detecção incorreta pode produzir sintomas que vão além do pequeno ícone próximo ao relógio.
Para entender o problema, precisamos primeiro descobrir como o Windows responde a uma pergunta aparentemente simples:
“Este computador realmente possui acesso à Internet?”
O Windows não confia apenas no fato de existir uma rede conectada
Conectar-se a uma rede e possuir acesso à Internet são coisas diferentes.
Imagine que seu notebook esteja conectado corretamente ao Wi-Fi.
Ele recebeu:
- endereço IP;
- máscara de rede;
- gateway;
- servidor DNS.
Isso significa que existe uma conexão com a rede local.
Mas não prova que a Internet esteja disponível.
O roteador pode estar funcionando normalmente enquanto a conexão da operadora caiu.
Também podemos encontrar situações nas quais o computador conversa com outros dispositivos da rede local, mas não consegue chegar à Internet.
Por isso, o Windows precisa distinguir diferentes estados.
De forma simplificada:
adaptador desconectado
é diferente de:
rede local disponível
que também é diferente de:
Internet disponível.
Essa distinção parece pequena, mas possui enorme importância para o sistema operacional.
O que é NCSI?
NCSI significa:
Network Connectivity Status Indicator
Podemos traduzir como Indicador de Status de Conectividade de Rede.
Ele faz parte dos mecanismos utilizados pelo Windows para determinar o nível de conectividade disponível.
Quando tudo funciona corretamente, quase ninguém percebe sua existência.
Você conecta o cabo.
Ou entra no Wi-Fi.
Alguns instantes depois, o Windows reconhece a conexão e apresenta o estado correspondente.
Nos bastidores, porém, existe muito mais acontecendo.
O sistema precisa descobrir:
Existe uma interface ativa?
Existe conectividade local?
Existe uma rota utilizável?
Existe acesso à Internet?
O NCSI ajuda justamente nessa avaliação.
Windows 10 e Windows 11 possuem uma diferença importante
Existe um detalhe técnico interessante.
No Windows 10, parte desse processo historicamente esteve associada ao serviço Network Location Awareness, conhecido como NLA.
No Windows 11, a Microsoft informa que o trabalho relacionado ao NCSI passou para o Network List Service, identificado como netprofm.
Para o usuário comum isso não muda a aparência do problema.
Mas para quem realiza diagnóstico técnico, conhecer essa diferença evita seguir tutoriais antigos como se todas as versões do Windows funcionassem exatamente da mesma maneira.
Esse é um problema frequente quando pesquisamos soluções para rede.
Um procedimento escrito para Windows 7 ou para uma versão antiga do Windows 10 continua circulando anos depois.
O comando pode até existir.
A chave de Registro pode continuar presente.
Mas o comportamento interno do sistema pode ter mudado.
Por isso precisamos diagnosticar o Windows atual, e não simplesmente repetir soluções antigas.
Como o NCSI descobre se existe Internet?
O NCSI trabalha principalmente com dois tipos de verificação:
Active Probing
e
Passive Probing.
Em português, podemos pensar nelas como:
sondagem ativa
e
sondagem passiva.
As duas ajudam o Windows a construir uma visão sobre a conectividade.
O que é Active Probing?
A sondagem ativa faz exatamente o que o nome sugere.
O Windows realiza uma ação de rede especificamente para verificar a conectividade.
Em determinados cenários, isso pode envolver uma consulta DNS ou uma solicitação HTTP para um endpoint conhecido utilizado pelo mecanismo do NCSI.
O Windows não está tentando descobrir se “qualquer coisa” respondeu.
Ele conhece o tipo de resposta que espera.
Quando a verificação acontece corretamente e o conteúdo esperado retorna, o sistema ganha uma forte indicação de que aquela interface possui acesso à Internet.
Podemos representar o processo de maneira simplificada:
Windows
↓
NCSI inicia a verificação
↓
DNS/HTTP
↓
servidor de verificação
↓
resposta esperada
↓
conectividade com a Internet confirmada
O problema aparece quando algum elemento no meio dessa sequência interfere na verificação.
A Internet pode funcionar enquanto a sondagem falha
Esse é o ponto mais importante do artigo.
Imagine que seu navegador consiga abrir:
google.com
e vários outros serviços.
Mas algum componente da rede bloqueia especificamente a comunicação necessária para a sondagem do NCSI.
O Windows tenta verificar a Internet.
A tentativa falha.
O sistema não recebe aquilo que esperava.
Consequentemente, o NCSI pode concluir que não conseguiu confirmar acesso à Internet.
Isso não significa necessariamente que:
toda a Internet está inacessível.
Significa que:
o mecanismo utilizado para confirmar a conectividade não conseguiu concluir sua verificação corretamente.
Essa diferença explica o estranho cenário:
Windows: “Sem Internet”
enquanto:
Chrome: navegando normalmente.
O que é Passive Probing?
O Windows não depende apenas de verificações ativas.
O NCSI também pode utilizar informações obtidas passivamente do tráfego de rede.
Em vez de iniciar necessariamente uma conexão específica, a sondagem passiva observa informações relacionadas ao tráfego que já está passando pelo computador.
Ela pode considerar dados e estatísticas de rede para ajudar a determinar se existe conectividade além da rede local.
Isso complementa as sondagens ativas.
E existe um motivo importante para manter os dois mecanismos.
Redes são ambientes dinâmicos.
Uma sondagem ativa pode falhar temporariamente.
Uma rota pode oscilar.
Um proxy pode interferir.
Uma VPN pode estar estabelecendo conexão.
O DNS pode demorar para responder.
As verificações ativa e passiva ajudam o sistema a formar uma avaliação mais confiável.
Por que simplesmente desativar a sondagem ativa não é uma boa solução?
Quando alguém encontra o problema “Sem Internet, mas funciona”, é comum pesquisar no Google e encontrar alguma modificação no Registro do Windows.
Entre elas aparecem procedimentos para alterar configurações relacionadas ao:
EnableActiveProbing
A lógica parece simples:
“Se a sondagem está mostrando Sem Internet, desative a sondagem.”
Mas isso não corrige necessariamente a causa.
É parecido com um carro que acende uma luz de advertência no painel.
Remover a lâmpada não corrige o defeito que provocou o alerta.
A própria Microsoft recomenda não desativar a sondagem ativa como solução para problemas do NCSI.
O correto é descobrir por que a verificação não consegue ser concluída.
O problema pode ser apenas o ícone?
Pode.
Mas precisamos confirmar.
Se:
- sites abrem;
- DNS funciona;
- aplicações acessam a Internet;
- Windows Update funciona;
- outros serviços funcionam normalmente;
e somente o indicador permanece incorreto, podemos estar diante de um problema essencialmente relacionado à detecção de conectividade.
Entretanto, existem casos nos quais aplicativos também se comportam de maneira estranha.
Isso acontece porque programas podem consultar APIs do Windows para descobrir se existe acesso à Internet.
Em vez de testar a conexão por conta própria, eles perguntam ao sistema operacional.
Se o Windows responde que não detectou Internet, o programa pode modificar seu comportamento.
É por isso que o problema merece diagnóstico mesmo quando o navegador aparentemente funciona.
Quais programas podem perceber o estado do NCSI?
Componentes e aplicações podem utilizar o estado de conectividade fornecido pelo Windows.
A documentação da Microsoft cita exemplos como:
- Microsoft Outlook;
- Microsoft Teams;
- Skype;
- Windows Update;
- DirectAccess;
- alguns softwares de terceiros.
Isso cria situações curiosas.
O navegador abre páginas normalmente.
Mas determinado programa informa:
“Você está offline.”
Nesse momento, muita gente conclui que o programa está com defeito.
Talvez esteja.
Mas também pode existir uma inconsistência na maneira como o Windows detectou a conectividade.
Primeiro diagnóstico: Get-NetConnectionProfile
Antes de modificar Registro, DNS, firewall ou adaptador, podemos fazer uma verificação extremamente simples.
Abra o PowerShell.
Execute:
Get-NetConnectionProfile
O Windows apresentará informações sobre os perfis de rede.
Dependendo da versão do sistema, podemos encontrar campos como:
Name
InterfaceAlias
InterfaceIndex
NetworkCategory
IPv4Connectivity
IPv6Connectivity
Em um cenário no qual o Windows reconhece acesso completo à Internet, podemos encontrar:
IPv4Connectivity : Internet
e, quando existe conectividade IPv6:
IPv6Connectivity : Internet
Esse comando fornece uma excelente primeira visão.
O que significa NetworkCategory?
No resultado também podemos encontrar algo como:
NetworkCategory : Private
ou:
NetworkCategory : Public
Isso representa outra classificação.
Não confunda:
categoria da rede
com:
estado de conectividade com a Internet.
Uma rede pode ser:
Private
e estar sem Internet.
Também pode ser:
Public
e possuir Internet normalmente.
A categoria influencia principalmente comportamentos relacionados à descoberta de rede, compartilhamento e regras de firewall.
Já os campos de conectividade indicam como o Windows está classificando o acesso daquela interface.
IPv4Connectivity e IPv6Connectivity podem apresentar resultados diferentes
Esse detalhe é extremamente útil.
Um computador moderno pode utilizar simultaneamente:
IPv4
e:
IPv6.
Portanto, podemos encontrar situações nas quais:
IPv4Connectivity : Internet
mas:
IPv6Connectivity : LocalNetwork
ou outro estado.
Isso mostra que não devemos tratar “Internet” como uma única conexão abstrata.
O Windows pode estar avaliando separadamente a conectividade das duas famílias de protocolos.
Esse detalhe ajuda bastante quando o problema ocorre somente em determinados serviços.
Não desative IPv6 apenas porque o resultado parece estranho
Esse é outro procedimento comum em tutoriais.
A pessoa encontra:
IPv4 funcionando;
IPv6 apresentando comportamento diferente.
Então desativa IPv6.
O ícone muda.
Problema “resolvido”.
Mas talvez nada tenha sido realmente corrigido.
Podemos simplesmente ter removido o caminho que estava apresentando o problema.
Se existe conectividade IPv6 configurada de maneira incorreta no roteador ou na operadora, o melhor diagnóstico consiste em descobrir o motivo.
Desativar IPv6 indiscriminadamente não deveria ser a primeira solução.
DNS pode fazer o Windows acreditar que não existe Internet?
Sim.
O NCSI pode depender de resolução DNS durante suas verificações.
Se o computador não consegue resolver corretamente os nomes necessários para a sondagem, a detecção pode falhar.
Mas existe um detalhe importante:
isso não significa necessariamente que todo DNS esteja quebrado.
Imagine um servidor DNS com filtro.
Ele resolve normalmente:
Google;
YouTube;
Facebook;
VMIA;
Microsoft.
Mas bloqueia ou redireciona um domínio utilizado especificamente para teste de conectividade.
Para o usuário:
Internet funcionando.
Para o NCSI:
verificação falhando.
Essa diferença é exatamente o tipo de situação que precisamos procurar.
DNS com bloqueio de anúncios pode interferir?
Pode, dependendo das regras utilizadas.
Servidores DNS filtrados, bloqueadores de anúncios, soluções de segurança, filtros parentais e sistemas corporativos podem bloquear determinados domínios.
O mesmo pode acontecer com:
- Pi-hole;
- AdGuard DNS;
- filtros do roteador;
- DNS corporativo;
- firewall;
- soluções de segurança.
Isso não significa que essas ferramentas sejam ruins.
Significa apenas que qualquer sistema que modifica respostas DNS pode interferir em mecanismos que dependem de domínios específicos.
O diagnóstico precisa verificar se isso realmente está acontecendo.
Como testar a resolução DNS usada pelo NCSI?
Uma das verificações documentadas pela Microsoft utiliza:
nslookup dns.msftncsi.com
Também podemos utilizar PowerShell:
Resolve-DnsName dns.msftncsi.com
O objetivo não consiste em alterar nada.
Estamos fazendo uma pergunta:
o computador consegue resolver o nome utilizado na verificação?
Se a resposta falha, precisamos descobrir por quê.
Teste o DNS configurado.
Compare outro computador.
Compare outra rede.
Veja se existe filtro.
Observe se a VPN modifica o DNS.
Essa sequência produz muito mais informação do que simplesmente trocar imediatamente para outro servidor DNS.
Trocar para Google DNS ou Cloudflare resolve?
Talvez.
Mas “talvez” não representa diagnóstico.
Se o problema realmente for provocado pelo servidor DNS atual, trocar temporariamente o DNS durante um teste pode ajudar a confirmar a hipótese.
Por exemplo:
DNS atual → NCSI falha.
DNS alternativo → NCSI funciona.
DNS original → NCSI volta a falhar.
Agora existe uma correlação interessante.
Mas se trocamos DNS, reiniciamos roteador, limpamos cache, resetamos Winsock e reinstalamos driver ao mesmo tempo, perdemos a capacidade de descobrir qual alteração realmente fez diferença.
Proxy pode provocar “Sem Internet” mesmo com navegador funcionando?
Sim.
Esse é um cenário particularmente interessante.
Navegadores e componentes do Windows nem sempre utilizam exatamente o mesmo caminho ou as mesmas configurações para todas as solicitações.
Uma configuração de proxy incorreta pode impedir que a sondagem alcance corretamente o destino esperado.
Também podem existir arquivos PAC usados para configuração automática de proxy.
Se o PAC encaminha determinadas solicitações incorretamente, a sondagem pode falhar.
O usuário abre um site.
O navegador funciona.
Mas a verificação do Windows não consegue completar seu caminho.
Por isso, proxy precisa entrar no diagnóstico.
Como verificar o proxy do Windows?
Nas configurações do Windows, acesse:
Configurações → Rede e Internet → Proxy
Observe:
- detectar configurações automaticamente;
- usar script de configuração;
- usar servidor proxy.
Não altere nada ainda.
Primeiro registre o que existe.
Em ambientes empresariais, essas configurações podem ter sido definidas propositalmente.
VPN também pode confundir a detecção
Uma VPN modifica a maneira como o tráfego sai do computador.
Dependendo da solução, ela pode alterar:
- rotas;
- DNS;
- interface padrão;
- métricas;
- filtros;
- proxy;
- regras de firewall.
Durante a conexão da VPN, o NCSI pode realizar uma sondagem em um momento no qual as rotas ainda estão sendo alteradas.
Também pode acontecer de a VPN redirecionar a sondagem para um caminho que não consegue alcançar corretamente o endpoint.
A própria documentação da Microsoft lista configuração de VPN e redirecionamento incorreto entre possíveis causas de falha da sondagem.
Por isso, uma pergunta simples ajuda muito:
o problema aparece somente quando a VPN está conectada?
Se sim, já temos uma pista valiosa.
Firewall pode bloquear apenas o NCSI?
Sim.
Um firewall pode permitir navegação normal e bloquear determinada comunicação.
O mesmo vale para soluções de segurança instaladas no computador ou presentes na própria rede.
Isso acontece porque firewalls não trabalham apenas com uma regra:
Internet permitida / Internet bloqueada.
Eles podem aplicar políticas específicas por:
- domínio;
- IP;
- protocolo;
- aplicativo;
- porta;
- usuário;
- categoria.
Assim, uma sondagem específica pode falhar enquanto dezenas de outros serviços continuam funcionando.
Portal cativo: o caso do Wi-Fi de hotel, aeroporto e shopping
Existe outro cenário muito interessante.
Você conecta o notebook a uma rede Wi-Fi pública.
Tecnicamente, a conexão com o ponto de acesso foi realizada.
Você recebeu IP.
Existe gateway.
Talvez até consiga resolver DNS.
Mas antes de acessar a Internet, precisa abrir uma página e:
- aceitar termos;
- fazer login;
- informar algum dado;
- confirmar o acesso.
Isso recebe o nome de portal cativo.
O Windows precisa distinguir esse cenário de uma conexão normal com Internet.
As verificações de conectividade ajudam o sistema a perceber que existe algo entre o computador e a Internet.
É também por isso que, em determinadas redes públicas, o Windows pode abrir ou sugerir uma página de autenticação.
Por que o navegador pode ser redirecionado?
Imagine que o Windows espera acessar um endpoint conhecido.
Mas a rede intercepta a solicitação e devolve:
página de login do hotel.
Essa não é a resposta que o NCSI esperava.
Logo, ele sabe que ainda não possui conectividade normal com a Internet.
Depois que você autentica no portal, a sondagem pode ser executada novamente e finalmente receber a resposta correta.
O ícone então muda.
Esse comportamento mostra por que simplesmente desativar a verificação ativa poderia prejudicar funcionalidades úteis do Windows.
O endereço msftconnecttest é vírus?
Não.
O nome pode parecer estranho quando aparece em logs de DNS, firewall ou roteador, especialmente para quem nunca ouviu falar do NCSI.
Mas msftconnecttest está relacionado ao mecanismo de verificação de conectividade da Microsoft.
Isso explica por que administradores podem encontrar acessos relacionados a esse domínio mesmo sem abrir conscientemente uma página com esse endereço.
O próprio Windows pode estar realizando a verificação.
Por que bloquear msftconnecttest pode causar comportamento estranho?
Porque você pode estar bloqueando justamente parte do mecanismo que o Windows utiliza para determinar se existe Internet.
O restante da navegação continua funcionando.
O usuário pensa:
“Internet normal.”
Mas o Windows tenta realizar sua verificação e não recebe a resposta esperada.
Resultado:
“Sem Internet.”
Por isso, quando um DNS filtrado ou firewall possui regras personalizadas, vale verificar se endpoints relacionados ao NCSI foram bloqueados.
Não crie uma exceção antes de confirmar o bloqueio
Aqui vale a mesma regra utilizada em outros diagnósticos de rede.
Não saia criando exceções.
Primeiro prove o problema.
Verifique:
- resolução DNS;
- logs;
- comportamento com VPN;
- proxy;
- firewall;
- outro computador;
- outra rede.
Somente depois faça a alteração necessária.
Isso evita transformar a rede em uma coleção de exceções criadas para problemas que nunca foram realmente identificados.
O Visualizador de Eventos pode mostrar o que aconteceu
Quando o diagnóstico básico não revela a causa, podemos aprofundar.
Abra:
Visualizador de Eventos
e navegue até os logs relacionados ao:
Microsoft → Windows → NCSI
O Windows possui registros que podem ajudar a identificar quando as sondagens foram executadas e se elas terminaram corretamente.
Essa informação se torna especialmente útil quando o problema acontece de forma intermitente.
Imagine:
08:00 — Windows normal.
08:10 — aparece “Sem Internet”.
08:12 — volta sozinho.
Sem logs, podemos apenas tentar reproduzir o problema.
Com os eventos, conseguimos procurar o que aconteceu naquele intervalo.
Logs não são apenas códigos de erro
O objetivo não consiste em copiar qualquer Event ID para o Google.
Precisamos correlacionar o horário do evento com:
- mudança de rede;
- conexão da VPN;
- alteração de Wi-Fi;
- renovação de endereço;
- mudança de DNS;
- início do problema.
Essa correlação transforma logs em evidência.
Sem contexto, um evento isolado pode não dizer quase nada.
Uma mudança de rede pode provocar uma nova sondagem
O NCSI reage a eventos relacionados ao estado da rede.
Por isso, desconectar e reconectar uma interface pode provocar uma nova avaliação de conectividade.
Em um diagnóstico controlado, isso pode ajudar.
Por exemplo:
- abra os logs;
- desconecte o cabo;
- aguarde;
- reconecte;
- observe os eventos;
- compare com o estado apresentado pelo Windows.
No Wi-Fi, podemos realizar procedimento semelhante desconectando e reconectando à rede.
O objetivo é reproduzir o comportamento e observar o que acontece.
A grande diferença entre “Internet caiu” e “Windows não detectou Internet”
Depois de entender o NCSI, conseguimos separar dois cenários completamente diferentes.
Cenário A — Internet realmente caiu
O navegador não abre.
Ping externo falha.
DNS falha.
Outros dispositivos podem apresentar problema.
Gateway ou WAN pode estar indisponível.
Aqui temos um problema real de conectividade.
Cenário B — Internet funciona, mas o Windows informa “Sem Internet”
Navegador funciona.
Serviços externos respondem.
Outros testes apresentam conectividade.
Mas o NCSI não confirma acesso à Internet.
Aqui devemos investigar o mecanismo de detecção.
Essa separação economiza muito tempo.
Sem ela, podemos reiniciar roteador, trocar cabo, reinstalar placa de rede e até culpar a operadora por um problema que está relacionado apenas à maneira como o Windows verifica a conexão.
O diagnóstico correto começa fazendo a pergunta certa
“Minha Internet está sem Internet.”
Essa frase parece contraditória, mas descreve exatamente o problema.
Precisamos então substituir a pergunta:
“Por que minha Internet caiu?”
por:
“A Internet realmente caiu ou o Windows apenas não conseguiu confirmar a conectividade?”
Essa pequena mudança reorganiza completamente o diagnóstico.
Se a Internet realmente caiu, investigamos:
roteador;
Wi-Fi;
cabo;
DHCP;
DNS;
gateway;
operadora.
Se a Internet funciona, mas o Windows não reconhece, investigamos:
NCSI;
sondagem ativa;
sondagem passiva;
DNS específico;
proxy;
VPN;
firewall;
filtros;
logs.
É assim que deixamos de trocar configurações aleatoriamente e começamos a encontrar a verdadeira origem do problema.
Como diagnosticar quando o Windows mostra “Sem Internet”, mas a conexão funciona
Na primeira parte chegamos a uma conclusão importante:
o estado mostrado pelo Windows e a conectividade real não são exatamente a mesma coisa.
O NCSI precisa reunir evidências para classificar uma interface como conectada à Internet.
Portanto, quando o navegador funciona, mas o Windows informa “Sem Internet”, nosso objetivo não deve ser reiniciar tudo ou modificar o Registro imediatamente.
Precisamos descobrir em qual etapa a detecção está falhando.
Vamos montar esse diagnóstico em camadas.
Etapa 1 — Confirme que a Internet realmente funciona
Parece óbvio, mas esse teste precisa vir primeiro.
Abra dois ou três sites diferentes.
Não teste apenas uma página que já estava aberta.
Depois abra o Prompt de Comando e teste um endereço IP externo conhecido.
Por exemplo:
ping 1.1.1.1
Se houver resposta, já sabemos que existe algum nível de conectividade IP externa.
Mas isso ainda não confirma DNS.
Agora teste:
ping www.microsoft.com
Se o nome for resolvido e houver comunicação, temos mais uma evidência.
Entretanto, existe uma observação importante:
um servidor pode não responder a ping e ainda estar perfeitamente acessível por outros protocolos.
Por isso, ICMP é uma ferramenta de diagnóstico, não uma prova absoluta de funcionamento ou falha.
Etapa 2 — Descubra o que o próprio Windows pensa da conexão
Abra o PowerShell e execute:
Get-NetConnectionProfile
Observe principalmente:
InterfaceAlias
InterfaceIndex
NetworkCategory
IPv4Connectivity
IPv6Connectivity
Um exemplo pode mostrar:
IPv4Connectivity : Internet
IPv6Connectivity : Internet
Isso significa que o Windows classificou ambas as famílias de protocolo como possuindo conectividade com a Internet naquela interface.
Agora imagine:
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork
Temos uma situação diferente.
IPv4 está sendo reconhecido com acesso à Internet, enquanto IPv6 não recebeu a mesma classificação.
Não significa automaticamente que IPv6 esteja “quebrado”.
Mas já sabemos onde aprofundar a investigação.
Etapa 3 — Identifique exatamente qual interface está sendo utilizada
Um notebook pode possuir várias interfaces simultaneamente:
- Ethernet;
- Wi-Fi;
- VPN;
- adaptador virtual;
- Hyper-V;
- software de virtualização;
- interfaces criadas por aplicativos.
Execute:
Get-NetAdapter
Observe:
- Name;
- InterfaceDescription;
- Status;
- LinkSpeed.
Isso ajuda a responder:
qual interface realmente está ativa?
Em computadores com várias interfaces, essa pergunta pode ser mais importante do que parece.
Imagine um notebook conectado simultaneamente ao Wi-Fi e Ethernet.
Agora adicione uma VPN.
O sistema possui vários caminhos possíveis.
O simples fato de o cabo estar conectado não significa que todo tráfego esteja obrigatoriamente utilizando aquele caminho.
Etapa 4 — Verifique a configuração IP
Execute:
ipconfig /all
Não procure apenas pelo endereço IPv4.
Observe:
- IPv4;
- IPv6;
- gateway padrão;
- servidores DNS;
- DHCP;
- sufixos DNS;
- adaptador correto.
Um computador pode navegar normalmente enquanto apresenta uma configuração inesperada em uma das interfaces.
Por exemplo, um adaptador virtual pode possuir DNS diferente.
Uma VPN pode instalar servidores DNS próprios.
Um software corporativo pode modificar a resolução de nomes.
Essas informações precisam ser registradas antes de qualquer alteração.
Etapa 5 — Teste especificamente o DNS relacionado ao NCSI
Agora saímos do teste genérico.
Execute:
nslookup dns.msftncsi.com
Também podemos usar:
Resolve-DnsName dns.msftncsi.com
O importante é observar se existe resolução.
Se houver falha, não troque o DNS imediatamente.
Primeiro pergunte:
qual servidor DNS respondeu?
O nslookup normalmente mostra o servidor utilizado.
Isso permite descobrir se a consulta está indo para:
- roteador;
- DNS da operadora;
- DNS corporativo;
- VPN;
- servidor local;
- filtro DNS.
Essa informação pode explicar muita coisa.
Etapa 6 — Compare com outro domínio
Execute também:
nslookup www.microsoft.com
e outro domínio conhecido.
Agora podemos encontrar uma situação interessante.
www.microsoft.com resolve normalmente.
dns.msftncsi.com falha.
Isso indica que não estamos diante de uma falha DNS completa.
Existe algo específico afetando aquele nome ou aquela consulta.
Esse padrão aponta para:
- filtro DNS;
- bloqueio;
- regra personalizada;
- política corporativa;
- software de segurança.
É uma pista muito melhor do que simplesmente dizer:
“DNS está ruim.”
Etapa 7 — Compare outro servidor DNS sem alterar a máquina inteira
O nslookup permite consultar diretamente um servidor específico.
Por exemplo:
nslookup dns.msftncsi.com 1.1.1.1
Podemos comparar com:
nslookup dns.msftncsi.com 8.8.8.8
O objetivo aqui não consiste em recomendar um DNS específico.
Estamos apenas comparando respostas.
Imagine:
DNS configurado no computador → falha.
1.1.1.1 → responde.
8.8.8.8 → responde.
Agora existe uma forte indicação de que o servidor DNS utilizado normalmente merece investigação.
Mas existe outro cenário.
Todos respondem corretamente.
Nesse caso, a causa provavelmente está em outro ponto.
Etapa 8 — Limpar o cache DNS resolve?
Talvez.
O comando conhecido é:
ipconfig /flushdns
Ele limpa o cache do resolvedor DNS do Windows.
Isso pode ajudar quando existe uma entrada armazenada incorretamente ou desatualizada.
Mas precisamos entender sua limitação.
Se o servidor DNS continua fornecendo uma resposta problemática, limpar o cache apenas fará o Windows perguntar novamente ao mesmo servidor.
Portanto:
flushdns não corrige servidor DNS ruim.
Ele apenas remove informações armazenadas localmente.
Esse comando é útil quando existe uma hipótese relacionada ao cache.
Não é um ritual obrigatório para todo problema de Internet.
Etapa 9 — Verifique o proxy
Acesse:
Configurações → Rede e Internet → Proxy
Observe as opções existentes.
Também podemos verificar algumas configurações pelo Prompt de Comando:
netsh winhttp show proxy
Esse comando mostra a configuração de proxy do WinHTTP.
Podemos encontrar algo como:
Direct access (no proxy server)
ou uma configuração específica.
Esse detalhe importa porque componentes do Windows podem utilizar mecanismos diferentes daqueles percebidos diretamente pelo usuário no navegador.
Um navegador pode funcionar enquanto outra solicitação segue uma configuração problemática.
Proxy do navegador e WinHTTP são sempre iguais?
Não necessariamente.
Esse é um dos motivos pelos quais o problema pode parecer tão estranho.
Dependendo da aplicação e do componente, diferentes APIs e configurações podem participar da comunicação.
Por isso, não basta dizer:
“Chrome funciona, então proxy não pode ser.”
Precisamos verificar o caminho utilizado pelo componente que está apresentando o problema.
Etapa 10 — Procure scripts de configuração automática
Na tela de Proxy do Windows, observe se existe:
Usar script de configuração
Em ambientes empresariais, podemos encontrar um endereço PAC.
PAC significa:
Proxy Auto-Configuration
Esse arquivo contém regras que determinam como determinadas conexões devem ser encaminhadas.
Um erro na regra pode fazer:
site A → acesso direto;
site B → proxy;
endpoint do NCSI → caminho incorreto.
Assim, o navegador continua aparentemente normal enquanto a verificação do Windows falha.
Em uma empresa, não altere esse script sem autorização.
O objetivo inicial consiste apenas em identificar sua existência.
Etapa 11 — Verifique se existe VPN
Olhe para a bandeja do sistema e para:
Configurações → Rede e Internet → VPN
Também observe softwares instalados.
VPNs podem criar adaptadores virtuais e modificar:
- rotas;
- DNS;
- métricas;
- filtros;
- firewall.
Faça uma pergunta fundamental:
o problema começou depois da instalação ou conexão da VPN?
Depois:
o problema desaparece quando a VPN é desconectada de forma segura?
Se sim, temos uma correlação importante.
Isso não significa que a VPN esteja “com defeito”.
Pode existir uma política intencional impedindo determinados acessos.
Em ambiente corporativo, converse com o administrador antes de modificar configurações.
Etapa 12 — Compare a tabela de rotas
Para uma investigação mais avançada, execute:
route print
Esse comando mostra a tabela de roteamento.
Também podemos usar PowerShell:
Get-NetRoute
Aqui entramos em um assunto mais técnico.
O Windows precisa escolher por qual interface enviar cada pacote.
Se existem:
Ethernet;
Wi-Fi;
VPN;
adaptadores virtuais;
podem existir múltiplas rotas.
Uma configuração incorreta pode fazer a sondagem seguir um caminho diferente daquele esperado.
Esse tipo de problema aparece especialmente em máquinas com VPN, virtualização ou várias interfaces simultaneamente.
Métrica de interface importa
O Windows utiliza métricas para ajudar a escolher entre rotas possíveis.
Podemos consultar informações com:
Get-NetIPInterface
Observe campos como:
InterfaceAlias
AddressFamily
InterfaceMetric
ConnectionState
Não altere a métrica apenas porque uma interface possui número diferente.
Primeiro precisamos entender a tabela.
Uma métrica menor pode tornar determinado caminho preferencial quando as rotas são comparáveis.
Mas a escolha depende da rota inteira, incluindo prefixos.
É por isso que modificar métricas aleatoriamente pode criar problemas novos.
Etapa 13 — Compare IPv4 e IPv6
Execute:
Get-NetConnectionProfile
novamente e observe separadamente:
IPv4Connectivity
e
IPv6Connectivity
Depois podemos testar resolução:
Resolve-DnsName www.microsoft.com -Type A
e:
Resolve-DnsName www.microsoft.com -Type AAAA
O registro A está relacionado ao IPv4.
O AAAA está relacionado ao IPv6.
A existência de um registro AAAA não prova que sua conexão IPv6 esteja funcionando corretamente.
Ela apenas mostra que o DNS retornou um endereço IPv6 para aquele nome.
Precisamos separar:
resolução DNS
de:
conectividade real.
Um problema IPv6 pode coexistir com IPv4 funcionando
Imagine:
IPv4 → normal.
IPv6 → parcialmente configurado.
O roteador anuncia IPv6.
O computador recebe endereço.
Mas a conectividade externa apresenta problemas.
Algumas aplicações podem tentar IPv6 e depois recorrer ao IPv4.
Outras podem reagir de maneira diferente.
O NCSI também avalia conectividade das famílias de protocolo.
Por isso, um cenário misto merece investigação.
Mas novamente:
não desative IPv6 como primeiro teste permanente.
Descubra por que ele está falhando.
Etapa 14 — Firewall do Windows
O Firewall do Windows pode ser consultado por:
Segurança do Windows → Firewall e proteção de rede
Observe qual perfil está ativo.
Também podemos utilizar PowerShell:
Get-NetFirewallProfile
Isso mostra os perfis:
- Domain;
- Private;
- Public.
Não desligue o firewall para “ver se resolve” como primeira abordagem.
Esse procedimento reduz segurança e fornece pouca informação quando realizado sem controle.
Prefira verificar:
- regras;
- logs;
- software que criou filtros;
- comportamento em outra rede.
Etapa 15 — Firewall ou antivírus de terceiros
Algumas suítes de segurança adicionam:
- firewall;
- inspeção HTTPS;
- filtro web;
- proteção DNS;
- controle parental;
- VPN.
Tudo isso pode participar da comunicação.
O diagnóstico precisa perguntar:
existe algum software entre o aplicativo e a rede?
Esse conceito é mais importante do que simplesmente olhar se “o antivírus está ligado”.
Algumas ferramentas continuam com drivers e filtros carregados mesmo quando uma parte da interface foi temporariamente desativada.
Por isso, qualquer teste envolvendo software de segurança precisa seguir as orientações do fabricante e preservar a proteção do computador.
Etapa 16 — Teste em outra rede
Esse é um dos testes mais poderosos.
Pegue o mesmo notebook e conecte-o temporariamente a outra rede confiável.
Por exemplo:
Rede A:
Windows mostra “Sem Internet”.
Rede B:
Windows reconhece Internet imediatamente.
O que isso nos diz?
Que o problema provavelmente depende de algo presente na Rede A.
Pode ser:
- DNS;
- firewall;
- roteador;
- filtro;
- proxy;
- política;
- portal cativo.
Agora imagine o contrário:
o notebook apresenta o problema em todas as redes.
Mas outro notebook funciona normalmente nas mesmas redes.
Nesse caso, o próprio computador se torna um suspeito muito mais forte.
Etapa 17 — Compare outro computador na mesma rede
Temos quatro combinações extremamente úteis.
Um computador falha em uma rede
Suspeite do computador.
Todos os computadores falham na mesma rede
Suspeite da infraestrutura.
O mesmo computador falha em todas as redes
Suspeite fortemente do sistema, software ou configuração local.
O problema acompanha uma VPN específica
Suspeite do caminho criado pela VPN ou das políticas associadas.
Essas comparações economizam horas de tentativa e erro.
Etapa 18 — Visualizador de Eventos
Agora chegamos a uma ferramenta poderosa.
Abra:
eventvwr.msc
ou pesquise:
Visualizador de Eventos
Navegue pelos logs de aplicativos e serviços relacionados ao Windows e ao NCSI.
Procure eventos no horário exato em que o estado mudou.
O ideal é reproduzir o problema.
Anote:
07:30 — conexão normal
07:35 — VPN conectada
07:36 — Windows muda para Sem Internet
07:37 — evento NCSI registrado
Agora temos uma sequência temporal.
Isso vale muito mais do que encontrar um erro aleatório de três dias atrás.
Event Viewer: cuidado com falsos culpados
Todo Windows possui eventos de aviso e erro.
Isso é normal.
O fato de existir um evento vermelho não significa que ele esteja causando o problema.
Pergunte:
o horário coincide?
o evento se repete quando o problema ocorre?
o evento desaparece quando a conexão funciona?
ele menciona a interface correta?
Essa metodologia reduz falsos diagnósticos.
Etapa 19 — Não esqueça o horário do problema
Problemas intermitentes são difíceis porque o técnico frequentemente chega quando tudo voltou a funcionar.
Por isso, registre:
- hora;
- rede utilizada;
- VPN;
- Wi-Fi ou cabo;
- endereço IP;
- DNS;
- estado do NCSI.
Quando o problema ocorrer novamente, compare.
Talvez exista um padrão.
Por exemplo:
sempre depois de sair da suspensão.
Sempre depois de conectar VPN.
Sempre quando troca Ethernet por Wi-Fi.
Sempre depois de renovar DHCP.
Esses padrões são extremamente valiosos.
Etapa 20 — Reiniciar o computador resolve temporariamente?
Essa informação também importa.
Se reiniciar corrige, mas o problema retorna horas depois, não considere o caso resolvido.
A reinicialização pode:
- renovar estados;
- reiniciar serviços;
- recarregar drivers;
- remover rotas temporárias;
- reconectar VPN;
- limpar determinadas condições.
Ela não necessariamente elimina a causa.
Pergunte:
o que muda antes do problema retornar?
Essa é a pergunta que pode revelar o verdadeiro defeito.
O problema aparece depois da suspensão?
Notebooks passam constantemente por:
- suspensão;
- Modern Standby;
- troca de Wi-Fi;
- mudança de local;
- VPN;
- reconexão.
Imagine:
notebook conectado na empresa;
entra em suspensão;
usuário chega em casa;
acorda o computador;
conecta ao Wi-Fi doméstico;
o estado de conectividade fica incorreto.
Agora temos um cenário envolvendo transição de rede.
Nesses casos, driver, serviços, VPN e atualização de estado podem entrar no diagnóstico.
Reiniciar o adaptador é diferente de reiniciar o computador
Durante testes controlados, podemos desabilitar e habilitar novamente um adaptador.
Mas faça isso somente se souber qual interface está utilizando e se não depender dela para uma sessão remota.
Em suporte remoto, desabilitar a interface ativa pode simplesmente derrubar o atendimento.
Essa observação parece óbvia, mas evita muitos problemas.
E o comando ipconfig /release e /renew?
Esses comandos estão relacionados ao DHCP para interfaces que utilizam configuração dinâmica.
Eles podem ser úteis quando o problema envolve concessão DHCP ou parâmetros recebidos.
Mas não são solução universal para NCSI.
Se:
IP está correto;
gateway está correto;
DNS está correto;
Internet funciona;
o problema está especificamente na sondagem;
renovar DHCP pode não mudar absolutamente nada.
Use o comando quando a hipótese envolver DHCP.
E netsh winsock reset?
Outro clássico.
netsh winsock reset
redefine o catálogo Winsock.
Pode ajudar em determinados problemas envolvendo componentes e provedores relacionados à pilha de sockets.
Mas novamente:
não é o primeiro passo.
Executá-lo sem necessidade pode mascarar o diagnóstico.
Primeiro descubra se existe evidência de corrupção ou interferência na pilha.
Reset de rede do Windows
O Windows também possui uma opção gráfica de redefinição de rede.
Esse recurso pode reinstalar adaptadores e restaurar determinadas configurações.
É uma ferramenta útil em situações específicas.
Mas deve ficar perto do final do diagnóstico, não do início.
Especialmente em computadores com:
- VPN corporativa;
- IP manual;
- adaptadores virtuais;
- software especializado.
Um reset pode exigir reconfiguração posterior.
Não formate o Windows por causa do ícone
Parece exagero, mas acontece.
O usuário tenta:
DNS;
driver;
reset;
Registro;
firewall;
roteador.
Nada funciona.
Então considera formatar.
Antes disso, precisamos provar que existe realmente uma corrupção local impossível de resolver de forma mais simples.
Se o navegador e os serviços funcionam e apenas a detecção NCSI está errada, reinstalar todo o sistema operacional seria uma medida extremamente desproporcional sem investigação adequada.
Um roteiro rápido de diagnóstico
Podemos resumir a sequência inicial assim:
1. Internet realmente funciona?
Teste navegação e conectividade.
2. O que Get-NetConnectionProfile informa?
Veja IPv4 e IPv6.
3. Qual interface está ativa?
Use Get-NetAdapter.
4. Quais IP, gateway e DNS estão configurados?
Use ipconfig /all.
5. O DNS do NCSI resolve?
Use nslookup ou Resolve-DnsName.
6. Existe proxy?
Verifique Windows e WinHTTP.
7. Existe VPN?
Compare conectado e desconectado quando permitido.
8. Existe filtro de segurança?
Analise firewall, DNS e software.
9. O problema acontece em outra rede?
Compare.
10. Outro computador apresenta o mesmo comportamento?
Compare novamente.
11. Existem eventos NCSI no mesmo horário?
Consulte os logs.
Somente depois disso devemos pensar em alterações mais invasivas.
Exemplo prático 1 — DNS filtrado
Imagine:
Chrome funciona.
YouTube funciona.
Ping externo funciona.
Windows mostra:
Sem Internet.
Executamos:
Get-NetConnectionProfile
e percebemos que o Windows não classifica a interface como Internet.
Depois:
nslookup www.microsoft.com
funciona.
Mas:
nslookup dns.msftncsi.com
falha.
Consultando outro servidor DNS diretamente, o nome resolve.
Agora temos uma hipótese forte:
o DNS utilizado pela rede está interferindo na verificação do NCSI.
Nesse cenário, mexer em driver de rede não faria sentido.
Exemplo prático 2 — VPN
Sem VPN:
Internet
Com VPN:
Sem Internet
Navegação continua funcionando.
Desconecta VPN:
Internet
Reconecta:
Sem Internet
Esse padrão é muito forte.
Agora investigamos:
- DNS da VPN;
- rotas;
- políticas;
- firewall;
- split tunneling;
- proxy.
Não começamos formatando o Windows.
Exemplo prático 3 — Apenas uma rede apresenta o problema
Casa:
NCSI normal.
Hotspot do celular:
NCSI normal.
Empresa:
Sem Internet.
Isso aponta para algo específico na infraestrutura empresarial.
Talvez exista:
- proxy;
- firewall;
- DNS interno;
- política;
- bloqueio deliberado.
O computador provou que consegue realizar a detecção corretamente em outras redes.
Exemplo prático 4 — Apenas um computador apresenta o problema
PC A:
normal.
PC B:
normal.
PC C:
Sem Internet, mas navega.
Todos estão na mesma rede.
Nesse caso, compare o PC C com os outros.
Verifique:
- DNS;
- proxy;
- VPN;
- firewall;
- driver;
- software instalado;
- configurações NCSI.
A infraestrutura deixa de ser a principal suspeita.
A regra de ouro: descubra onde o problema acompanha
Esse princípio resolve muitos problemas de informática.
Se o defeito acompanha:
o computador, investigue o computador.
Se acompanha:
a rede, investigue a rede.
Se acompanha:
a VPN, investigue a VPN.
Se acompanha:
um servidor DNS, investigue o DNS.
Se acompanha:
uma interface, investigue a interface.
Comparações controladas transformam um problema aparentemente misterioso em um conjunto pequeno de hipóteses.
Não tente fazer o ícone ficar bonito
O objetivo técnico não consiste em convencer o Windows a mostrar o globo correto.
O objetivo consiste em descobrir por que a classificação está errada.
Modificar o Registro para forçar ou impedir determinadas verificações pode mudar o sintoma.
Mas se DNS, proxy, firewall ou VPN continuam configurados incorretamente, o defeito real permanece.
Esse princípio vale para praticamente todo diagnóstico:
não esconda o sintoma antes de entender a causa.
Como corrigir o erro “Sem Internet” quando a conexão funciona
Nas partes anteriores entendemos como o NCSI trabalha e como diagnosticar o problema.
Agora chega a parte mais importante:
corrigir sem mascarar a causa.
Quando o Windows mostra “Sem Internet”, mas a navegação funciona, existem várias possibilidades. Cada uma exige uma abordagem diferente.
Por isso, a correção deve ser baseada no que já foi encontrado durante o diagnóstico.
Correção 1 — Quando o problema está no DNS
Se os testes mostraram que o Windows consegue resolver domínios normais, mas falha especificamente nos nomes utilizados pelo NCSI, o servidor DNS merece atenção.
Imagine:
nslookup www.microsoft.com
funciona.
Mas:
nslookup dns.msftncsi.com
falha.
Nesse cenário, podemos estar diante de:
- filtro DNS;
- bloqueio do roteador;
- política empresarial;
- software de segurança;
- DNS com listas de bloqueio;
- Pi-hole;
- AdGuard Home;
- controle parental.
A correção correta consiste em descobrir quem está bloqueando.
Teste comparativo
Podemos comparar temporariamente utilizando outro servidor DNS.
Por exemplo:
nslookup dns.msftncsi.com 1.1.1.1
ou:
nslookup dns.msftncsi.com 8.8.8.8
Se o nome resolve nesses servidores, mas não no DNS configurado normalmente, a evidência fica muito forte.
Isso não significa que você obrigatoriamente precisa abandonar o DNS atual.
Pode ser suficiente corrigir a regra responsável pelo bloqueio.
Quando vale trocar o DNS
Trocar o DNS pode fazer sentido quando:
- o servidor atual apresenta falhas reais;
- existe bloqueio não intencional;
- a resolução apresenta erros;
- a configuração está incorreta.
Mas não devemos transformar Google DNS ou Cloudflare em “cura universal”.
O ideal é entender a causa antes.
Correção 2 — Quando o cache DNS está inconsistente
Se existe suspeita de resposta antiga ou incorreta armazenada localmente, podemos limpar o cache.
Execute:
ipconfig /flushdns
Depois repita o teste.
Mas lembre:
se o servidor DNS continua entregando a mesma resposta errada, o problema voltará imediatamente.
Correção 3 — Quando existe proxy incorreto
Se o diagnóstico mostrou uma configuração de proxy inesperada, revise:
Configurações → Rede e Internet → Proxy
Observe:
- detecção automática;
- script de configuração;
- proxy manual.
Também verifique:
netsh winhttp show proxy
Se aparecer um proxy que não deveria existir, precisamos descobrir de onde ele veio.
Pode ter sido:
- configurado manualmente;
- aplicado por software;
- definido por política;
- instalado por ferramenta de segurança.
Em ambiente empresarial, não remova proxy sem autorização.
Redefinir proxy WinHTTP
Em determinados cenários controlados, existe o comando:
netsh winhttp reset proxy
Mas ele não deve ser usado automaticamente.
Antes, confirme que a configuração atual realmente está errada.
Caso contrário, você pode remover uma configuração necessária.
Correção 4 — Quando a VPN interfere
Se o problema aparece somente com VPN conectada, investigue a própria VPN.
Verifique:
- DNS;
- rotas;
- split tunneling;
- firewall;
- proxy;
- política corporativa.
Em VPN empresarial, muitas dessas configurações são intencionais.
Nesse cenário, “corrigir” localmente pode quebrar acesso corporativo.
O ideal é validar com o administrador da rede.
Correção 5 — Quando um firewall bloqueia a sondagem
Se logs ou testes indicam bloqueio de endpoints do NCSI, revise as regras do firewall.
Não crie exceções amplas.
Evite liberar “qualquer tráfego Microsoft”.
Prefira ajustar exatamente o que está sendo bloqueado.
Esse princípio melhora segurança e facilita manutenção futura.
Correção 6 — Quando um DNS filtrado bloqueia msftconnecttest
Ferramentas de filtragem podem classificar determinados endpoints de conectividade como rastreamento ou telemetria.
Mas bloquear esses endereços pode afetar a detecção do Windows.
Se o objetivo do filtro não era quebrar o NCSI, crie uma exceção específica para os domínios utilizados pelo mecanismo.
Mais uma vez:
confirme primeiro.
Não adicione whitelist apenas porque encontrou um domínio em um tutorial.
Correção 7 — Quando o problema está em IPv6
Se IPv4 funciona normalmente e IPv6 apresenta falha, investigue:
- roteador;
- anúncio de rota;
- DNS;
- operadora;
- VPN;
- firewall.
O erro comum consiste em simplesmente desativar IPv6.
Isso pode fazer o sintoma desaparecer.
Mas a infraestrutura continua incorreta.
Se a rede deveria oferecer IPv6, o ideal é corrigir o funcionamento.
Correção 8 — Quando a rede pública possui portal cativo
Em hotel, aeroporto, shopping ou hospital, o Windows pode mostrar ausência de Internet até a autenticação ser concluída.
Nesse caso:
- abra o navegador;
- tente acessar uma página simples;
- aguarde o redirecionamento;
- conclua o login;
- aguarde a nova detecção.
Se a página de portal não aparecer, às vezes desconectar e reconectar ao Wi-Fi pode ajudar a disparar uma nova tentativa.
Correção 9 — Quando o problema aparece após suspensão
Se o defeito acontece sempre depois que o notebook retorna da suspensão, investigue:
- driver da placa;
- VPN;
- adaptação de rede;
- energia do adaptador;
- transição entre Wi-Fi e Ethernet.
Atualizar o driver pode fazer sentido nesse cenário.
Prefira o driver fornecido pelo fabricante do notebook ou da placa quando houver uma versão adequada.
Correção 10 — Quando existe driver problemático
Abra:
Gerenciador de Dispositivos → Adaptadores de Rede
Identifique o modelo.
Verifique:
- versão do driver;
- data;
- fabricante.
Se o problema surgiu após uma atualização, também vale investigar regressão.
Não instale drivers aleatórios de sites desconhecidos.
Correção 11 — Quando o perfil de rede está inconsistente
Em alguns casos, o perfil da rede pode ficar inconsistente.
O comando:
Get-NetConnectionProfile
ajuda a identificar.
Antes de alterar qualquer categoria, entenda se a rede deveria ser:
Private
ou:
Public
A categoria não determina diretamente a existência de Internet, mas regras de firewall podem mudar conforme o perfil.
Correção 12 — Quando o problema está na tabela de rotas
Se o computador possui:
- Wi-Fi;
- Ethernet;
- VPN;
- adaptadores virtuais;
podem existir rotas conflitantes.
Execute:
route print
e:
Get-NetRoute
Compare gateways e métricas.
Evite apagar rotas manualmente sem saber sua origem.
Softwares como VPNs e hipervisores podem recriá-las automaticamente.
O que fazer quando nada óbvio aparece
Se:
- DNS funciona;
- proxy está correto;
- VPN não interfere;
- firewall não bloqueia;
- IPv4 e IPv6 estão coerentes;
- outro computador funciona;
- outra rede funciona;
então vale aprofundar em logs e estado dos serviços.
Não desative EnableActiveProbing como solução
Esse ponto merece destaque.
Existem muitos tutoriais recomendando alterar:
EnableActiveProbing
no Registro.
O raciocínio costuma ser:
“Se o Windows não consegue detectar corretamente, desative a detecção.”
Essa abordagem pode esconder o sintoma.
Mas ela não corrige o que impediu o NCSI de funcionar.
Além disso, pode afetar comportamentos esperados do Windows e de aplicações que dependem desse estado.
A recomendação mais segura é investigar a causa.
Registro do Windows não deve ser o primeiro recurso
Alterações no Registro podem ter efeito imediato e parecer eficientes.
Mas justamente por isso são perigosas quando usadas sem diagnóstico.
Antes de modificar qualquer chave:
- documente o valor atual;
- confirme a relação com o problema;
- entenda o impacto;
- crie ponto de restauração quando apropriado;
- altere apenas uma variável.
E se o problema for apenas cosmético?
Pode acontecer.
Se:
- navegador funciona;
- aplicações funcionam;
- Windows Update funciona;
- VPN funciona;
- DNS funciona;
- não existe impacto real;
e apenas o ícone está incorreto, o problema pode ser principalmente visual.
Mesmo assim, vale investigar se o estado NCSI está incorreto.
Porque uma aplicação futura pode depender dele.
Como validar se a correção funcionou
Depois de aplicar uma correção, não olhe apenas para o ícone.
Repita os testes.
Execute:
Get-NetConnectionProfile
Confira:
IPv4Connectivity
e:
IPv6Connectivity
Depois valide:
nslookup dns.msftncsi.com
Também teste navegação.
Se havia VPN, repita com a VPN.
Se o problema ocorria após suspensão, reproduza o ciclo de suspensão.
Uma correção só está validada quando o cenário que provocava o defeito deixa de reproduzi-lo.
Documente antes e depois
Um diagnóstico profissional pode registrar algo como:
Antes
Windows:
Sem Internet
IPv4Connectivity : LocalNetwork
DNS:
domínios comuns resolvem
NCSI:
falha
VPN:
desconectada
Firewall:
ativo
Depois
Regra de filtro corrigida
IPv4Connectivity : Internet
NCSI:
normal
Navegação:
normal
Assim conseguimos provar o que mudou.
Erros comuns encontrados em tutoriais
Erro 1 — Desativar Active Probing
Pode esconder o problema em vez de corrigir.
Erro 2 — Desativar IPv6
Pode mascarar falha de configuração.
Erro 3 — Resetar Winsock sem diagnóstico
Pode alterar o ambiente sem revelar a causa.
Erro 4 — Fazer reset de rede imediatamente
Pode remover configurações válidas.
Erro 5 — Trocar DNS e considerar resolvido
Se a causa era um filtro ou política, talvez o problema volte.
Erro 6 — Desligar firewall
Reduz segurança e não explica o defeito.
Erro 7 — Formatar o Windows
É uma medida extrema para um problema que frequentemente possui causa bem menor.
Checklist final
Quando o Windows mostra “Sem Internet”, mas a conexão funciona:
- teste navegação real;
- teste IP externo;
- teste resolução DNS;
- execute
Get-NetConnectionProfile; - execute
Get-NetAdapter; - confira
ipconfig /all; - teste
dns.msftncsi.com; - compare outro DNS;
- verifique proxy;
- verifique WinHTTP;
- identifique VPN;
- analise rotas;
- compare IPv4 e IPv6;
- revise firewall;
- teste outra rede;
- compare outro computador;
- consulte logs NCSI;
- corrija apenas a causa encontrada;
- repita os testes;
- documente o resultado.
FAQ — Windows mostra “Sem Internet”, mas funciona
Por que o Windows mostra Sem Internet mesmo com sites abrindo?
Porque o Windows usa mecanismos próprios para verificar conectividade. Se a sondagem do NCSI falhar, o sistema pode não confirmar acesso à Internet mesmo que outros programas consigam navegar.
O que é NCSI?
NCSI significa Network Connectivity Status Indicator. Ele ajuda o Windows a determinar se existe acesso local ou completo à Internet.
msftconnecttest é vírus?
Não. Ele está relacionado aos testes de conectividade realizados pelo Windows.
Posso bloquear msftconnecttest?
Pode ser possível, mas isso pode causar detecção incorreta de conectividade. Antes de bloquear, entenda o impacto.
Vale a pena desativar EnableActiveProbing?
Não como solução genérica. O ideal é descobrir por que a sondagem falha.
Trocar DNS pode resolver?
Sim, se o DNS atual estiver bloqueando ou respondendo incorretamente. Mas o correto é confirmar isso por comparação.
VPN pode causar esse problema?
Sim. VPNs podem modificar DNS, rotas, proxy e firewall.
Desativar IPv6 resolve?
Pode alterar o sintoma, mas não necessariamente corrige a causa.
Reset de rede resolve?
Pode ajudar em alguns casos, mas é uma ferramenta mais invasiva e não deve ser a primeira tentativa.
O problema pode afetar aplicativos?
Sim. Alguns programas usam o estado de conectividade fornecido pelo Windows.
O problema pode acontecer depois da suspensão?
Sim. Transições de rede, VPNs e drivers podem contribuir.
Preciso formatar o computador?
Na maioria dos casos, não. O ideal é identificar a falha específica antes de considerar uma reinstalação completa.
Conclusão
Quando o Windows mostra “Sem Internet”, mas a Internet funciona, o problema pode parecer contraditório.
Na verdade, existem duas coisas diferentes acontecendo.
A primeira é:
conectividade real.
A segunda é:
detecção de conectividade.
O navegador pode acessar a Internet enquanto o NCSI falha em confirmar o estado esperado.
Isso pode acontecer por:
DNS;
proxy;
VPN;
firewall;
filtros;
IPv6;
rotas;
portal cativo;
driver;
transição de rede.
O erro mais comum consiste em tentar corrigir o ícone.
Mas o ícone é apenas o resultado.
O diagnóstico correto procura a causa.
Quando entendemos como o NCSI funciona, o problema deixa de parecer misterioso.
Em vez de:
“Windows está bugado.”
passamos a perguntar:
“Qual etapa da detecção falhou?”
Essa mudança de raciocínio transforma tentativa e erro em diagnóstico técnico.
Precisa de ajuda com problemas de rede no Windows?
A VMIA realiza diagnóstico de computadores, notebooks, redes domésticas, Wi-Fi, roteadores, VPNs, impressoras e problemas de conectividade no Windows.
Se o computador mostra “Sem Internet”, mas alguns programas continuam funcionando, podemos analisar DNS, rotas, drivers, configurações do sistema e comportamento da rede antes de aplicar resets ou modificações desnecessárias.
Atendimento com agendamento, presencial ou remoto, conforme o tipo de problema.
VMIA — Manutenção e Configuração
WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
Avaliações: https://avaliacao.vmia.com.br
Atendimento em São Paulo e suporte remoto para problemas compatíveis com acesso à distância.
Faça um comentário