Você está usando o Windows 11 normalmente. O navegador abre sites, o Google funciona, talvez até um vídeo esteja sendo reproduzido, mas existe algo estranho na barra de tarefas: o Windows mostra que não há acesso à Internet.
Em outras situações acontece exatamente o contrário. O computador está conectado ao Wi-Fi, o ícone aparentemente indica uma conexão normal, mas nenhum site abre.
Existe ainda um terceiro cenário bastante comum: o Windows exibe o ícone de globo, indicando ausência ou limitação do acesso à Internet, enquanto alguns programas continuam funcionando normalmente.
Como isso é possível?
A resposta está em um componente pouco conhecido do Windows chamado NCSI — Network Connectivity Status Indicator, ou Indicador de Status da Conectividade de Rede.
O NCSI faz parte do mecanismo usado pelo Windows para determinar se uma interface de rede possui apenas conectividade local ou consegue realmente alcançar a Internet.
Isso significa que o Windows não considera simplesmente:
“Estou conectado ao Wi-Fi, portanto tenho Internet.”
Também não basta o computador receber um endereço IP do roteador.
É perfeitamente possível existir:
- conexão Wi-Fi;
- endereço IPv4 válido;
- gateway configurado;
- comunicação com outros computadores da rede;
- acesso ao painel do roteador;
e, mesmo assim, o Windows concluir que não existe conectividade com a Internet.
É justamente nesse processo de identificação que entra o NCSI.
Neste guia, vamos entender como o Windows 11 realiza essa verificação, quais servidores entram no processo, por que o famoso msftconnecttest.com aparece em logs e capturas de rede e, principalmente, por que às vezes o Windows mostra o ícone de globo mesmo quando a Internet aparentemente está funcionando.
O ícone de rede do Windows não mostra apenas se o Wi-Fi está conectado
Antes de entender o NCSI, precisamos separar dois conceitos que frequentemente causam confusão:
conexão com a rede local e conexão com a Internet.
Quando um notebook se conecta ao Wi-Fi, isso prova inicialmente que houve uma associação entre o adaptador sem fio e o ponto de acesso.
Depois disso, normalmente entra o DHCP.
O computador pode receber informações como:
Endereço IPv4: 192.168.1.105
Máscara: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.1
Nesse momento, o computador já pode conversar com dispositivos da rede local.
Por exemplo:
ping 192.168.1.1
pode responder normalmente.
Uma impressora de rede também pode continuar acessível.
Um NAS pode funcionar.
O compartilhamento de arquivos entre dois computadores pode funcionar.
Mas nada disso comprova, sozinho, que existe acesso à Internet.
O roteador pode estar ligado e funcionando perfeitamente na LAN enquanto a conexão WAN da operadora está indisponível.
Por isso o Windows precisa descobrir algo além de:
“Existe uma rede?”
Ele precisa responder:
“Esta rede consegue chegar à Internet?”
Essa diferença é fundamental para compreender o NCSI.
O que significa NCSI?
NCSI significa:
Network Connectivity Status Indicator.
De forma simplificada, ele é responsável por ajudar o Windows a avaliar o nível de conectividade disponível.
O resultado dessa avaliação influencia o estado de rede mostrado pelo sistema e também pode ser consultado por aplicativos.
No Windows 11, a arquitetura relacionada ao NCSI mudou em relação às versões anteriores do Windows. A documentação atual da Microsoft informa que, no Windows 11, essa função está associada ao Network List Service (NLS/netprofm), enquanto versões anteriores utilizavam o Network Location Awareness (NLA) nesse processo.
Portanto, encontramos muitos tutoriais antigos sobre NCSI que descrevem corretamente versões anteriores do Windows, mas não necessariamente refletem todos os detalhes atuais do Windows 11.
Outro ponto importante:
NCSI não é simplesmente um ping automático feito pelo Windows.
O mecanismo trabalha principalmente com probes, ou sondagens/testes de conectividade.
Esses testes podem ser classificados principalmente em:
- Active Probing;
- Passive Probing.
Em português, podemos entender como:
- verificação ativa;
- verificação passiva.
As duas técnicas ajudam o Windows a construir uma visão mais confiável sobre o estado da conexão.
Active Probing: o Windows testa ativamente se existe Internet
A parte mais conhecida do NCSI é o Active Probing.
Quando determinadas mudanças acontecem na rede, o Windows pode iniciar uma verificação ativa.
Entre os eventos capazes de disparar uma nova verificação estão alterações na interface de rede, mudanças nas condições da rede, alterações relacionadas a proxy e detecção de hotspots.
Imagine que você acabou de conectar o notebook ao Wi-Fi.
O adaptador estabelece a conexão.
O DHCP entrega as configurações.
A interface fica pronta.
Agora o Windows precisa descobrir:
essa rede realmente oferece Internet?
O NCSI pode então realizar uma sondagem ativa.
No Windows 11, segundo a documentação atual da Microsoft, HTTP é utilizado na sondagem ativa. Pode existir atividade DNS durante o processo, mas ela participa da localização necessária para que o teste HTTP seja realizado.
Isso é importante porque muitos artigos antigos descrevem o funcionamento do NCSI como uma simples escolha entre um teste DNS ou HTTP.
No Windows 11 atual, essa explicação fica incompleta.
O famoso msftconnecttest.com
Quem já analisou uma rede com Wireshark, firewall, Pi-hole, AdGuard, proxy corporativo ou algum sistema de filtragem provavelmente encontrou o domínio:
www.msftconnecttest.com
Ele não apareceu por acaso.
A partir do Windows 10 versão 1607, a Microsoft passou a utilizar uma URL do Microsoft Connect Test para essa verificação.
O Windows pode solicitar:
http://www.msftconnecttest.com/connecttest.txt
O arquivo é extremamente simples.
O importante não é apresentar uma página para o usuário.
O objetivo é permitir que o Windows faça uma requisição HTTP e verifique se recebeu exatamente o resultado esperado.
Quando o servidor responde corretamente, o Windows obtém uma evidência de que aquela interface consegue alcançar um recurso conhecido na Internet.
A resposta HTTP esperada inclui:
HTTP 200 OK
e um conteúdo conhecido pelo sistema.
O conteúdo esperado é:
Microsoft Connect Test
Esse detalhe é muito importante.
O Windows não verifica simplesmente se qualquer página apareceu.
Ele sabe o que espera receber.
Isso ajuda, entre outras coisas, a detectar redes que interceptam a navegação.
Por que o Windows não testa simplesmente google.com?
Seria possível imaginar uma solução mais simples:
ping google.com
Se responder, existe Internet.
Mas essa abordagem apresentaria diversos problemas.
Primeiro, muitos servidores e redes bloqueiam ICMP. Portanto, ausência de resposta ao ping não significa necessariamente ausência de Internet.
Segundo, um domínio comum pode apresentar comportamento diferente dependendo de CDN, DNS, firewall, proxy, localização geográfica e outros fatores.
Terceiro, o Windows precisa de um endpoint cujo comportamento esperado seja conhecido.
Com um servidor específico de teste, o sistema sabe aproximadamente:
- qual endereço deseja acessar;
- qual recurso deseja solicitar;
- qual resposta espera receber.
Isso transforma o teste em algo muito mais controlado do que simplesmente tentar acessar um site aleatório.
DNS também participa do processo
Antes de acessar:
www.msftconnecttest.com
o Windows precisa descobrir para qual endereço o domínio aponta.
É aí que entra o DNS.
Portanto, uma falha de DNS pode provocar um comportamento curioso.
A conexão física está funcionando.
O computador consegue conversar com o roteador.
O gateway está correto.
Talvez você consiga até acessar um servidor usando diretamente seu endereço IP.
Porém, se a resolução DNS necessária para o NCSI falhar, o teste pode não ser concluído corretamente.
O Windows pode então considerar que existe apenas conectividade local ou apresentar um estado diferente do esperado.
Isso explica uma situação clássica:
o ícone de globo nem sempre significa que o Wi-Fi caiu.
Pode existir um problema em outra camada da comunicação.
Um exemplo prático
Imagine este cenário:
Notebook
|
| Wi-Fi
|
Roteador
|
| Internet
|
Operadora
O notebook recebe:
IP: 192.168.0.20
Gateway: 192.168.0.1
DNS: 192.168.0.1
Você executa:
ping 192.168.0.1
Resultado:
Resposta de 192.168.0.1
Até aqui sabemos apenas que existe comunicação entre notebook e roteador.
Agora tente:
ping 8.8.8.8
Se houver resposta, já temos evidência de comunicação IP para fora da rede local.
Depois:
nslookup www.msftconnecttest.com
Se o nome for resolvido, o DNS também parece estar funcionando.
Porém, ainda existe uma diferença importante.
O NCSI possui seu próprio processo de verificação e precisa receber a resposta esperada.
Por isso um simples:
ping www.msftconnecttest.com
não reproduz integralmente a decisão tomada pelo NCSI.
O Windows pode mostrar “sem Internet” mesmo com Internet funcionando?
Sim.
Esse é provavelmente o aspecto mais interessante do NCSI.
Imagine que um firewall permita normalmente:
google.com
youtube.com
vmia.com.br
mas bloqueie:
msftconnecttest.com
Para o usuário, aparentemente existe Internet.
O navegador abre.
O WhatsApp funciona.
O e-mail talvez funcione.
Mas o teste utilizado pelo NCSI pode falhar.
Consequentemente, o Windows pode não classificar aquela interface como tendo acesso completo à Internet.
Temos então duas situações diferentes:
Internet real
A capacidade efetiva do computador de acessar recursos externos.
Estado detectado pelo Windows
A conclusão obtida pelo mecanismo de detecção de conectividade.
Normalmente os dois estados coincidem.
Quando não coincidem, surgem problemas aparentemente contraditórios.
O ícone de globo não é necessariamente prova de queda da Internet
Essa conclusão merece destaque.
Quando aparece o famoso ícone de globo no Windows 11, não devemos imediatamente concluir:
“A placa Wi-Fi está com defeito.”
Nem:
“O roteador perdeu a Internet.”
O símbolo informa o estado que o Windows determinou para aquela conexão.
A falha pode estar relacionada a vários elementos, incluindo:
- DNS;
- proxy;
- VPN;
- firewall;
- portal cativo;
- filtragem de conteúdo;
- falha temporária de conectividade;
- bloqueio do endpoint utilizado pelo NCSI;
- configuração corporativa da rede.
A própria Microsoft documenta que problemas de proxy, arquivos PAC, VPN, DNS e condições intermitentes podem impedir que uma sondagem ativa seja concluída corretamente.
Por isso, em um diagnóstico profissional, o ícone deve ser tratado como uma informação, e não como diagnóstico definitivo.
Active Probing e Passive Probing trabalham juntos
Até agora falamos principalmente da verificação ativa.
Mas o NCSI não depende exclusivamente dela.
Existe também o chamado Passive Probing.
Na análise passiva, o Windows utiliza informações aprendidas a partir do tráfego recebido e do comportamento da interface para ajudar a determinar o estado da conectividade.
Isso é importante porque redes reais não são ambientes perfeitos.
Uma sondagem ativa pode falhar temporariamente.
O roteador pode apresentar alguns segundos de instabilidade.
Um servidor pode demorar para responder.
Uma VPN pode ainda estar estabelecendo suas rotas.
Um proxy pode estar sendo detectado.
A análise passiva oferece informações adicionais que ajudam o Windows a acompanhar essas mudanças.
Segundo a Microsoft, os mecanismos ativo e passivo são complementares.
Portanto, descrever o NCSI apenas como:
“Windows baixa connecttest.txt e decide se existe Internet.”
é uma simplificação.
Esse teste é extremamente importante, mas existe uma lógica maior por trás da avaliação da conectividade.
Por que desativar o NCSI geralmente é uma péssima solução
Na Internet existem diversos tutoriais ensinando a alterar:
EnableActiveProbing
no Registro do Windows.
A configuração pode ser encontrada dentro da estrutura:
HKEY_LOCAL_MACHINE
\SYSTEM
\CurrentControlSet
\Services
\NlaSvc
\Parameters
\Internet
Também existem políticas administrativas capazes de controlar as sondagens ativas.
Isso não significa que desativá-las seja uma boa solução para eliminar o ícone de globo.
Na realidade, a Microsoft recomenda não desativar a sondagem ativa como solução para problemas do NCSI.
O motivo é simples.
A verificação passiva, sozinha, não consegue identificar corretamente todas as situações de conectividade.
Além disso, outros componentes e aplicativos podem utilizar o estado informado pelo NCSI.
Portanto, quando existe um problema, o melhor caminho normalmente não é impedir o Windows de testar a conexão.
O correto é descobrir:
por que o teste está falhando?
Essa mudança de raciocínio faz enorme diferença no diagnóstico.
NCSI não afeta apenas o desenho mostrado na barra de tarefas
Outro erro comum é acreditar que o NCSI existe exclusivamente para escolher qual símbolo aparece perto do relógio.
O estado de conectividade pode ser utilizado por outros componentes e aplicativos.
A Microsoft cita, entre outros exemplos, aplicações e serviços que consultam informações relacionadas ao estado da rede.
Por isso podemos encontrar situações nas quais:
- o navegador funciona;
- alguns sites abrem;
- mas determinado aplicativo afirma estar offline.
Nesses casos, existe a possibilidade de o programa estar tomando decisões com base no estado de conectividade fornecido pelo Windows.
Isso não significa que todo aplicativo offline com navegador funcionando seja culpa do NCSI.
Mas significa que o NCSI precisa entrar na lista de hipóteses durante o diagnóstico.
O que acontece em redes com portal cativo?
Existe outro cenário em que o NCSI se torna particularmente interessante: hotéis, aeroportos, universidades, hospitais, shoppings e redes Wi-Fi públicas.
Você conecta ao Wi-Fi.
Tecnicamente, a associação foi realizada.
O DHCP entrega um endereço IP.
O gateway responde.
Mas você ainda não possui acesso normal à Internet.
Primeiro precisa abrir uma página e:
- aceitar os termos;
- informar alguma credencial;
- inserir um código;
- confirmar o acesso.
Esse sistema é conhecido como captive portal, ou portal cativo.
Imagine agora o que aconteceria se o Windows solicitasse:
http://www.msftconnecttest.com/connecttest.txt
e o hotspot interceptasse a requisição.
Em vez de devolver o conteúdo esperado, ele poderia redirecionar a conexão para sua página de autenticação.
O NCSI percebe que não recebeu o resultado que esperava.
Essa diferença ajuda o Windows a identificar que a rede ainda não oferece acesso normal à Internet.
É também uma das razões pelas quais, em determinadas redes públicas, o Windows pode abrir ou sugerir uma página para concluir a autenticação.
Uma maneira melhor de interpretar o ícone de rede
Depois de entender o NCSI, podemos mudar completamente a maneira de interpretar os indicadores do Windows.
Em vez de pensar:
Wi-Fi conectado = Internet funcionando
podemos imaginar uma sequência:
Adaptador funcionando
↓
Conexão com Wi-Fi/Ethernet
↓
Configuração IP
↓
Gateway
↓
DNS
↓
Roteamento externo
↓
Teste NCSI
↓
Estado de conectividade informado ao Windows
Cada etapa responde a uma pergunta diferente.
Isso também explica por que um bom diagnóstico de rede não deve começar imediatamente com:
netsh winsock reset
ou:
ipconfig /flushdns
Executar comandos aleatórios até a conexão voltar pode até funcionar ocasionalmente, mas não revela a causa.
Um diagnóstico melhor identifica em qual etapa a comunicação parou.
E o NCSI pode fornecer pistas extremamente úteis nessa investigação.
Como diagnosticar o NCSI quando o Windows 11 mostra “Sem Internet”
Na primeira parte vimos que o Windows 11 não utiliza apenas o fato de o computador estar conectado ao Wi-Fi ou ao cabo para determinar se existe Internet.
O NCSI realiza verificações próprias e fornece ao sistema uma indicação sobre o estado da conectividade.
Agora surge a parte mais útil para quem precisa resolver problemas:
como descobrir por que o Windows mostra o ícone de globo ou informa “Sem Internet”?
O primeiro cuidado é não começar alterando configurações.
Antes de limpar DNS, reinstalar drivers, redefinir a rede ou executar comandos de reset, precisamos descobrir em qual ponto a comunicação está falhando.
Podemos organizar o diagnóstico em uma sequência:
Adaptador
↓
Endereço IP
↓
Gateway
↓
Internet por IP
↓
DNS
↓
HTTP
↓
Teste do NCSI
↓
Estado informado pelo WindowsEsse método evita um problema muito comum no suporte técnico: executar várias correções simultaneamente e nunca descobrir o que realmente estava errado.
1. Primeiro descubra se existe uma falha real de Internet
Suponha que o Windows apresente o ícone de globo.
Abra o Prompt de Comando:
cmdExecute:
ipconfigProcure o adaptador que está sendo utilizado.
Em uma rede doméstica típica podemos encontrar algo parecido com:
Adaptador de Rede sem Fio Wi-Fi:
Endereço IPv4. . . . . . . . . . : 192.168.1.105
Máscara de Sub-rede . . . . . . . : 255.255.255.0
Gateway Padrão. . . . . . . . . . : 192.168.1.1O endereço exato depende da configuração do roteador.
Outras faixas privadas bastante comuns são:
192.168.0.x
10.0.0.x
172.16.x.xSe existe um endereço IPv4 coerente com a rede e um gateway padrão, já sabemos que pelo menos parte da configuração IP foi concluída.
Mas isso ainda não comprova acesso à Internet.
2. Encontrou um endereço 169.254.x.x? Pare o diagnóstico do NCSI por enquanto
Existe um resultado que muda completamente nossa investigação.
Se ipconfig mostrar algo semelhante a:
169.254.37.82o computador provavelmente não recebeu normalmente uma configuração IPv4 do servidor DHCP e utilizou um endereço de link local APIPA.
Nesse cenário, investigar msftconnecttest.com ainda não é nossa prioridade.
O problema está em uma etapa anterior.
Precisamos investigar elementos como:
- servidor DHCP;
- comunicação com o roteador;
- adaptador de rede;
- VLAN;
- Wi-Fi;
- cabo;
- switch;
- configuração manual incorreta;
- serviço DHCP Client;
- conflito ou falha da infraestrutura.
O NCSI não consegue provar acesso normal à Internet se a própria configuração básica da interface não está funcionando corretamente.
Essa é uma regra importante:
não comece pelo NCSI quando a camada IP já apresenta um problema evidente.
3. Teste o gateway padrão
Se o computador possui IP válido, descubra o gateway:
ipconfigSuponha que seja:
192.168.1.1Execute:
ping 192.168.1.1Se houver resposta, temos uma evidência de que o computador consegue alcançar o roteador pela rede local.
Exemplo:
Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64Mas atenção:
gateway respondendo não significa Internet funcionando.
O roteador pode responder perfeitamente enquanto a conexão da operadora está fora do ar.
Por outro lado, ausência de resposta também não deve ser usada isoladamente como prova absoluta de falha, porque determinados equipamentos podem restringir ICMP.
O ping é uma ferramenta de diagnóstico, não um detector universal de Internet.
4. Teste comunicação externa sem depender primeiro do DNS
Agora queremos responder outra pergunta:
o computador consegue alcançar um endereço fora da rede local?
Podemos testar um endereço IP público conhecido, desde que ele aceite ICMP.
Por exemplo:
ping 1.1.1.1ou:
ping 8.8.8.8Se houver resposta, temos uma pista importante.
A comunicação IP externa está funcionando.
Agora compare:
ping 1.1.1.1com:
ping www.microsoft.comSe o primeiro funciona e o segundo falha porque o nome não pode ser localizado, o problema pode estar relacionado ao DNS.
Mas novamente devemos ter cuidado:
um host não responder ao ping não significa automaticamente que está inacessível por HTTP ou HTTPS.
Por isso vamos complementar o teste.
5. Verifique o DNS utilizado pelo Windows
Execute:
ipconfig /allProcure:
Servidores DNSVocê pode encontrar algo como:
192.168.1.1Nesse caso, o computador envia as consultas ao roteador, que atua como intermediário ou encaminhador DNS.
Também podemos encontrar diretamente servidores como:
1.1.1.1
8.8.8.8ou servidores internos de uma empresa.
Agora teste a resolução:
nslookup www.msftconnecttest.comSe tudo estiver funcionando, o comando deverá conseguir resolver o domínio.
O endereço retornado pode variar, portanto não utilize um IP encontrado em um tutorial antigo como referência fixa.
O importante é saber se a resolução ocorre corretamente.
6. Teste também o domínio relacionado ao DNS do NCSI
Outro domínio que pode aparecer durante análises do mecanismo é:
dns.msftncsi.comPodemos consultar:
nslookup dns.msftncsi.comAqui existe uma distinção importante.
No Windows 11 atual, não devemos interpretar essa consulta como se o sistema simplesmente realizasse um teste DNS isolado e, com base nele, decidisse que existe Internet.
A documentação da Microsoft explica que a sondagem ativa do Windows 11 utiliza HTTP. O DNS participa do processo necessário para localizar o destino da sondagem.
Mesmo assim, testar:
nslookup dns.msftncsi.come:
nslookup www.msftconnecttest.compode fornecer pistas importantes sobre problemas de resolução.
7. Teste o connecttest.txt manualmente
Agora chegamos a um teste muito interessante.
Abra no navegador:
http://www.msftconnecttest.com/connecttest.txtO conteúdo esperado é simples:
Microsoft Connect TestSe o navegador acessar corretamente esse recurso, sabemos que o endpoint está alcançável pelo navegador.
Porém, isso ainda não garante que o NCSI esteja conseguindo realizar exatamente o mesmo processo.
Por quê?
Porque podem existir diferenças relacionadas a:
- proxy;
- contexto do processo;
- VPN;
- políticas corporativas;
- firewall;
- autenticação;
- filtros;
- momento em que a sondagem ocorreu;
- interfaces de rede disponíveis.
Mesmo assim, esse é um excelente teste inicial.
8. Use PowerShell para testar o HTTP
O PowerShell permite fazer uma verificação adicional.
Podemos utilizar:
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Observe o resultado.
Queremos verificar principalmente se recebemos a resposta HTTP e o conteúdo esperado.
Em uma situação normal, devemos conseguir identificar:
StatusCode : 200e o conteúdo:
Microsoft Connect TestSe isso funcionar enquanto o Windows continua indicando ausência de Internet, começamos a suspeitar de um falso negativo, de uma condição temporária ou de alguma particularidade no processo utilizado pelo NCSI.
9. Test-NetConnection ajuda a separar DNS, TCP e HTTP
Outro comando muito útil no PowerShell é:
Test-NetConnection www.msftconnecttest.com -Port 80Esse comando não reproduz toda a lógica do NCSI.
Mas ajuda a responder:
é possível estabelecer comunicação TCP com o servidor pela porta 80?
Procure:
TcpTestSucceededSe aparecer:
TcpTestSucceeded : Truea conexão TCP com a porta testada foi estabelecida.
Agora temos uma sequência de informações:
nslookup
↓
DNS funciona?
Test-NetConnection
↓
TCP porta 80 funciona?
Invoke-WebRequest
↓
HTTP funciona e o conteúdo esperado chega?Isso é muito mais útil do que executar simplesmente:
ping www.msftconnecttest.com10. Por que a porta 80 é importante nesse diagnóstico?
Observe que o endereço utilizado pelo teste é:
http://e não necessariamente:
https://Isso é proposital.
O NCSI precisa identificar situações em que uma rede intercepta a primeira tentativa de navegação para apresentar um portal cativo.
Isso acontece frequentemente em:
- hotéis;
- aeroportos;
- hospitais;
- universidades;
- empresas;
- shoppings;
- redes públicas.
Se o Windows solicitar o arquivo esperado e receber uma página diferente, existe uma pista de que a rede está interceptando a comunicação.
Portanto, não devemos simplesmente concluir:
“HTTP é antigo; vou bloquear toda porta 80 e pronto.”
Dependendo da política da rede, bloquear o endpoint ou a comunicação necessária pode interferir na detecção de conectividade do Windows.
11. Firewall pode causar falso “Sem Internet”
Imagine uma empresa que configure o firewall assim:
Internet geral → permitida
msftconnecttest.com → bloqueadoO usuário consegue abrir vários sites.
Porém, o endpoint utilizado pelo teste de conectividade não está disponível.
O resultado pode ser contraditório:
Chrome → Internet funciona
Edge → Internet funciona
E-mail → funciona
Windows → Sem InternetNesse cenário, trocar a placa de rede não resolveria.
Reinstalar o driver também provavelmente não resolveria.
Trocar o roteador talvez não resolvesse.
O problema está na diferença entre conectividade real disponível e capacidade do NCSI de comprovar essa conectividade.
12. Pi-hole, AdGuard e filtros DNS também merecem atenção
Usuários mais avançados podem utilizar:
- Pi-hole;
- AdGuard Home;
- NextDNS;
- DNS corporativo;
- filtros de segurança;
- bloqueadores no roteador;
- sistemas de controle parental.
Esses sistemas podem bloquear domínios considerados de telemetria ou serviços da Microsoft.
Dependendo das regras utilizadas, um domínio necessário ao processo de detecção de conectividade pode acabar bloqueado.
Por isso, ao investigar um falso “Sem Internet”, verifique os logs do servidor DNS.
Procure requisições relacionadas a:
msftconnecttest.come:
msftncsi.comSe estiverem sendo bloqueadas, temos uma pista importante.
Isso não significa que todo usuário deve simplesmente liberar qualquer domínio sem análise.
Em redes empresariais, alterações precisam respeitar a política de segurança definida pelos administradores.
13. Proxy é um dos grandes causadores de comportamento estranho
Empresas ainda utilizam proxies em diversos ambientes.
Além disso, malware, programas antigos e configurações abandonadas podem deixar proxies configurados no Windows.
Comece verificando:
Configurações → Rede e Internet → Proxy
Mas existe outro teste importante.
Abra o Prompt ou PowerShell como administrador e execute:
netsh winhttp show proxyVocê pode encontrar:
Direct access (no proxy server).ou alguma configuração de proxy.
Em sistemas em português, a mensagem exibida pode aparecer traduzida.
Se existir um proxy configurado, precisamos descobrir se ele é realmente necessário.
Não remova configurações corporativas sem autorização.
14. Proxy do navegador e WinHTTP não são exatamente a mesma coisa
Esse detalhe explica muitos casos aparentemente impossíveis.
Um usuário diz:
“Mas o Edge abre normalmente.”
Isso não prova que todos os componentes do Windows consigam acessar a Internet exatamente da mesma forma.
Aplicativos e serviços podem utilizar mecanismos diferentes para comunicação e configuração de proxy.
Por isso, durante o diagnóstico, precisamos verificar tanto a experiência do navegador quanto as configurações utilizadas pelo sistema.
O comando:
netsh winhttp show proxyé especialmente útil nesse contexto.
15. VPN pode alterar completamente o diagnóstico
Agora imagine:
PC
↓
Wi-Fi
↓
Roteador
↓
Internet
↓
VPN
↓
Rede corporativaAo conectar uma VPN, podem mudar:
- rotas;
- DNS;
- gateway;
- métricas;
- interfaces;
- filtros;
- regras de firewall.
Por isso, se o problema começou após conectar uma VPN, faça uma comparação controlada.
Teste:
VPN desconectadae depois:
VPN conectadaCompare:
ipconfig /allroute printnslookup www.msftconnecttest.comTest-NetConnection www.msftconnecttest.com -Port 80Essa comparação pode revelar imediatamente onde o comportamento muda.
16. Cuidado com split tunneling
Algumas VPNs utilizam split tunneling.
Nesse modelo, apenas parte do tráfego passa pelo túnel.
Por exemplo:
Rede corporativa → VPN
Internet normal → conexão localOutras VPNs encaminham praticamente todo o tráfego pelo túnel:
Tudo → VPNIsso pode alterar a forma como o Windows percebe a conectividade.
Também pode acontecer de:
- DNS passar pela VPN;
- HTTP sair pela conexão local;
- determinadas rotas irem para o túnel;
- outras permanecerem no gateway doméstico.
Quando o problema ocorre apenas com a VPN ativa, route print passa a ser uma ferramenta muito importante.
17. Analise a tabela de rotas
Execute:
route printO resultado pode parecer assustador para quem nunca trabalhou com roteamento.
Procure principalmente a rota padrão IPv4:
0.0.0.0 0.0.0.0Ela ajuda a indicar por onde o Windows pretende enviar tráfego destinado a redes para as quais não existe uma rota mais específica.
Em um computador simples, normalmente teremos uma situação relativamente clara.
Em um computador com:
- Ethernet;
- Wi-Fi;
- VPN;
- Hyper-V;
- VMware;
- VirtualBox;
- Docker;
a tabela pode ficar muito mais complexa.
É exatamente nesses computadores que problemas de detecção de conectividade ficam mais interessantes.
18. Duas interfaces podem ter Internet ao mesmo tempo
Imagine um notebook conectado simultaneamente:
Ethernet
+
Wi-FiAs duas interfaces podem possuir gateway.
Agora adicione uma VPN.
Temos três caminhos possíveis.
O Windows utiliza sua tabela de roteamento e métricas para decidir qual caminho utilizar para determinado destino.
Por isso não devemos analisar apenas:
"o Wi-Fi está conectado?"Precisamos descobrir:
qual interface está sendo usada para chegar ao destino do teste?
No PowerShell podemos começar examinando:
Get-NetIPConfiguratione:
Get-NetRoutePara uma visão mais específica das rotas padrão IPv4:
Get-NetRoute -DestinationPrefix "0.0.0.0/0"Isso pode mostrar mais de uma rota disponível.
19. IPv4 funciona, mas IPv6 não: isso pode influenciar?
Sim, e esse é um detalhe importante.
O Windows moderno trabalha com IPv4 e IPv6.
Segundo a documentação da Microsoft, quando ambos estão disponíveis, o NCSI pode executar sondagens para IPv4 e IPv6 em paralelo.
Isso significa que um diagnóstico completo não deve simplesmente ignorar IPv6.
Podemos verificar a configuração com:
ipconfig /allE testar:
ping -4 www.microsoft.come:
ping -6 www.microsoft.comTambém podemos utilizar:
Test-NetConnection www.microsoft.comO objetivo não é concluir que IPv6 precisa obrigatoriamente responder a todos os testes, mas descobrir se existe uma diferença significativa entre as duas pilhas.
20. Não desative IPv6 apenas para “ver se resolve”
Esse é outro procedimento muito comum em tutoriais antigos.
Surge um problema de rede e a primeira recomendação é:
desmarque IPv6.
Isso pode mascarar o problema em vez de resolvê-lo.
O Windows 11 foi projetado para trabalhar com IPv6 e diversos componentes assumem sua disponibilidade.
Se existe um problema específico com IPv6, devemos identificá-lo.
Podemos comparar:
IPv4com:
IPv6e descobrir qual caminho está apresentando falha.
Desativar um protocolo inteiro deve ser uma decisão técnica fundamentada, não o primeiro passo do diagnóstico.
21. Como diferenciar DNS quebrado de NCSI quebrado
Podemos montar uma pequena matriz de diagnóstico.
Situação A
Gateway → OK
IP externo → OK
DNS → FALHA
NCSI → FALHASuspeita principal:
DNS.
Situação B
Gateway → OK
IP externo → OK
DNS → OK
Sites → OK
connecttest.txt → FALHASuspeitas:
- firewall;
- filtro DNS;
- proxy;
- bloqueio do endpoint;
- política de rede.
Situação C
Gateway → OK
Internet → OK
DNS → OK
connecttest.txt → OK
Windows → continua mostrando Sem InternetAgora a investigação precisa avançar para:
- eventos do NCSI;
- serviços;
- políticas;
- VPN;
- estado armazenado pelo sistema;
- condições específicas da interface.
Situação D
Gateway → FALHA
Internet → FALHA
DNS → FALHA
NCSI → FALHANesse caso, o NCSI provavelmente está apenas informando corretamente que existe um problema real de conectividade.
22. O Visualizador de Eventos pode revelar o que aconteceu
Quando os testes manuais funcionam, mas o Windows continua mostrando o estado incorreto, precisamos perguntar:
o que o próprio NCSI registrou?
Abra:
eventvwr.mscO Windows possui logs específicos relacionados ao NCSI.
Um caminho importante para investigação é encontrado em:
Logs de Aplicativos e Serviços
↓
Microsoft
↓
Windows
↓
NCSIDependendo da versão e configuração do sistema, os canais disponíveis podem variar.
Esses eventos podem fornecer informações muito mais úteis do que simplesmente observar o ícone da barra de tarefas.
Podemos encontrar pistas relacionadas a:
- início da sondagem;
- interface utilizada;
- resultado;
- resolução;
- HTTP;
- mudanças no estado de conectividade.
Para técnicos, essa é uma das etapas mais interessantes do diagnóstico.
23. PowerShell também pode ajudar a consultar eventos
Em vez de navegar manualmente pelo Visualizador de Eventos, podemos usar PowerShell.
Primeiro descubra os logs relacionados:
Get-WinEvent -ListLog *NCSI*Isso é melhor do que assumir que o nome exato do canal será idêntico em todas as instalações.
Depois de identificar o canal disponível, podemos consultar seus eventos com Get-WinEvent.
Por exemplo, usando o nome retornado pelo sistema:
Get-WinEvent -LogName "NOME-DO-LOG" -MaxEvents 30Assim podemos correlacionar:
horário em que apareceu o globo
↓
evento registrado
↓
mudança de interface
↓
resultado da sondagemEssa correlação é muito mais poderosa do que simplesmente redefinir toda a rede.
24. Teste importante: desconecte temporariamente interfaces adicionais
Em computadores usados para desenvolvimento ou virtualização podemos encontrar várias interfaces:
Ethernet
Wi-Fi
vEthernet
VMware Network Adapter
VirtualBox Host-Only
VPN
TAP Adapter
WireGuardIsso não significa que exista um problema.
Interfaces virtuais são normais quando seus respectivos programas precisam delas.
Porém, para diagnóstico, podemos simplificar temporariamente o cenário.
Se for seguro e você souber quais interfaces pertencem a cada software, teste utilizando apenas a conexão necessária.
Por exemplo:
Wi-Fi → ativo
Ethernet → desconectado
VPN → desconectadaDepois observe novamente o estado.
A ideia não é apagar adaptadores aleatoriamente.
É reduzir variáveis durante o teste.
25. Não use “Redefinição de Rede” como primeiro passo
O Windows 11 possui uma opção de redefinição de rede.
Ela pode ser útil em determinados problemas.
Mas existe uma diferença enorme entre:
usar uma redefinição depois de identificar corrupção ou configuração problemática
e:
usar uma redefinição porque apareceu um globo.
A redefinição pode remover ou recriar configurações importantes e exigir nova configuração de:
- VPN;
- adaptadores;
- redes;
- softwares de virtualização;
- configurações personalizadas.
Em computadores empresariais, isso pode gerar ainda mais trabalho.
Primeiro diagnostique.
Depois corrija.
26. Sequência VMIA para diagnosticar “Sem Internet”
Quando o Windows 11 mostrar o globo, uma sequência eficiente seria:
1. ipconfig /allVerifique:
- IP;
- máscara;
- gateway;
- DNS;
- interfaces.
Depois:
2. ping <gateway>Em seguida:
3. teste comunicação externaDepois:
4. nslookup www.msftconnecttest.comEm seguida:
5. Test-NetConnection www.msftconnecttest.com -Port 80Depois:
6. Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Confira:
7. netsh winhttp show proxySe houver VPN:
8. compare conectado/desconectadoAnalise:
9. route printE, finalmente:
10. eventos do NCSIEssa sequência cria um diagnóstico progressivo.
Cada teste responde a uma pergunta.
27. O que não fazer imediatamente
Ao encontrar o ícone de globo, evite começar executando uma coleção de comandos como:
ipconfig /flushdns
netsh winsock reset
netsh int ip resetEsses comandos possuem usos legítimos.
O problema é executá-los sem saber o que estamos tentando corrigir.
Imagine que o verdadeiro problema seja um firewall bloqueando o Microsoft Connect Test.
Você redefine Winsock.
Reinicia.
O problema continua.
Redefine TCP/IP.
Reinicia.
Continua.
Reinstala o adaptador.
Continua.
Troca o DNS.
Talvez continue.
Depois de uma hora de alterações, o computador possui diversas configurações modificadas e você ainda não sabe a causa original.
Diagnóstico técnico funciona melhor quando cada alteração testa uma hipótese.
28. O NCSI pode ser usado como ferramenta de diagnóstico
Existe uma mudança de perspectiva interessante aqui.
Normalmente enxergamos o ícone de globo como um problema.
Mas ele também pode ser uma pista.
Se:
sites funcionam
+
NCSI informa Sem Internetpodemos perguntar:
o que existe de diferente entre o tráfego que funciona e a sondagem do Windows?
Essa pergunta direciona a investigação para:
- DNS;
- HTTP;
- proxy;
- VPN;
- firewall;
- rotas;
- filtros;
- políticas.
O símbolo deixa de ser apenas uma irritação visual e passa a fornecer uma pista sobre o comportamento da rede.
29. Diagnóstico rápido: falso negativo ou Internet realmente fora?
Uma maneira prática de pensar é:
O navegador abre vários sites?
|
SIM
↓
O DNS resolve msftconnecttest.com?
|
SIM
↓
A porta 80 está acessível?
|
SIM
↓
connecttest.txt retorna o conteúdo esperado?
|
SIM
↓
Investigue NCSI, proxy, VPN, políticas e eventosSe a resposta for “não” em uma etapa, acabamos de encontrar um ponto concreto para investigar.
Essa metodologia é muito superior a tentar “consertar o ícone”.
Nosso objetivo é descobrir por que o Windows chegou àquela conclusão.
Como corrigir falso “Sem Internet” do NCSI sem quebrar a rede
Na Parte 2 montamos uma sequência de diagnóstico para descobrir se existe realmente uma falha de Internet ou se o Windows 11 apenas está interpretando incorretamente o estado da conexão.
Agora vamos trabalhar com o cenário mais interessante:
Internet funciona
+
sites abrem
+
DNS responde
+
Windows mostra "Sem Internet"Nesse caso, o problema pode estar diretamente relacionado à maneira como o NCSI executa ou interpreta suas sondagens.
A tentação é pesquisar na Internet e aplicar a primeira solução encontrada:
EnableActiveProbing = 0O ícone pode até mudar de comportamento.
Porém, isso não significa que corrigimos a causa.
Na verdade, podemos apenas ter impedido o Windows de executar uma das verificações que estavam revelando o problema.
A própria Microsoft alerta que não recomenda desativar as sondagens do NCSI como solução geral. Alguns componentes do Windows e aplicativos utilizam o estado fornecido pelo NCSI, e uma configuração incorreta pode gerar efeitos colaterais.
Por isso, nesta parte vamos seguir outra abordagem:
descobrir exatamente o que impede o teste de funcionar e corrigir essa causa.
1. Antes de alterar qualquer coisa, confirme que é realmente um problema de NCSI
Uma condição importante para começar esta investigação é:
o computador precisa ter conectividade real com a Internet.
Abra alguns sites diferentes.
Teste também PowerShell:
Test-NetConnection www.microsoft.com -Port 443Depois:
Test-NetConnection www.msftconnecttest.com -Port 80Em seguida:
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Se o último comando devolver o conteúdo esperado:
Microsoft Connect Testtemos uma evidência forte de que o endpoint está acessível naquele momento.
Agora existe uma diferença interessante:
Internet funcionando
↓
Endpoint acessível
↓
Windows ainda diz "Sem Internet"Nesse cenário, devemos começar a analisar estado, políticas, interfaces, eventos, VPNs e proxies.
2. Entenda o EnableActiveProbing antes de mexer nele
Uma configuração frequentemente citada em tutoriais fica em:
HKEY_LOCAL_MACHINE
\SYSTEM
\CurrentControlSet
\Services
\NlaSvc
\Parameters
\InternetDentro dessa chave podemos encontrar:
EnableActiveProbingEm condições normais, a sondagem ativa deve permanecer disponível.
Podemos consultar o valor pelo Prompt:
reg query "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbingOu pelo PowerShell:
Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" `
-Name EnableActiveProbingO importante aqui é consultar antes de alterar.
Se alguém, algum script de otimização, ferramenta de privacidade ou política empresarial tiver modificado essa configuração, você acabou de encontrar uma pista.
A Microsoft documenta EnableActiveProbing como uma das configurações relacionadas à sondagem ativa do NCSI.
3. EnableActiveProbing = 0 não é uma “correção do globo”
Esse ponto precisa ficar claro.
Configurar:
EnableActiveProbing = 0pode desativar a sondagem ativa correspondente.
Isso não significa:
problema resolvidoSignifica:
mecanismo de teste alteradoSão coisas muito diferentes.
Imagine que um firewall esteja bloqueando:
www.msftconnecttest.comA solução tecnicamente correta seria investigar por que isso acontece e decidir se o endpoint deve ser permitido naquela rede.
Desligar o NCSI apenas para fazer o ícone parar de incomodar seria equivalente a retirar a lâmpada de advertência do painel de um carro sem corrigir o defeito que fez a luz acender.
Além disso, a Microsoft alerta explicitamente que a sondagem passiva, isoladamente, não consegue identificar todas as situações de conectividade.
4. Existe também uma política chamada NoActiveProbe
Além da configuração localizada em NlaSvc, existe uma política do Windows relacionada ao NCSI.
O caminho de Registro associado pode aparecer como:
HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicatorDentro dele pode existir:
NoActiveProbeUma configuração de política pode substituir o comportamento esperado.
Verifique:
reg query "HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator"Se a chave não existir, isso não significa erro.
Em uma instalação comum sem políticas específicas, determinados valores de política simplesmente não estarão presentes.
A Microsoft documenta NoActiveProbe como política capaz de controlar os testes ativos do NCSI.
5. Política de Grupo também pode controlar o NCSI
Em edições do Windows que possuem o Editor de Política de Grupo Local, execute:
gpedit.mscExistem políticas relacionadas ao Network Connectivity Status Indicator.
Dependendo da política específica, elas podem controlar elementos como:
- sondagem ativa;
- sondagem passiva;
- comportamento DNS;
- configurações administrativas relacionadas ao NCSI.
Isso se torna especialmente importante em computadores:
- corporativos;
- ingressados em domínio;
- gerenciados por MDM;
- administrados por Intune;
- configurados por scripts.
Um computador empresarial pode apresentar comportamento diferente de outro aparentemente idêntico porque recebeu políticas específicas.
A Microsoft mantém políticas administrativas próprias para NCSI em versões atuais do Windows 11.
6. Como saber se uma política veio da empresa?
Um comando útil é:
gpresult /rPara gerar um relatório mais completo:
gpresult /h "%USERPROFILE%\Desktop\gpresult.html"Depois abra o arquivo criado na Área de Trabalho.
Esse relatório pode ajudar a identificar políticas aplicadas ao computador e ao usuário.
Em ambientes corporativos, não altere essas configurações manualmente sem autorização.
Uma política pode ter sido aplicada por motivos como:
- segurança;
- proxy;
- VPN;
- intranet;
- isolamento de rede;
- conformidade.
O objetivo do diagnóstico não é simplesmente “forçar o Windows a mostrar Internet”.
É entender por que o ambiente foi configurado daquela maneira.
7. Redes empresariais podem bloquear Internet de propósito
Existe um caso em que o ícone “Sem Internet” pode estar tecnicamente correto, mesmo quando diversos serviços funcionam.
Imagine uma estação empresarial que acessa:
servidor.local
ERP
servidor de arquivos
intranet
impressorasmas não possui acesso livre à Internet.
Nesse caso:
rede local → funcionando
Internet pública → bloqueadaO NCSI pode classificar a conexão como conectividade local.
Isso não é necessariamente erro.
É o comportamento esperado para aquela arquitetura.
Portanto, sempre precisamos perguntar:
esta rede deveria ter acesso irrestrito à Internet?
8. Proxy automático e arquivos PAC são causas importantes
Um dos problemas documentados pela Microsoft envolve proxy e arquivos PAC.
PAC significa:
Proxy Auto-Configuration.
Um arquivo PAC contém regras que determinam como determinados destinos devem ser acessados.
De maneira simplificada, ele pode decidir:
site A → proxy
site B → conexão direta
site C → outro proxySe houver erro no arquivo PAC ou o NCSI não conseguir utilizar corretamente o caminho necessário, uma sondagem pode falhar.
A Microsoft cita explicitamente erros de proxy, configuração incorreta e problemas de PAC como causas capazes de impedir uma sondagem ativa.
9. Descubra se existe proxy WinHTTP
Execute:
netsh winhttp show proxyEm uma conexão sem proxy WinHTTP configurado, podemos encontrar uma mensagem indicando acesso direto.
Se aparecer um endereço de proxy, anote-o.
Não execute imediatamente:
netsh winhttp reset proxyEsse comando pode ser útil em situações específicas, mas pode quebrar a comunicação de uma máquina corporativa configurada corretamente.
Primeiro descubra:
quem configurou esse proxy?
Pode ser:
- empresa;
- antivírus;
- VPN;
- software antigo;
- malware;
- script;
- configuração manual.
10. Verifique também as configurações gráficas de proxy
No Windows 11, acesse:
Configurações → Rede e Internet → Proxy
Observe principalmente:
- detectar configurações automaticamente;
- usar script de configuração;
- usar servidor proxy.
Se houver um script configurado, anote o endereço.
Agora temos outra comparação útil:
Proxy do Windows
↓
WinHTTP
↓
Aplicativos
↓
NCSINem todo componente utiliza exatamente o mesmo mecanismo.
É por isso que podemos encontrar situações nas quais:
navegador funcionamas:
determinados serviços do Windows não funcionam11. VPN pode produzir um falso negativo temporário
A própria Microsoft documenta configurações de VPN e atrasos durante a instalação do túnel como possíveis causas de falha de sondagem ativa.
Pense no que acontece durante a conexão de uma VPN.
Antes:
PC
↓
Roteador
↓
InternetDurante a conexão:
PC
↓
nova interface virtual
↓
novas rotas
↓
novo DNS
↓
VPNDurante alguns instantes, a tabela de roteamento pode estar mudando.
Se uma sondagem ocorrer exatamente nesse momento, ela pode utilizar um caminho que ainda não está completamente disponível.
Resultado:
NCSI → falhamesmo que alguns segundos depois tudo funcione normalmente.
12. Compare a rede antes e depois da VPN
Antes de conectar:
ipconfig /allSalve:
route printDepois conecte a VPN e repita:
ipconfig /allroute printCompare principalmente:
- DNS;
- gateway;
- interface;
- métricas;
- rotas padrão;
- IPv4;
- IPv6.
No PowerShell:
Get-NetRoute -DestinationPrefix "0.0.0.0/0"Também:
Get-DnsClientServerAddressIsso permite visualizar rapidamente se a VPN substituiu os servidores DNS.
13. Um teste interessante: NCSI com VPN ligada e desligada
Faça:
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"com a VPN desligada.
Depois repita com a VPN conectada.
Também teste:
Test-NetConnection www.msftconnecttest.com -Port 80Se funcionar sem VPN e falhar com VPN, reduzimos drasticamente o universo de hipóteses.
Agora podemos investigar:
- rota;
- DNS da VPN;
- proxy;
- firewall da VPN;
- política corporativa.
Esse é um exemplo perfeito de diagnóstico por comparação.
14. Pi-hole: veja o log antes de liberar qualquer coisa
Se a rede usa Pi-hole, AdGuard Home ou outro filtro DNS, abra o log de consultas.
Procure:
msftconnectteste:
msftncsiSe aparecer algo semelhante a:
Blockedou:
Deniedtemos uma pista.
Uma lista de bloqueio muito agressiva pode interpretar alguns endpoints da Microsoft como telemetria e impedir consultas necessárias ao mecanismo de detecção.
Porém, não devemos liberar domínios aleatoriamente.
Primeiro confirme que o bloqueio realmente coincide com o problema.
15. Faça um teste controlado com outro DNS
Se suspeitamos de filtragem DNS, podemos testar temporariamente utilizando outro resolvedor permitido naquele ambiente.
Por exemplo, em uma rede doméstica, compare o comportamento do DNS atual com um resolvedor conhecido.
Mas não faça essa alteração em:
- rede empresarial;
- computador de domínio;
- rede escolar;
- ambiente que exige DNS interno.
Por quê?
Porque o DNS interno pode ser necessário para localizar:
- servidores;
- domínio;
- Active Directory;
- impressoras;
- aplicativos internos.
Trocar DNS sem entender a infraestrutura pode resolver um sintoma e criar cinco novos problemas.
16. Use nslookup especificando o servidor DNS
Uma alternativa melhor para diagnóstico é consultar diretamente um servidor sem necessariamente alterar a configuração da placa.
Exemplo:
nslookup www.msftconnecttest.com 1.1.1.1Depois compare com:
nslookup www.msftconnecttest.comO primeiro consulta explicitamente um resolvedor específico.
O segundo utiliza o DNS configurado normalmente no Windows.
Se:
DNS padrão → falha
DNS alternativo → resolvetemos uma pista muito forte de problema no caminho DNS atual.
17. Firewall local também pode interferir
Não pense apenas no firewall do roteador.
O próprio computador pode possuir:
- Windows Defender Firewall;
- suíte de segurança;
- agente corporativo;
- EDR;
- firewall de terceiros;
- filtro web.
Esses programas podem analisar ou bloquear comunicação por:
- domínio;
- endereço IP;
- porta;
- aplicativo;
- categoria.
Uma regra pode permitir o navegador e bloquear outro processo.
Consequentemente:
Chrome → funcionaenquanto:
sondagem do Windows → falhaIsso explica por que testar apenas com navegador não encerra a investigação.
18. Não desative o firewall inteiro para testar
Um procedimento muito utilizado é:
“Desative o firewall e veja se resolve.”
Em muitos casos, existe uma alternativa melhor.
Analise:
- logs;
- regras;
- eventos;
- política aplicada.
Se for necessário realizar um teste temporário, ele deve ser controlado e realizado em ambiente seguro.
O objetivo é identificar a regra responsável, e não transformar o computador em uma máquina sem proteção apenas para eliminar uma hipótese.
19. Portal cativo: quando receber resposta é justamente o problema
Normalmente pensamos:
recebi uma página HTTP = funcionouNo NCSI isso não basta.
Suponha que o Windows solicite:
http://www.msftconnecttest.com/connecttest.txtMas a rede devolva:
<html>
Faça login para acessar o Wi-Fi
</html>Houve uma resposta HTTP.
Porém, não foi a resposta esperada.
Isso indica que a navegação está sendo interceptada.
Esse comportamento é útil em redes com portal cativo.
A documentação da Microsoft explica que, quando existe um portal cativo e o acesso ainda não foi liberado, a interface pode permanecer classificada apenas com capacidade local.
20. Por que o Windows abre uma janela do navegador sozinho?
Você entra em um hotel, conecta ao Wi-Fi e de repente aparece uma página pedindo autenticação.
Isso não significa necessariamente:
“O Windows abriu publicidade.”
Pode fazer parte do mecanismo de detecção do portal cativo.
O Windows percebe que a resposta esperada não chegou e identifica que a rede provavelmente exige interação.
A Microsoft documenta que a abertura do navegador nesse cenário é um comportamento intencional para facilitar a autenticação em portais cativos.
21. O falso portal cativo
Agora imagine um problema mais curioso.
Um firewall ou filtro intercepta:
msftconnecttest.come devolve uma página própria:
Acesso bloqueado pela política da empresaPara o NCSI, isso se parece muito com uma interceptação da comunicação.
O usuário talvez consiga acessar outros sites normalmente, mas o teste não recebe:
Microsoft Connect TestResultado:
Internet parcialmente funcional
+
NCSI sem confirmação corretaEsse é um bom exemplo de como uma página de bloqueio pode interferir no estado mostrado pelo Windows.
22. Use o navegador para observar redirecionamentos
Digite:
http://www.msftconnecttest.com/connecttest.txtObserve a barra de endereços.
Se acabar em outro domínio ou página, investigue.
Pergunte:
- houve redirecionamento?
- apareceu página de login?
- apareceu aviso do antivírus?
- apareceu filtro da empresa?
- apareceu erro DNS?
- apareceu bloqueio?
Uma captura simples do comportamento HTTP pode revelar muito sobre a causa.
23. Agora vamos observar o NCSI na rede
Para técnicos ou usuários avançados, uma das formas mais interessantes de entender o problema é capturar o tráfego.
O Wireshark permite visualizar pacotes passando pela interface.
Durante uma mudança de estado da rede, podemos procurar comunicações relacionadas a:
msftconnecttest.come:
msftncsi.comIsso permite confirmar se:
consulta DNS saiu?
↓
resposta DNS chegou?
↓
conexão TCP foi criada?
↓
requisição HTTP saiu?
↓
servidor respondeu?Agora estamos observando o problema diretamente na rede.
24. O que procurar no Wireshark?
Em uma captura, filtros de exibição úteis podem incluir:
dnsDepois procure consultas relacionadas aos nomes utilizados pelo NCSI.
Também podemos observar HTTP:
httpOu limitar por porta:
tcp.port == 80Outra opção é utilizar o endereço IP obtido previamente pelo DNS e filtrar:
ip.addr == ENDERECO_IPMas evite colocar em um tutorial um IP fixo para msftconnecttest.com.
Infraestruturas de Internet podem mudar.
Resolva o nome no momento do teste.
25. O que uma captura pode revelar?
Imagine esta sequência:
DNS Query
www.msftconnecttest.com
↓
DNS Response
↓
TCP SYN
↓
TCP SYN/ACK
↓
HTTP GET /connecttest.txt
↓
HTTP 200
↓
Microsoft Connect TestEsse é um cenário bastante saudável.
Agora imagine:
DNS Query
↓
sem respostaTemos uma suspeita DNS.
Outro cenário:
DNS → OK
TCP SYN → enviado
TCP SYN → retransmitido
TCP SYN → retransmitidoPode existir problema de:
- firewall;
- roteamento;
- conectividade;
- filtro.
Outro:
HTTP GET
↓
HTTP 302
↓
página de autenticaçãoTemos forte indicação de redirecionamento ou portal cativo.
O Wireshark transforma o diagnóstico em evidência.
26. Dá para fazer algo parecido com Pktmon?
Sim.
O Windows possui uma ferramenta nativa chamada:
pktmonO Packet Monitor permite capturar informações de rede sem instalar imediatamente uma ferramenta externa.
Podemos confirmar que ele está disponível:
pktmon /?Em investigações mais avançadas, o Pktmon pode ajudar a descobrir por onde os pacotes estão passando e onde podem estar sendo descartados.
No entanto, ele não deve ser tratado como substituto perfeito do Wireshark.
Cada ferramenta possui vantagens diferentes.
27. Captura de pacotes é etapa avançada, não primeiro passo
Se o problema é simplesmente:
nslookup www.msftconnecttest.comretornando erro, não precisamos começar analisando centenas de pacotes.
A ordem eficiente continua sendo:
IP
↓
gateway
↓
DNS
↓
TCP
↓
HTTP
↓
eventos
↓
capturaQuanto mais avançamos, mais específica fica a investigação.
Esse princípio economiza muito tempo.
28. Múltiplos adaptadores: um detalhe frequentemente ignorado
Execute:
Get-NetAdapterTalvez encontre:
Wi-Fi
Ethernet
vEthernet
VMware Network Adapter
VirtualBox Host-Only
VPN
Bluetooth Network ConnectionCada interface possui:
- estado;
- índice;
- métrica;
- endereços;
- rotas.
Isso significa que uma captura ou teste feito sem observar a interface pode produzir interpretações erradas.
Pergunte sempre:
por qual adaptador esse tráfego está saindo?
29. Observe as métricas das interfaces
Use:
Get-NetIPInterfaceProcure:
InterfaceMetricO Windows utiliza métricas junto com as rotas para determinar qual caminho possui preferência.
Você também pode encontrar configurações automáticas.
Não altere valores apenas porque um tutorial afirma que:
Wi-Fi deve ser 10
Ethernet deve ser 5Isso não é uma regra universal.
Primeiro descubra se a seleção de interface realmente está errada.
30. Hyper-V e vEthernet podem confundir o usuário, mas não são necessariamente defeito
Quando Hyper-V, WSL, Docker ou tecnologias relacionadas estão instaladas, podem aparecer adaptadores como:
vEthernetEles são esperados em muitos cenários.
Não exclua essas interfaces simplesmente porque parecem “estranhas”.
Elas podem participar da rede virtual utilizada por:
- máquinas virtuais;
- containers;
- WSL;
- switches virtuais.
O melhor diagnóstico identifica se determinada interface está realmente interferindo nas rotas ou no estado da conectividade.
31. O mesmo vale para VMware e VirtualBox
VMware e VirtualBox podem adicionar adaptadores virtuais próprios.
Alguns trabalham com:
- NAT;
- bridge;
- host-only.
Esses adaptadores não são automaticamente problemáticos.
Porém, ao diagnosticar um caso complexo, vale observar:
Get-NetAdapterGet-NetIPConfigurationGet-NetRouteO objetivo é reconstruir:
qual é o caminho real utilizado pelo Windows para chegar à Internet?
32. NCSI possui comportamento passivo também
Até aqui nos concentramos muito na sondagem ativa.
Mas o NCSI também utiliza sondagem passiva.
Segundo a documentação da Microsoft, o mecanismo passivo utiliza informações aprendidas do tráfego recebido para ajudar a determinar o estado da conectividade.
Os dois mecanismos se complementam.
Isso é importante em situações de conectividade intermitente.
Imagine:
roteador falha durante alguns segundosUma sondagem ativa pode coincidir exatamente com o problema.
Depois a Internet volta.
O tráfego real observado pela pilha de rede fornece informações adicionais para atualizar o estado.
33. A sondagem passiva também possui política própria
A Microsoft disponibiliza política para controlar o comportamento da sondagem passiva do NCSI.
Em versões modernas do Windows 11, essa política está disponível administrativamente e pode ser gerenciada em ambientes corporativos.
Isso reforça uma conclusão importante:
NCSI é muito mais sofisticado do que apenas baixar um arquivo TXT.
Temos:
sondagem ativa
+
sondagem passiva
+
estado das interfaces
+
roteamento
+
DNS
+
condições da rede
+
políticasO resultado final alimenta o estado de conectividade observado pelo Windows e por aplicativos.
34. Alguns programas podem acreditar que não existe Internet
Esse é um efeito especialmente interessante.
Você abre o navegador.
Tudo funciona.
Abre outro aplicativo.
Ele afirma:
Sem conexão com a InternetÉ tentador concluir imediatamente que o aplicativo possui algum defeito.
Porém, alguns programas consultam APIs do Windows relacionadas ao estado da conectividade.
A documentação da Microsoft cita o Microsoft Office como exemplo de software capaz de utilizar o estado fornecido pelo NCSI. Se o Office reportar ausência de Internet enquanto a navegação funciona, isso pode indicar um problema no NCSI.
Portanto:
Chrome funcionandonão garante que:
todos os aplicativos considerarão o sistema online.35. Isso também explica problemas aparentemente sem relação
Quando o estado de conectividade está errado, podem aparecer sintomas como:
- aplicativo dizendo que está offline;
- serviços demorando para iniciar conexão;
- software esperando conectividade;
- comportamento estranho após conectar VPN;
- ícone incorreto na barra de tarefas.
Não devemos atribuir automaticamente qualquer falha de aplicativo ao NCSI.
Mas quando vários sintomas aparecem ao mesmo tempo e a Internet realmente funciona, ele passa a ser um candidato importante.
36. Quando reiniciar realmente ajuda
Reiniciar o computador pode fazer o problema desaparecer.
Isso acontece porque várias condições são reconstruídas:
interfaces
rotas
DNS
serviços
VPN
estado NCSIMas existe uma diferença entre:
reiniciar resolveue:
reiniciar revelou a causaSe o problema volta todos os dias, reiniciar não é solução.
Precisamos identificar o evento que ocorre antes do problema:
- conecta VPN?
- muda de Wi-Fi?
- acorda da suspensão?
- troca Ethernet por Wi-Fi?
- inicia um software?
- recebe nova política?
- muda DNS?
O padrão temporal costuma revelar a causa.
37. Quando a Redefinição de Rede passa a fazer sentido?
A Redefinição de Rede do Windows é uma ferramenta mais agressiva.
Ela pode fazer sentido quando encontramos sinais de:
- adaptadores corrompidos;
- configurações inconsistentes;
- pilha de rede danificada;
- problemas persistentes após remoção de software de rede;
- VPN removida incorretamente.
Ainda assim, use-a depois de coletar informações.
Antes:
ipconfig /all > "%USERPROFILE%\Desktop\ipconfig.txt"route print > "%USERPROFILE%\Desktop\routes.txt"No PowerShell:
Get-NetAdapter | Out-File "$env:USERPROFILE\Desktop\netadapters.txt"Assim você preserva uma fotografia da configuração anterior.
38. Cuidado: Redefinição de Rede pode exigir reconfiguração
Depois de redefinir a rede, alguns elementos podem precisar ser configurados novamente.
Dependendo do computador:
- VPN;
- Hyper-V;
- switches virtuais;
- software de virtualização;
- IP manual;
- DNS;
- configurações especializadas.
Por isso não transforme:
Configurações → Rede e Internet → Configurações avançadas de rede → Redefinição da rede
em um botão universal de reparo.
Em uma máquina simples pode ser tranquilo.
Em uma estação corporativa ou de desenvolvimento pode gerar bastante trabalho.
39. Winsock reset também não deve ser ritual
Outro comando famoso:
netsh winsock resetWinsock faz parte da arquitetura utilizada pelos aplicativos para comunicação de rede no Windows.
Existem situações em que uma redefinição pode ajudar.
Mas um endpoint do NCSI bloqueado por firewall não será magicamente liberado porque Winsock foi redefinido.
Antes de executar o comando, precisamos de uma hipótese:
há evidência de problema na pilha Winsock?
Se não existe, continue o diagnóstico.
40. O mesmo vale para netsh int ip reset
Outro clássico:
netsh int ip resetEle altera componentes importantes da configuração TCP/IP.
Não deve ser o primeiro comando digitado porque existe um globo perto do relógio.
Uma regra simples para suporte profissional é:
medir
↓
formular hipótese
↓
testar
↓
corrigir
↓
validare não:
reset
↓
reset
↓
reset
↓
reiniciar
↓
torcer41. Como saber se corrigimos realmente o problema?
Depois de qualquer correção, repita a bateria original.
DNS
nslookup www.msftconnecttest.comTCP
Test-NetConnection www.msftconnecttest.com -Port 80HTTP
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Configuração
ipconfig /allRota
route printDepois observe o comportamento durante:
- reinicialização;
- troca de Wi-Fi;
- suspensão;
- VPN;
- troca entre cabo e Wi-Fi.
Uma correção só é convincente quando o problema não retorna no cenário que originalmente o provocava.
42. Método VMIA para falso “Sem Internet”
Podemos resumir o diagnóstico completo em um fluxo.
Windows mostra Sem Internet
↓
Sites também não abrem?
↓
SIM
↓
Diagnosticar conexão geral
IP → gateway → DNS → rota → operadoraSe:
Sites abrem normalmente
↓
Testar msftconnecttestDepois:
DNS falha?
↓
Investigar DNS/filtroSe DNS funciona:
TCP porta 80 falha?
↓
Investigar firewall/rota/VPNSe TCP funciona:
HTTP recebe resposta diferente?
↓
Investigar proxy/portal/filtroSe tudo funciona:
Verificar
políticas
NCSI
eventos
interfaces
VPN
estado do sistemaEsse fluxo evita dezenas de procedimentos desnecessários.
43. O diagnóstico muda completamente quando entendemos o NCSI
Antes:
ícone de globo
↓
"Wi-Fi está ruim"Depois de compreender o NCSI:
ícone de globo
↓
Qual capacidade o Windows detectou?
↓
A rede local funciona?
↓
Existe rota para Internet?
↓
DNS funciona?
↓
A sondagem HTTP consegue sair?
↓
Recebe a resposta esperada?
↓
Existe proxy, VPN ou filtro?
↓
Qual interface está sendo utilizada?Essa é a diferença entre tentativa e diagnóstico.
44. Não “conserte o ícone”; conserte a causa
Essa talvez seja a principal mensagem deste artigo.
O ícone de rede é apenas a parte visível.
Por trás dele existem:
- interfaces;
- rotas;
- DNS;
- IPv4;
- IPv6;
- HTTP;
- proxy;
- VPN;
- firewall;
- NCSI;
- políticas administrativas.
Quando o Windows mostra “Sem Internet”, o melhor procedimento não é procurar uma configuração capaz de esconder o aviso.
É descobrir:
qual teste está falhando e por quê.
Essa abordagem resolve o problema sem criar outro.
Ícone de globo no Windows 11: causas reais, cenários práticos e diagnóstico final
Depois de entender como o NCSI funciona, quais testes ele realiza e como proxy, VPN, DNS, firewall e políticas podem interferir, podemos montar um diagnóstico muito mais objetivo.
O ponto principal é simples:
o ícone de globo não identifica sozinho a causa do problema.
Ele apenas indica que o Windows não conseguiu confirmar o nível de conectividade esperado naquele momento.
Por isso, dois computadores podem mostrar exatamente o mesmo símbolo e terem defeitos completamente diferentes.
Vamos aos cenários mais comuns.
Cenário 1 — Wi-Fi conectado, mas aparece o ícone de globo
Este é o caso clássico.
O usuário vê:
Wi-Fi conectado
+
ícone de globo
+
"Sem Internet"Primeiro verifique:
ipconfigSe houver:
169.254.x.xo problema provavelmente está antes do NCSI, normalmente envolvendo DHCP ou configuração IP.
Se o endereço for válido, teste o gateway.
Depois teste acesso externo.
Depois DNS.
Só então investigue NCSI.
Cenário 2 — Internet funciona, mas Windows continua mostrando “Sem Internet”
Esse cenário é o mais típico de um falso negativo.
Sintomas:
sites abrem
YouTube funciona
WhatsApp funciona
Windows mostra Sem InternetAgora teste:
nslookup www.msftconnecttest.comDepois:
Test-NetConnection www.msftconnecttest.com -Port 80E:
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Se tudo funcionar, investigue:
- políticas;
- VPN;
- proxy;
- filtros locais;
- eventos do NCSI;
- múltiplas interfaces;
- estado temporário da rede.
Cenário 3 — Funciona no cabo, mas Wi-Fi mostra “Sem Internet”
Agora temos uma comparação excelente.
Se:
Ethernet → Internet OK
Wi-Fi → Sem Interneto problema provavelmente não está na Internet da operadora como um todo.
Compare:
ipconfig /allnos dois adaptadores.
Verifique:
- gateway;
- DNS;
- faixa IP;
- métricas;
- perfil da rede.
Também compare:
Get-NetIPConfigurationSe o cabo usa um DNS diferente do Wi-Fi, isso pode explicar o comportamento.
Cenário 4 — O problema começou depois de instalar uma VPN
Esse é um forte sinal para investigar:
- nova interface virtual;
- nova rota padrão;
- DNS da VPN;
- split tunneling;
- firewall da VPN;
- proxy.
Compare:
route printantes e depois da conexão.
Também:
Get-DnsClientServerAddressSe o problema aparece apenas com a VPN ativa, é pouco provável que o defeito esteja no adaptador Wi-Fi físico.
Cenário 5 — O problema aparece depois de sair da suspensão
Alguns usuários relatam:
liga o notebook → Internet normal
suspende
retorna da suspensão → globoNesse caso, observe:
- reconexão do adaptador;
- DHCP;
- renovação de endereço;
- DNS;
- rota;
- VPN;
- driver da placa de rede.
Execute após voltar da suspensão:
ipconfig /allCompare com o resultado antes da suspensão.
Também verifique eventos relacionados à interface.
Esse tipo de problema pode envolver o driver ou a renegociação da rede, e o NCSI apenas mostra a consequência.
Cenário 6 — Outro computador na mesma rede funciona normalmente
Imagine:
PC 1 → normal
PC 2 → Sem InternetAmbos estão no mesmo roteador.
Isso reduz a chance de um problema geral da operadora.
Compare:
IP
gateway
DNS
proxy
VPN
firewall
políticasSe apenas um computador apresenta o problema, concentre a investigação nele.
Esse tipo de comparação é extremamente valioso.
Cenário 7 — Todos os computadores mostram “Sem Internet”
Agora o raciocínio muda.
Se vários dispositivos Windows apresentam o mesmo sintoma simultaneamente:
PC 1 → globo
PC 2 → globo
PC 3 → globoinvestigue primeiro algo compartilhado:
- roteador;
- DNS;
- firewall;
- proxy;
- filtro;
- operadora.
Se todos conseguem navegar normalmente, uma filtragem central pode estar bloqueando o endpoint do NCSI.
Cenário 8 — Somente um aplicativo diz estar offline
Exemplo:
Edge → funciona
Chrome → funciona
Aplicativo X → "Sem Internet"Nesse cenário, o problema pode estar:
- no próprio aplicativo;
- em proxy;
- em firewall;
- no estado de conectividade informado pelo Windows.
Se o programa consulta o estado do NCSI, uma inconsistência pode influenciar seu comportamento.
Por isso vale testar o estado geral do sistema antes de reinstalar o aplicativo.
Cenário 9 — O problema começou depois de instalar antivírus
Algumas suítes de segurança adicionam:
- filtros de rede;
- inspeção HTTPS;
- firewall próprio;
- controle DNS;
- proteção web.
Depois da instalação, o caminho pode se tornar:
Aplicativo
↓
Filtro de segurança
↓
RedeSe o problema começou exatamente nesse momento, investigue as regras da suíte.
Não conclua automaticamente que o antivírus é culpado.
Mas a coincidência temporal é uma pista importante.
Cenário 10 — NCSI falha somente com determinado roteador
Imagine:
Roteador A → normal
Roteador B → Sem InternetO computador é o mesmo.
Nesse caso, investigue diferenças como:
- DNS;
- filtragem;
- controle parental;
- firewall;
- proxy;
- rede convidada;
- isolamento;
- IPv6.
Um teste simples com outro roteador pode reduzir bastante o diagnóstico.
Cenário 11 — Rede Mesh apresenta comportamento diferente
Em redes Mesh, o problema pode variar dependendo de:
- nó utilizado;
- backhaul;
- DHCP;
- DNS;
- roaming;
- VLAN;
- isolamento de convidados.
Se o problema acontece apenas em um SSID específico, compare:
SSID principal
SSID convidadoRedes de convidados muitas vezes bloqueiam acessos específicos ou aplicam políticas diferentes.
Cenário 12 — Portal cativo que não abre
O usuário conecta a uma rede pública.
Aparece:
Sem Internetmas a página de autenticação não aparece.
Tente abrir:
http://www.msftconnecttest.com/connecttest.txtSe houver redirecionamento para uma página de login, o portal cativo está ativo.
Também é possível tentar abrir um endereço HTTP simples para forçar o redirecionamento.
O problema pode estar no portal, não no Windows.
Cenário 13 — DNS filtrado bloqueia apenas Microsoft
Alguns filtros DNS possuem regras agressivas.
Sintomas:
Google → abre
YouTube → abre
msftconnecttest.com → não resolveNesse caso:
nslookup www.msftconnecttest.compode revelar imediatamente o problema.
Compare com:
nslookup www.msftconnecttest.com 1.1.1.1Se o segundo resolver e o primeiro não, o DNS atual merece investigação.
Cenário 14 — IPv4 funciona, IPv6 apresenta falhas
Execute:
ping -4 www.microsoft.come:
ping -6 www.microsoft.comNão trate ausência de resposta isolada como prova definitiva.
Mas se vários testes mostrarem:
IPv4 → estável
IPv6 → falhandoinvestigue a configuração IPv6.
Pode haver:
- anúncio incorreto;
- rota defeituosa;
- problema no roteador;
- operadora;
- VPN.
Cenário 15 — Duas rotas padrão competindo
Execute:
Get-NetRoute -DestinationPrefix "0.0.0.0/0"Se houver múltiplas rotas, compare métricas e interfaces.
Exemplo:
Wi-Fi → rota padrão
Ethernet → rota padrão
VPN → rota padrãoNesse cenário, o Windows precisa decidir qual caminho utilizar.
Uma rota inesperada pode fazer a sondagem sair por uma interface que não possui conectividade completa.
Cenário 16 — Windows mostra globo por alguns segundos depois de conectar
Isso pode ser normal.
Existe um intervalo entre:
conectar à rede
↓
obter IP
↓
resolver DNS
↓
realizar teste
↓
atualizar estadoUm pequeno atraso não significa necessariamente defeito.
O problema merece investigação quando:
- demora muito;
- não se corrige;
- volta constantemente;
- aplicativos passam a falhar.
Tabela prática de diagnóstico do NCSI
| Sintoma | Causa provável | Primeiro teste |
|---|---|---|
| Wi-Fi conectado + 169.254.x.x | DHCP | ipconfig /all |
| Gateway não responde | Rede local | ping gateway |
| IP externo funciona, domínio não | DNS | nslookup |
| Sites abrem, NCSI falha | NCSI/Proxy/Firewall | Invoke-WebRequest |
| Só falha com VPN | Rota/DNS/VPN | route print |
| Só falha em um PC | Configuração local | comparar ipconfig /all |
| Falha em todos | Roteador/DNS/Firewall | testar outro DNS/rede |
| HTTP retorna página diferente | Portal cativo/proxy | abrir connecttest.txt |
| Problema após antivírus | Filtro/firewall | revisar logs |
| Após suspensão | Driver/reconexão | comparar configuração antes/depois |
Diagnóstico em menos de cinco minutos
Para uma verificação rápida, use esta sequência:
ipconfig /allDepois:
ping gatewayDepois:
nslookup www.msftconnecttest.comDepois:
Test-NetConnection www.msftconnecttest.com -Port 80Depois:
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Por fim:
netsh winhttp show proxySe o problema continuar, avance para:
route printe análise de eventos do NCSI.
Quando o problema realmente está no roteador?
Suspeite do roteador quando:
- vários computadores apresentam a falha;
- o DNS entregue via DHCP não funciona;
- IPv6 está inconsistente para todos;
- regras de segurança afetam vários dispositivos;
- trocar de rede resolve imediatamente.
Também verifique se o roteador possui:
- controle parental;
- filtragem DNS;
- firewall avançado;
- bloqueio de categorias;
- rede de convidados.
Em equipamentos de operadora, algumas dessas funções podem existir sem muita transparência para o usuário.
Quando o problema provavelmente está no Windows?
Suspeite mais do próprio computador quando:
- apenas uma máquina é afetada;
- outra máquina na mesma rede funciona;
- o problema começou após software específico;
- existe VPN;
- existem interfaces virtuais;
- existem políticas locais;
- proxy está configurado;
- eventos do NCSI mostram falha específica.
Nesse cenário, trocar o roteador pode ser perda de tempo.
Quando o problema pode estar na operadora?
Suspeite da operadora quando:
- diversos dispositivos perdem acesso externo;
- gateway local continua funcionando;
- DNS externo falha;
- rotas para fora da rede desaparecem;
- o modem/ONT indica falha WAN.
Nesse caso, o NCSI provavelmente está apenas mostrando corretamente que não existe acesso completo à Internet.
O NCSI não substitui diagnóstico de rede
É importante entender o papel correto do NCSI.
Ele ajuda o Windows a classificar a conectividade.
Mas ele não responde sozinho perguntas como:
- existe perda de pacote?
- existe latência alta?
- há bufferbloat?
- o Wi-Fi está fraco?
- existe congestionamento?
- o DNS está lento?
- o roteador está sobrecarregado?
Para isso precisamos de outras ferramentas.
Por exemplo:
ping
tracert
pathping
pktmon
Wireshark
Test-NetConnectionO NCSI é apenas uma peça do diagnóstico.
Conclusão
O ícone de globo do Windows 11 parece simples, mas por trás dele existe um mecanismo muito mais complexo do que a maioria dos usuários imagina.
O Windows não decide que existe Internet apenas porque:
Wi-Fi está conectadoEle avalia a conectividade usando mecanismos como o NCSI.
O sistema pode analisar:
- conectividade local;
- DNS;
- HTTP;
- IPv4;
- IPv6;
- estado das interfaces;
- sondagens ativas;
- sondagens passivas.
Na maior parte do tempo, tudo funciona de forma invisível.
O problema aparece quando algum componente interfere nesse processo.
Por exemplo:
DNS
proxy
VPN
firewall
portal cativo
política
filtro
rotaÉ aí que surge o comportamento aparentemente contraditório:
a Internet funciona, mas o Windows diz que não existe Internet.
A solução correta não é simplesmente esconder o aviso ou desativar o mecanismo.
O melhor caminho é identificar qual etapa falhou.
Comece sempre pelo básico:
IP
↓
gateway
↓
Internet
↓
DNS
↓
TCP
↓
HTTP
↓
NCSISó depois avance para:
proxy
VPN
políticas
rotas
eventos
captura de pacotesEsse método transforma um problema aparentemente aleatório em um diagnóstico lógico.
E essa é a principal vantagem de entender o NCSI:
o ícone deixa de ser apenas um símbolo e passa a ser uma pista técnica.
FAQ — NCSI no Windows 11
O que significa NCSI?
NCSI significa Network Connectivity Status Indicator. Ele participa da detecção do estado de conectividade do Windows.
O NCSI usa ping?
Não como método principal de decisão. O Windows utiliza sondagens específicas, incluindo testes HTTP.
O que é msftconnecttest.com?
É um domínio utilizado pela Microsoft no processo de teste de conectividade.
O arquivo connecttest.txt é vírus?
Não. Ele faz parte do mecanismo legítimo de teste de conectividade da Microsoft.
Por que o Windows mostra globo mesmo com Internet?
Porque o teste do NCSI pode falhar enquanto outros tipos de tráfego continuam funcionando.
DNS pode causar falso “Sem Internet”?
Sim. Se o sistema não conseguir resolver os nomes necessários ao teste, o estado pode ser afetado.
VPN interfere no NCSI?
Pode interferir, principalmente quando altera rotas, DNS, proxy ou firewall.
Pi-hole pode causar o problema?
Pode, caso uma lista de bloqueio impeça consultas ou acessos necessários ao teste.
Posso desativar o NCSI?
Tecnicamente existem políticas e configurações relacionadas às sondagens, mas não é recomendado desativar o mecanismo apenas para esconder um falso aviso.
O que é EnableActiveProbing?
É uma configuração relacionada à sondagem ativa utilizada pelo NCSI.
Colocar EnableActiveProbing em 0 resolve?
Não necessariamente. Pode apenas impedir o mecanismo de realizar determinado teste.
O NCSI testa IPv6?
O Windows pode testar conectividade por IPv4 e IPv6 quando ambos estão disponíveis.
O NCSI usa HTTPS?
A sondagem ativa documentada pela Microsoft utiliza HTTP no processo descrito para o Windows 11.
Por que usar HTTP?
Entre outros motivos, isso permite identificar situações em que uma rede intercepta a comunicação, como ocorre em portais cativos.
O que é portal cativo?
É uma rede que exige autenticação, aceitação de termos ou alguma interação antes de liberar acesso normal à Internet.
Como testar o endpoint do NCSI?
Use:
Invoke-WebRequest -Uri "http://www.msftconnecttest.com/connecttest.txt"Como testar DNS?
Use:
nslookup www.msftconnecttest.comComo testar a porta HTTP?
Use:
Test-NetConnection www.msftconnecttest.com -Port 80Como verificar proxy?
Use:
netsh winhttp show proxyComo verificar as rotas?
Use:
route printComo descobrir os adaptadores de rede?
Use:
Get-NetAdapterRedefinir a rede resolve NCSI?
Pode ajudar em casos de corrupção ou configuração inconsistente, mas não deve ser o primeiro procedimento.
Winsock reset resolve?
Pode ajudar em problemas específicos da pilha Winsock, mas não corrige, por exemplo, um firewall bloqueando o endpoint do NCSI.
O problema pode estar no roteador?
Sim, principalmente se vários dispositivos apresentarem o mesmo comportamento.
Um antivírus pode interferir?
Pode, especialmente se utilizar filtragem web, firewall, inspeção de tráfego ou DNS próprio.
Precisa de ajuda para descobrir por que o Windows mostra “Sem Internet”?
Se o seu computador mostra o ícone de globo, perde conectividade, apresenta DNS inconsistente ou funciona no navegador enquanto outros programas dizem estar offline, o problema pode estar em diferentes pontos da rede.
A VMIA realiza diagnóstico de:
- Windows 10 e Windows 11;
- Wi-Fi;
- rede cabeada;
- roteadores;
- DNS;
- DHCP;
- VPN;
- impressoras de rede;
- configurações de rede doméstica;
- problemas de conectividade.
O atendimento pode ser realizado por acesso remoto ou visita técnica, conforme o tipo de problema.
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
E-mail: suporte@vmia.com.br
Faça um comentário