Windows 11 perde o gateway padrão? Veja como diagnosticar

Windows 11 conectado à rede, mas sem Internet, com diagnóstico do gateway padrão usando ipconfig e Get-NetRoute
Windows 11 pode continuar conectado ao Wi-Fi mesmo quando existe um problema no gateway padrão ou na tabela de roteamento.
27 / 100 Pontuação de SEO

Um dos problemas de rede mais confusos no Windows 11 acontece quando tudo parece indicar que o computador continua conectado, mas a Internet simplesmente para de funcionar. O ícone do Wi-Fi permanece ativo, a conexão Ethernet continua estabelecida, o computador ainda possui um endereço IP e, em alguns casos, você consegue até acessar outros equipamentos da rede local. Mesmo assim, os sites deixam de abrir.

Nessa situação, reiniciar o roteador, trocar o DNS ou executar uma redefinição completa da rede pode até fazer a conexão voltar temporariamente. Porém, essas ações não necessariamente revelam a verdadeira causa do problema.

Uma possibilidade menos óbvia está no gateway padrão e na tabela de roteamento do Windows 11.

O computador pode continuar perfeitamente conectado à rede local e, ao mesmo tempo, perder a rota que informa ao sistema operacional para onde enviar os pacotes destinados à Internet.

É justamente por isso que compreender o gateway padrão pode transformar completamente a maneira como você diagnostica determinadas quedas de conexão.

Neste guia da VMIA, vamos investigar o que acontece quando o Windows 11 perde o gateway, como identificar esse comportamento e quais comandos ajudam a separar problemas de DHCP, roteamento, adaptadores virtuais, VPN, métricas de interface, drivers e configurações da placa de rede.

Mais importante: vamos seguir uma ordem lógica de diagnóstico.

Em vez de modificar várias configurações ao mesmo tempo, primeiro vamos descobrir em qual ponto a comunicação está falhando.


O que é o gateway padrão?

Imagine uma rede doméstica relativamente comum.

O computador recebeu estas configurações:

Endereço IPv4: 192.168.1.50
Máscara:        255.255.255.0
Gateway:        192.168.1.1
DNS:            192.168.1.1

O endereço 192.168.1.50 identifica o computador dentro dessa rede.

O endereço 192.168.1.1, neste exemplo, pertence ao roteador.

Quando o computador precisa conversar com outro equipamento pertencente à mesma sub-rede, normalmente não precisa enviar o tráfego ao gateway para que o roteador encaminhe esse tráfego para a Internet.

Mas imagine que você tente acessar um servidor cujo endereço seja:

8.8.8.8

Esse endereço não pertence à rede local 192.168.1.0/24.

O Windows precisa descobrir o que fazer com o pacote.

É nesse momento que a tabela de roteamento entra em ação.

Se nenhuma rota mais específica atender ao destino, o Windows normalmente utiliza a chamada rota padrão, que aponta para um próximo salto — geralmente o roteador da sua rede.

De maneira simplificada:

PC
192.168.1.50
     |
     v
Gateway
192.168.1.1
     |
     v
Internet

Portanto, possuir um endereço IP não significa automaticamente possuir acesso à Internet.

O computador precisa saber para onde encaminhar o tráfego que não pertence à rede local.


Estar conectado ao Wi-Fi não significa que a rota para a Internet está funcionando

Essa distinção é extremamente importante.

Quando o Windows mostra que o computador está conectado ao Wi-Fi, ele está indicando principalmente que existe uma associação com a rede sem fio e que a interface está ativa.

Isso não garante que todas as etapas seguintes estejam funcionando corretamente.

Podemos separar a comunicação, de maneira simplificada, assim:

Computador
     ↓
Adaptador Wi-Fi/Ethernet
     ↓
Rede local
     ↓
Gateway
     ↓
Operadora
     ↓
Internet

Uma falha pode acontecer em qualquer ponto.

Por isso, quando alguém diz:

“O Wi-Fi está conectado, mas não entra na Internet.”

a informação ainda é insuficiente para determinar a causa.

Precisamos descobrir até onde o computador consegue chegar.


Parte 1 — Descobrindo se o gateway realmente desapareceu

Antes de alterar qualquer configuração do Windows 11, precisamos confirmar o problema.

O primeiro comando é bastante conhecido:

ipconfig

Abra o Terminal ou Prompt de Comando e procure o adaptador que realmente está sendo utilizado.

Em uma conexão Ethernet, você poderá encontrar algo semelhante a:

Adaptador Ethernet Ethernet:

   Endereço IPv4. . . . . . . . . . : 192.168.1.50
   Máscara de Sub-rede . . . . . . . : 255.255.255.0
   Gateway Padrão. . . . . . . . . . : 192.168.1.1

Em uma conexão sem fio, procure o adaptador Wi-Fi.

O primeiro detalhe importante está no campo:

Gateway Padrão

Se ele estiver vazio quando deveria existir um gateway fornecido pela rede, já encontramos uma pista importante.

Mas não pare no ipconfig.

O Windows trabalha internamente com rotas, e precisamos verificar o que existe na tabela de roteamento.


Use route print para verificar a rota padrão

Execute:

route print

O resultado pode parecer complicado porque o Windows apresenta várias interfaces e rotas.

O ponto que nos interessa inicialmente está na tabela de rotas IPv4.

Procure uma entrada semelhante a:

Destino de rede    Máscara          Gateway        Interface       Métrica
0.0.0.0            0.0.0.0          192.168.1.1    192.168.1.50    25

A combinação:

0.0.0.0
0.0.0.0

representa a rota padrão IPv4.

Em termos simplificados, ela diz ao Windows:

Se não existir uma rota mais específica para o endereço de destino, envie o tráfego por este caminho.

Nesse exemplo, o próximo salto é:

192.168.1.1

Ou seja, o roteador.

Se o computador possui IP local válido, mas não existe uma rota padrão apropriada, ele pode continuar conversando com equipamentos da própria rede enquanto perde a capacidade normal de alcançar destinos externos.

Essa diferença fornece uma pista extremamente valiosa.


Um teste simples separa rede local de Internet

Vamos imaginar novamente:

PC:      192.168.1.50
Gateway: 192.168.1.1

Primeiro teste o próprio gateway:

ping 192.168.1.1

Se houver resposta, já sabemos que existe comunicação entre o computador e o roteador naquele momento.

Agora teste um endereço externo:

ping 8.8.8.8

Existem várias razões pelas quais um host pode não responder a ICMP, portanto um ping isolado não deve ser tratado como prova absoluta de indisponibilidade. Ainda assim, combinado com outros testes, ele ajuda bastante no diagnóstico.

Se o gateway responde, mas destinos externos deixam de funcionar, precisamos investigar o que acontece depois da rede local.

Agora existe outro cenário ainda mais interessante.

Imagine executar:

ping 192.168.1.1

e receber respostas normalmente.

Em seguida:

route print

e descobrir que não existe uma rota padrão IPv4 válida.

Isso ajuda a explicar por que a rede local continua funcionando enquanto o acesso externo apresenta problemas.


PowerShell oferece uma visão mais limpa das rotas

Para diagnósticos mais detalhados no Windows 11, podemos utilizar o PowerShell.

Execute:

Get-NetRoute

Como existem muitas rotas, podemos filtrar somente a rota padrão IPv4:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Um resultado típico pode conter informações como:

ifIndex DestinationPrefix NextHop      RouteMetric
------- ----------------- -------      -----------
12      0.0.0.0/0         192.168.1.1  0

O NextHop indica o próximo salto.

Neste exemplo:

192.168.1.1

Outro campo importante é o índice da interface, ifIndex.

Ele identifica qual adaptador está associado à rota.

Podemos relacionar essa informação aos adaptadores existentes usando:

Get-NetAdapter

Isso se torna especialmente útil em computadores que possuem várias interfaces.

Por exemplo:

Ethernet
Wi-Fi
VPN
Hyper-V
WSL
VirtualBox
VMware

Quanto mais interfaces existem, mais interessante fica analisar como o Windows escolhe suas rotas.


O computador pode possuir mais de um gateway padrão?

Sim.

E isso pode ser parte do problema.

Imagine um notebook conectado simultaneamente por Ethernet e Wi-Fi.

A tabela poderia possuir duas rotas:

0.0.0.0/0 → 192.168.1.1 → Ethernet
0.0.0.0/0 → 192.168.1.1 → Wi-Fi

Também podemos encontrar cenários como:

0.0.0.0/0 → roteador → Wi-Fi
0.0.0.0/0 → VPN → adaptador virtual

Nesse momento entra outro conceito importante:

Métrica

Quando existem diferentes caminhos possíveis, o Windows precisa decidir qual deles deve receber preferência.

As métricas fazem parte desse processo de seleção.

Você pode visualizar informações das interfaces com:

Get-NetIPInterface

Para concentrar a análise em IPv4:

Get-NetIPInterface -AddressFamily IPv4

Você poderá encontrar valores associados a interfaces como:

Ethernet
Wi-Fi
VPN

Uma métrica menor geralmente representa um caminho mais preferido, embora a seleção efetiva de rota também dependa da especificidade da rota e de outros elementos da tabela.

Isso significa que simplesmente encontrar duas rotas não prova que existe um problema.

Precisamos observar qual rota será escolhida para determinado destino.


Teste qual caminho o Windows realmente está utilizando

Outro comando bastante útil é:

tracert 8.8.8.8

O tracert tenta mostrar os saltos percorridos até o destino.

Em uma rede doméstica, o primeiro salto frequentemente será o roteador:

1    <1 ms    <1 ms    <1 ms    192.168.1.1

Isso confirma que o tráfego está sendo encaminhado inicialmente pelo gateway esperado.

Entretanto, roteadores e equipamentos intermediários podem limitar ou ignorar as respostas usadas pelo tracert. Portanto, a presença de asteriscos no resultado não significa automaticamente que aquele equipamento esteja com defeito.

O diagnóstico de rede precisa combinar evidências.

É justamente aí que muitos procedimentos dão errado: um único comando apresenta um resultado estranho e imediatamente recebe a culpa.


O teste que ajuda a diferenciar DNS de roteamento

Quando a Internet para de funcionar, muitas pessoas alteram imediatamente o DNS para servidores conhecidos.

Antes disso, faça uma comparação.

Teste:

ping 8.8.8.8

Depois:

ping google.com

Se um endereço IP externo funciona, mas nomes não são resolvidos, DNS passa a ser uma hipótese muito mais relevante.

Por outro lado, se o computador sequer possui uma rota adequada para alcançar redes externas, trocar o servidor DNS dificilmente corrigirá a causa principal.

Essa diferença evita uma quantidade enorme de tentativas aleatórias.


Verifique as configurações completas recebidas pelo DHCP

Execute:

ipconfig /all

Agora temos muito mais informações.

Procure:

DHCP Habilitado
Servidor DHCP
Endereço IPv4
Máscara de Sub-rede
Gateway Padrão
Servidores DNS
Concessão Obtida
Concessão Expira

Esses dados ajudam a responder uma pergunta fundamental:

o computador recebeu corretamente sua configuração de rede?

Em uma rede doméstica típica, o DHCP do roteador pode fornecer ao computador não apenas um endereço IP, mas também parâmetros importantes, como gateway e DNS.

Se o endereço IP foi obtido, mas o gateway esperado não aparece, precisamos investigar o DHCP e a configuração da rede.

Se tudo aparece corretamente no ipconfig /all, mas a rota desaparece posteriormente, a investigação muda de direção.

Agora precisamos descobrir:

quem está alterando a tabela de roteamento depois que o Windows já está conectado?

E essa pergunta nos leva aos casos mais interessantes deste diagnóstico.

VPNs, adaptadores virtuais, alterações de métrica, drivers, renovação DHCP e softwares que manipulam a pilha de rede podem modificar o comportamento do roteamento sem necessariamente desconectar fisicamente o Wi-Fi ou o cabo.

Na próxima parte, vamos investigar exatamente esses cenários e entender por que o gateway pode desaparecer, mudar de interface ou deixar de ser a rota preferencial no Windows 11.

Windows 11 perde o gateway padrão? Como descobrir por que a Internet cai mesmo com a rede conectada

Um dos problemas de rede mais confusos no Windows 11 acontece quando tudo parece indicar que o computador continua conectado, mas a Internet simplesmente para de funcionar. O ícone do Wi-Fi permanece ativo, a conexão Ethernet continua estabelecida, o computador ainda possui um endereço IP e, em alguns casos, você consegue até acessar outros equipamentos da rede local. Mesmo assim, os sites deixam de abrir.

Nessa situação, reiniciar o roteador, trocar o DNS ou executar uma redefinição completa da rede pode até fazer a conexão voltar temporariamente. Porém, essas ações não necessariamente revelam a verdadeira causa do problema.

Uma possibilidade menos óbvia está no gateway padrão e na tabela de roteamento do Windows 11.

O computador pode continuar perfeitamente conectado à rede local e, ao mesmo tempo, perder a rota que informa ao sistema operacional para onde enviar os pacotes destinados à Internet.

É justamente por isso que compreender o gateway padrão pode transformar completamente a maneira como você diagnostica determinadas quedas de conexão.

Neste guia da VMIA, vamos investigar o que acontece quando o Windows 11 perde o gateway, como identificar esse comportamento e quais comandos ajudam a separar problemas de DHCP, roteamento, adaptadores virtuais, VPN, métricas de interface, drivers e configurações da placa de rede.

Mais importante: vamos seguir uma ordem lógica de diagnóstico.

Em vez de modificar várias configurações ao mesmo tempo, primeiro vamos descobrir em qual ponto a comunicação está falhando.


O que é o gateway padrão?

Imagine uma rede doméstica relativamente comum.

O computador recebeu estas configurações:

Endereço IPv4: 192.168.1.50
Máscara:        255.255.255.0
Gateway:        192.168.1.1
DNS:            192.168.1.1

O endereço 192.168.1.50 identifica o computador dentro dessa rede.

O endereço 192.168.1.1, neste exemplo, pertence ao roteador.

Quando o computador precisa conversar com outro equipamento pertencente à mesma sub-rede, normalmente não precisa enviar o tráfego ao gateway para que o roteador encaminhe esse tráfego para a Internet.

Mas imagine que você tente acessar um servidor cujo endereço seja:

8.8.8.8

Esse endereço não pertence à rede local 192.168.1.0/24.

O Windows precisa descobrir o que fazer com o pacote.

É nesse momento que a tabela de roteamento entra em ação.

Se nenhuma rota mais específica atender ao destino, o Windows normalmente utiliza a chamada rota padrão, que aponta para um próximo salto — geralmente o roteador da sua rede.

De maneira simplificada:

PC
192.168.1.50
     |
     v
Gateway
192.168.1.1
     |
     v
Internet

Portanto, possuir um endereço IP não significa automaticamente possuir acesso à Internet.

O computador precisa saber para onde encaminhar o tráfego que não pertence à rede local.


Estar conectado ao Wi-Fi não significa que a rota para a Internet está funcionando

Essa distinção é extremamente importante.

Quando o Windows mostra que o computador está conectado ao Wi-Fi, ele está indicando principalmente que existe uma associação com a rede sem fio e que a interface está ativa.

Isso não garante que todas as etapas seguintes estejam funcionando corretamente.

Podemos separar a comunicação, de maneira simplificada, assim:

Computador
     ↓
Adaptador Wi-Fi/Ethernet
     ↓
Rede local
     ↓
Gateway
     ↓
Operadora
     ↓
Internet

Uma falha pode acontecer em qualquer ponto.

Por isso, quando alguém diz:

“O Wi-Fi está conectado, mas não entra na Internet.”

a informação ainda é insuficiente para determinar a causa.

Precisamos descobrir até onde o computador consegue chegar.


Descobrindo se o gateway realmente desapareceu

Antes de alterar qualquer configuração do Windows 11, precisamos confirmar o problema.

O primeiro comando é bastante conhecido:

ipconfig

Abra o Terminal ou Prompt de Comando e procure o adaptador que realmente está sendo utilizado.

Em uma conexão Ethernet, você poderá encontrar algo semelhante a:

Adaptador Ethernet Ethernet:

   Endereço IPv4. . . . . . . . . . : 192.168.1.50
   Máscara de Sub-rede . . . . . . . : 255.255.255.0
   Gateway Padrão. . . . . . . . . . : 192.168.1.1

Em uma conexão sem fio, procure o adaptador Wi-Fi.

O primeiro detalhe importante está no campo:

Gateway Padrão

Se ele estiver vazio quando deveria existir um gateway fornecido pela rede, já encontramos uma pista importante.

Mas não pare no ipconfig.

O Windows trabalha internamente com rotas, e precisamos verificar o que existe na tabela de roteamento.


Use route print para verificar a rota padrão

Execute:

route print

O resultado pode parecer complicado porque o Windows apresenta várias interfaces e rotas.

O ponto que nos interessa inicialmente está na tabela de rotas IPv4.

Procure uma entrada semelhante a:

Destino de rede    Máscara          Gateway        Interface       Métrica
0.0.0.0            0.0.0.0          192.168.1.1    192.168.1.50    25

A combinação:

0.0.0.0
0.0.0.0

representa a rota padrão IPv4.

Em termos simplificados, ela diz ao Windows:

Se não existir uma rota mais específica para o endereço de destino, envie o tráfego por este caminho.

Nesse exemplo, o próximo salto é:

192.168.1.1

Ou seja, o roteador.

Se o computador possui IP local válido, mas não existe uma rota padrão apropriada, ele pode continuar conversando com equipamentos da própria rede enquanto perde a capacidade normal de alcançar destinos externos.

Essa diferença fornece uma pista extremamente valiosa.


Um teste simples separa rede local de Internet

Vamos imaginar novamente:

PC:      192.168.1.50
Gateway: 192.168.1.1

Primeiro teste o próprio gateway:

ping 192.168.1.1

Se houver resposta, já sabemos que existe comunicação entre o computador e o roteador naquele momento.

Agora teste um endereço externo:

ping 8.8.8.8

Existem várias razões pelas quais um host pode não responder a ICMP, portanto um ping isolado não deve ser tratado como prova absoluta de indisponibilidade. Ainda assim, combinado com outros testes, ele ajuda bastante no diagnóstico.

Se o gateway responde, mas destinos externos deixam de funcionar, precisamos investigar o que acontece depois da rede local.

Agora existe outro cenário ainda mais interessante.

Imagine executar:

ping 192.168.1.1

e receber respostas normalmente.

Em seguida:

route print

e descobrir que não existe uma rota padrão IPv4 válida.

Isso ajuda a explicar por que a rede local continua funcionando enquanto o acesso externo apresenta problemas.


PowerShell oferece uma visão mais limpa das rotas

Para diagnósticos mais detalhados no Windows 11, podemos utilizar o PowerShell.

Execute:

Get-NetRoute

Como existem muitas rotas, podemos filtrar somente a rota padrão IPv4:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Um resultado típico pode conter informações como:

ifIndex DestinationPrefix NextHop      RouteMetric
------- ----------------- -------      -----------
12      0.0.0.0/0         192.168.1.1  0

O NextHop indica o próximo salto.

Neste exemplo:

192.168.1.1

Outro campo importante é o índice da interface, ifIndex.

Ele identifica qual adaptador está associado à rota.

Podemos relacionar essa informação aos adaptadores existentes usando:

Get-NetAdapter

Isso se torna especialmente útil em computadores que possuem várias interfaces.

Por exemplo:

Ethernet
Wi-Fi
VPN
Hyper-V
WSL
VirtualBox
VMware

Quanto mais interfaces existem, mais interessante fica analisar como o Windows escolhe suas rotas.


O computador pode possuir mais de um gateway padrão?

Sim.

E isso pode ser parte do problema.

Imagine um notebook conectado simultaneamente por Ethernet e Wi-Fi.

A tabela poderia possuir duas rotas:

0.0.0.0/0 → 192.168.1.1 → Ethernet
0.0.0.0/0 → 192.168.1.1 → Wi-Fi

Também podemos encontrar cenários como:

0.0.0.0/0 → roteador → Wi-Fi
0.0.0.0/0 → VPN → adaptador virtual

Nesse momento entra outro conceito importante:

Métrica

Quando existem diferentes caminhos possíveis, o Windows precisa decidir qual deles deve receber preferência.

As métricas fazem parte desse processo de seleção.

Você pode visualizar informações das interfaces com:

Get-NetIPInterface

Para concentrar a análise em IPv4:

Get-NetIPInterface -AddressFamily IPv4

Você poderá encontrar valores associados a interfaces como:

Ethernet
Wi-Fi
VPN

Uma métrica menor geralmente representa um caminho mais preferido, embora a seleção efetiva de rota também dependa da especificidade da rota e de outros elementos da tabela.

Isso significa que simplesmente encontrar duas rotas não prova que existe um problema.

Precisamos observar qual rota será escolhida para determinado destino.


Teste qual caminho o Windows realmente está utilizando

Outro comando bastante útil é:

tracert 8.8.8.8

O tracert tenta mostrar os saltos percorridos até o destino.

Em uma rede doméstica, o primeiro salto frequentemente será o roteador:

1    <1 ms    <1 ms    <1 ms    192.168.1.1

Isso confirma que o tráfego está sendo encaminhado inicialmente pelo gateway esperado.

Entretanto, roteadores e equipamentos intermediários podem limitar ou ignorar as respostas usadas pelo tracert. Portanto, a presença de asteriscos no resultado não significa automaticamente que aquele equipamento esteja com defeito.

O diagnóstico de rede precisa combinar evidências.

É justamente aí que muitos procedimentos dão errado: um único comando apresenta um resultado estranho e imediatamente recebe a culpa.


O teste que ajuda a diferenciar DNS de roteamento

Quando a Internet para de funcionar, muitas pessoas alteram imediatamente o DNS para servidores conhecidos.

Antes disso, faça uma comparação.

Teste:

ping 8.8.8.8

Depois:

ping google.com

Se um endereço IP externo funciona, mas nomes não são resolvidos, DNS passa a ser uma hipótese muito mais relevante.

Por outro lado, se o computador sequer possui uma rota adequada para alcançar redes externas, trocar o servidor DNS dificilmente corrigirá a causa principal.

Essa diferença evita uma quantidade enorme de tentativas aleatórias.


Verifique as configurações completas recebidas pelo DHCP

Execute:

ipconfig /all

Agora temos muito mais informações.

Procure:

DHCP Habilitado
Servidor DHCP
Endereço IPv4
Máscara de Sub-rede
Gateway Padrão
Servidores DNS
Concessão Obtida
Concessão Expira

Esses dados ajudam a responder uma pergunta fundamental:

o computador recebeu corretamente sua configuração de rede?

Em uma rede doméstica típica, o DHCP do roteador pode fornecer ao computador não apenas um endereço IP, mas também parâmetros importantes, como gateway e DNS.

Se o endereço IP foi obtido, mas o gateway esperado não aparece, precisamos investigar o DHCP e a configuração da rede.

Se tudo aparece corretamente no ipconfig /all, mas a rota desaparece posteriormente, a investigação muda de direção.

Agora precisamos descobrir:

quem está alterando a tabela de roteamento depois que o Windows já está conectado?

E essa pergunta nos leva aos casos mais interessantes deste diagnóstico.


Por que o gateway pode desaparecer ou mudar no Windows 11?

Confirmar que a rota padrão desapareceu é apenas metade do diagnóstico.

Agora precisamos descobrir por que isso aconteceu.

Existem diferenças importantes entre estes cenários:

O roteador não forneceu um gateway
        ↓
O Windows não criou a rota esperada

e:

O Windows recebeu o gateway
        ↓
A rota foi criada
        ↓
Alguma coisa alterou o roteamento posteriormente

Os sintomas para o usuário podem parecer praticamente iguais.

A origem do problema, entretanto, pode ser completamente diferente.

Por isso, um bom diagnóstico deve comparar o estado da rede quando ela funciona com o estado encontrado no momento exato da falha.


1. DHCP: o gateway pode simplesmente não ter sido recebido corretamente

Em muitas redes domésticas, o computador não possui manualmente todas as informações necessárias para se comunicar.

Ele recebe esses parâmetros através do DHCP.

De maneira simplificada, o roteador pode fornecer:

  • endereço IPv4;
  • máscara de sub-rede;
  • gateway padrão;
  • servidores DNS;
  • período da concessão.

Isso significa que uma falha envolvendo DHCP pode produzir uma configuração incompleta.

Quando a conexão estiver com problema, execute:

ipconfig /all

Observe principalmente:

DHCP Habilitado
Servidor DHCP
Endereço IPv4
Gateway Padrão
Concessão Obtida
Concessão Expira

Se o gateway estiver ausente, não devemos concluir imediatamente que o Windows “apagou” a rota.

Pode ser que a interface simplesmente não tenha recebido corretamente essa informação.

Essa distinção muda completamente o diagnóstico.


2. Compare a configuração antes e depois da falha

Existe uma técnica simples que ajuda muito nesse tipo de problema intermitente.

Quando a Internet estiver funcionando, execute:

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

Depois:

route print > "%USERPROFILE%\Desktop\rotas-funcionando.txt"

Quando o problema acontecer novamente, repita os comandos usando nomes diferentes:

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

e:

route print > "%USERPROFILE%\Desktop\rotas-com-falha.txt"

Agora temos dois retratos da rede.

Um quando tudo estava normal.

Outro durante a falha.

Essa comparação pode revelar mudanças que passariam despercebidas.

Por exemplo:

FUNCIONANDO

IPv4:             192.168.1.50
Gateway:          192.168.1.1
Servidor DHCP:    192.168.1.1
Rota 0.0.0.0/0:   presente

Durante a falha:

COM PROBLEMA

IPv4:             192.168.1.50
Gateway:          vazio
Servidor DHCP:    192.168.1.1
Rota 0.0.0.0/0:   ausente

Agora existe uma evidência concreta.

Em outro computador, poderíamos encontrar:

Gateway:          192.168.1.1
Rota 0.0.0.0/0:   presente

nos dois momentos.

Nesse caso, procurar apenas pelo desaparecimento do gateway seria seguir a hipótese errada.


3. Renovar o DHCP pode ajudar no diagnóstico

Quando suspeitamos da configuração recebida pelo DHCP, podemos solicitar uma nova concessão.

Um procedimento conhecido utiliza:

ipconfig /release

seguido por:

ipconfig /renew

Existe um detalhe importante: o primeiro comando libera a configuração DHCP da interface. Portanto, a conexão pode ser interrompida durante o procedimento.

Depois da renovação, execute novamente:

ipconfig /all

e:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Agora observe se o gateway e a rota retornaram.

Se retornaram imediatamente após a renovação, isso representa uma pista.

Não significa automaticamente que “o DHCP está quebrado”, mas justifica investigar o roteador, o servidor DHCP, a concessão e o comportamento da interface.


4. Descubra se o problema acontece somente neste computador

Esse teste parece simples, mas possui enorme valor.

Quando a Internet cair no computador problemático, teste outro dispositivo conectado à mesma rede.

Pode ser:

Notebook 1 → sem Internet
Notebook 2 → Internet normal
Celular → Internet normal
Smart TV → Internet normal

Esse padrão direciona a investigação para o primeiro computador.

Agora considere:

Notebook → sem Internet
Celular → sem Internet
TV → sem Internet

Nesse cenário, investigar apenas a tabela de roteamento do Windows provavelmente não será suficiente.

O problema pode estar no roteador, na conexão WAN, na operadora ou em outro componente compartilhado da rede.

A regra é simples:

quanto mais dispositivos apresentam o mesmo sintoma simultaneamente, menor a probabilidade de a causa estar exclusivamente naquele computador.


5. VPN pode alterar completamente a tabela de roteamento

VPNs merecem atenção especial.

Ao estabelecer uma conexão VPN, o software pode adicionar rotas para determinar quais destinos devem utilizar o túnel.

Dependendo da configuração, podemos ter:

Internet comum
      ↓
Roteador

ou:

Internet
   ↓
VPN
   ↓
Adaptador virtual
   ↓
Interface física

Algumas VPNs trabalham com split tunneling.

Nesse modelo, somente determinados destinos passam pelo túnel.

Outras podem direcionar uma parcela muito maior do tráfego através da VPN.

Portanto, ao diagnosticar uma rota estranha, pergunte:

o problema começa depois que a VPN conecta ou desconecta?

Execute:

Get-NetAdapter

e depois:

Get-NetRoute -AddressFamily IPv4

Observe se surgem interfaces ou rotas relacionadas à VPN.

Uma comparação antes e depois de estabelecer o túnel pode revelar bastante.


6. Não conclua que a VPN é culpada apenas porque existe um adaptador virtual

Esse cuidado é importante.

É comum encontrar computadores com vários adaptadores virtuais instalados.

Por exemplo:

Ethernet
Wi-Fi
vEthernet
VPN
VMware
VirtualBox

A presença dessas interfaces não significa automaticamente que exista um conflito.

O que precisamos descobrir é:

alguma delas possui uma rota que interfere no destino que estamos tentando alcançar?

É uma abordagem muito melhor do que simplesmente desinstalar todos os componentes virtuais do computador.


7. Hyper-V, WSL e máquinas virtuais também criam interfaces

Ambientes de virtualização podem adicionar adaptadores virtuais ao Windows.

Um computador utilizado para desenvolvimento, laboratório ou máquinas virtuais pode possuir uma lista de interfaces bem maior do que um computador doméstico convencional.

Execute:

Get-NetAdapter

Em alguns ambientes você poderá encontrar interfaces como:

vEthernet
VMware Network Adapter
VirtualBox Host-Only Network

Essas interfaces atendem a finalidades específicas.

O problema começa quando uma configuração de rede, uma rota ou uma métrica interfere no tráfego que deveria utilizar outra interface.

Novamente, não devemos assumir conflito apenas pela existência do adaptador.

Precisamos examinar as rotas.


8. Descubra qual interface corresponde ao ifIndex

Execute:

Get-NetIPInterface -AddressFamily IPv4

Você poderá encontrar algo conceitualmente parecido com:

ifIndex  InterfaceAlias
-------  --------------
6        Ethernet
12       Wi-Fi
24       VPN
37       vEthernet

Agora execute:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Imagine receber:

ifIndex  DestinationPrefix  NextHop
-------  -----------------  -------
12       0.0.0.0/0          192.168.1.1
24       0.0.0.0/0          10.20.0.1

Agora sabemos que existem duas rotas padrão associadas a interfaces diferentes.

A pergunta deixa de ser:

“Por que existem duas rotas?”

e passa a ser:

“Qual delas o Windows prefere e por quê?”


9. A métrica ajuda o Windows a escolher o caminho

O Windows pode trabalhar com métricas de rota e de interface ao decidir entre caminhos equivalentes.

Podemos consultar informações com:

Get-NetIPInterface -AddressFamily IPv4

Alguns campos importantes incluem:

InterfaceAlias
InterfaceIndex
ConnectionState
AutomaticMetric
InterfaceMetric

Você pode encontrar, por exemplo:

Interface        Metric
Ethernet         10
Wi-Fi            35
VPN              5

Isso não deve ser interpretado isoladamente como:

“A VPN sempre vai ganhar.”

Primeiro, o sistema considera a correspondência da rota com o endereço de destino. Uma rota mais específica possui vantagem sobre uma rota menos específica.

Quando existem rotas equivalentes para o mesmo prefixo, as métricas ajudam a definir a preferência.

Essa distinção é importante porque impede uma interpretação errada da tabela.


10. Prefixo mais específico vem antes da rota padrão

Imagine estas rotas:

0.0.0.0/0
10.0.0.0/8
192.168.1.0/24

Se o destino for:

192.168.1.25

a rota:

192.168.1.0/24

é muito mais específica que:

0.0.0.0/0

Portanto, ela corresponde melhor ao destino.

A rota padrão funciona como um caminho para os destinos que não encontraram uma correspondência mais específica.

Essa lógica é fundamental para compreender por que olhar apenas a métrica pode levar a conclusões incorretas.


11. Veja todas as rotas padrão existentes

Uma maneira direta de fazer isso no PowerShell é:

Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
Sort-Object RouteMetric, InterfaceMetric

Agora podemos observar:

InterfaceIndex
NextHop
RouteMetric
InterfaceMetric

Se aparecer apenas uma rota, o cenário tende a ser mais simples.

Se aparecem várias, investigue a qual interface cada uma pertence.

Podemos cruzar os índices com:

Get-NetAdapter

e:

Get-NetIPInterface -AddressFamily IPv4

Esse cruzamento é muito mais informativo do que olhar apenas para o nome “Ethernet” ou “Wi-Fi”.


12. O cabo e o Wi-Fi podem estar ativos simultaneamente

Esse cenário é comum em notebooks.

O usuário trabalha normalmente no Wi-Fi e depois conecta um cabo Ethernet.

Agora existem duas interfaces ativas.

Em muitos casos, o Windows administra essa situação sem qualquer dificuldade.

Porém, durante um diagnóstico, vale verificar:

Get-NetIPConfiguration

Esse comando oferece uma visão bastante conveniente das configurações de rede.

Podemos observar:

InterfaceAlias
InterfaceIndex
IPv4Address
IPv4DefaultGateway
DNSServer

Isso ajuda a identificar rapidamente qual interface possui gateway e qual endereço está associado a ela.


13. Get-NetIPConfiguration é excelente para esse diagnóstico

Execute:

Get-NetIPConfiguration

Em um computador simples, podemos encontrar algo equivalente a:

InterfaceAlias       : Wi-Fi
InterfaceIndex       : 12
IPv4Address          : 192.168.1.50
IPv4DefaultGateway   : 192.168.1.1
DNSServer            : 192.168.1.1

Esse comando reúne informações que, em outros casos, precisaríamos procurar separadamente.

Se existirem várias interfaces, compare cada uma.

Pergunte:

  • qual possui endereço IPv4?
  • qual possui gateway?
  • qual está conectada?
  • qual corresponde à rota padrão?
  • existe algum adaptador virtual envolvido?

Essas perguntas transformam uma tabela aparentemente complicada em uma investigação organizada.


14. Quando a rota existe, mas aponta para o gateway errado

Nem todo problema envolve uma rota ausente.

Às vezes ela existe, mas o NextHop não corresponde ao roteador esperado.

Imagine:

Rede atual:          192.168.1.0/24
Roteador atual:      192.168.1.1

Mas encontramos:

0.0.0.0/0 → 192.168.0.1

Isso exige investigação.

Tal configuração pode ter diferentes origens, como uma configuração manual incorreta, software de rede, uma interface diferente ou alterações realizadas anteriormente.

Antes de modificar qualquer coisa, identifique a interface associada.

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Depois:

Get-NetIPConfiguration

O objetivo é compreender de onde aquela rota veio.


15. Configuração manual de IPv4 também pode provocar o problema

Existe outro cenário clássico.

O computador originalmente utilizava DHCP.

Em algum momento alguém configurou manualmente:

IP:       192.168.1.50
Máscara:  255.255.255.0
Gateway:  192.168.1.1

Depois o computador foi levado para outra rede:

192.168.0.0/24

Agora a configuração antiga não corresponde ao ambiente atual.

Por isso, sempre confira:

ipconfig /all

e observe:

DHCP Habilitado

Se estiver:

Não

vale verificar se essa configuração manual realmente deveria existir.

Não altere automaticamente para DHCP, pois redes empresariais, equipamentos específicos e laboratórios podem utilizar configurações estáticas de propósito.

O diagnóstico precisa respeitar o ambiente.


16. O problema aparece depois da suspensão do notebook?

Esse detalhe muda bastante a investigação.

Imagine este padrão:

Liga o notebook
      ↓
Internet funciona
      ↓
Notebook entra em suspensão
      ↓
Usuário retorna
      ↓
Wi-Fi aparece conectado
      ↓
Internet não funciona

Agora temos uma correlação temporal.

O problema não acontece aleatoriamente.

Ele aparece depois de uma mudança de estado do equipamento.

Nesse caso, além da tabela de roteamento, devemos investigar:

  • driver do adaptador;
  • gerenciamento de energia;
  • reconexão Wi-Fi;
  • renovação DHCP;
  • estado da interface;
  • software VPN;
  • filtros instalados na pilha de rede.

Antes de alterar qualquer configuração, capture novamente:

ipconfig /all

e:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Faça isso antes e depois da suspensão.

Esse tipo de comparação costuma produzir evidências muito melhores.


17. Driver de rede merece investigação quando o comportamento acompanha a interface

O driver faz a comunicação entre o Windows e o hardware da placa de rede.

Problemas relacionados ao driver podem causar sintomas variados, como reconexões, perda temporária da interface ou comportamento anormal depois de mudanças de energia.

Para visualizar os adaptadores:

Get-NetAdapter

Para obter mais detalhes:

Get-NetAdapter | Format-List Name, InterfaceDescription, Status, LinkSpeed, DriverInformation

Dependendo do adaptador e da versão do Windows, as informações apresentadas podem variar.

O importante é identificar:

Nome
Descrição
Estado
Velocidade do link
Informações do driver

Se o problema começou imediatamente após uma atualização de driver, isso também merece ser registrado como parte da investigação.


18. Não atualize ou reinstale o driver como primeira tentativa

Esse ponto merece destaque.

É comum transformar qualquer problema de rede em:

“Atualize o driver.”

Às vezes isso resolve.

Mas não é um diagnóstico.

Antes, tente registrar o estado da rede durante a falha.

Caso contrário, uma reinstalação pode fazer o problema desaparecer temporariamente e eliminar justamente as evidências que permitiriam entender a causa.

Primeiro:

ipconfig /all

Depois:

route print

Em seguida:

Get-NetAdapter

e:

Get-NetIPInterface -AddressFamily IPv4

Somente depois avance para alterações.


19. Uma rota pode ser adicionada manualmente

O Windows possui o comando route, que permite manipular a tabela de roteamento.

Por exemplo, existem comandos capazes de adicionar ou excluir rotas.

Porém, não é recomendável sair criando uma rota padrão manualmente apenas porque ela desapareceu.

Isso pode mascarar a verdadeira causa.

Se o DHCP deveria fornecer o gateway, mas não está fazendo isso corretamente, criar manualmente uma rota pode fazer a Internet voltar sem corrigir o problema original.

Além disso, uma configuração incorreta pode criar conflitos.

Para diagnóstico, prefira primeiro comandos de consulta:

route print

e:

Get-NetRoute

Alterar a tabela deve ocorrer somente quando você entende exatamente qual rota precisa existir e por quê.


20. Reiniciar o computador pode esconder a pista mais importante

Existe uma situação comum no suporte técnico:

Internet caiu
     ↓
Usuário reinicia o computador
     ↓
Internet volta
     ↓
Não sabemos o que aconteceu

Reiniciar não é necessariamente errado.

O problema é fazer isso antes de coletar informações.

Se o computador estiver acessível e não houver urgência em restabelecer a conexão imediatamente, aproveite o momento da falha.

Execute:

ipconfig /all
route print
Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Get-NetAdapter

Depois teste:

ping <endereço-do-gateway>

e um destino externo apropriado.

Só então reinicie, se necessário.

Agora o problema deixou uma espécie de “fotografia” técnica.


O padrão do defeito é tão importante quanto o defeito

Depois de coletar essas informações, tente descobrir quando a falha acontece.

Por exemplo:

Somente depois da suspensão?
Somente quando conecta a VPN?
Somente quando desconecta a VPN?
Somente no Wi-Fi?
Somente no cabo?
Depois de trocar de rede?
Depois de algumas horas?
Depois da renovação DHCP?
Depois de iniciar determinado programa?

Essa correlação reduz drasticamente o número de hipóteses.

Um gateway que desaparece sempre depois de uma suspensão representa um cenário.

Uma rota que muda sempre que uma VPN conecta representa outro.

Uma configuração que já chega sem gateway logo após obter endereço pelo DHCP representa outro completamente diferente.

O sintoma pode ser:

“Windows 11 conectado, mas sem Internet.”

O diagnóstico, entretanto, depende do momento em que a configuração deixa de funcionar.


Montando um diagnóstico completo sem sair redefinindo a rede

Até aqui já conseguimos determinar se o Windows possui uma rota padrão, qual gateway está associado a ela, qual interface participa do caminho e se VPNs ou adaptadores virtuais estão envolvidos.

Agora falta transformar essas informações em um procedimento prático de diagnóstico.

Na próxima parte, vamos montar uma sequência completa para situações reais, incluindo:

gateway responde, mas Internet não; gateway não responde; rota padrão desapareceu; existem duas rotas padrão; Wi-Fi e Ethernet competem; VPN altera a rota; DHCP não entrega gateway; e o problema volta depois da suspensão.

Também veremos quando comandos como ipconfig /renew, route print, Get-NetRoute, Get-NetIPConfiguration, tracert e testes de conectividade realmente ajudam — e quando uma “redefinição de rede” apenas apaga as pistas que precisávamos para encontrar a causa.

Windows 11 perde o gateway padrão? Como descobrir por que a Internet cai mesmo com a rede conectada

Um dos problemas de rede mais confusos no Windows 11 acontece quando tudo parece indicar que o computador continua conectado, mas a Internet simplesmente para de funcionar. O ícone do Wi-Fi permanece ativo, a conexão Ethernet continua estabelecida, o computador ainda possui um endereço IP e, em alguns casos, você consegue até acessar outros equipamentos da rede local. Mesmo assim, os sites deixam de abrir.

Nessa situação, reiniciar o roteador, trocar o DNS ou executar uma redefinição completa da rede pode até fazer a conexão voltar temporariamente. Porém, essas ações não necessariamente revelam a verdadeira causa do problema.

Uma possibilidade menos óbvia está no gateway padrão e na tabela de roteamento do Windows 11.

O computador pode continuar perfeitamente conectado à rede local e, ao mesmo tempo, perder a rota que informa ao sistema operacional para onde enviar os pacotes destinados à Internet.

É justamente por isso que compreender o gateway padrão pode transformar completamente a maneira como você diagnostica determinadas quedas de conexão.

Neste guia da VMIA, vamos investigar o que acontece quando o Windows 11 perde o gateway, como identificar esse comportamento e quais comandos ajudam a separar problemas de DHCP, roteamento, adaptadores virtuais, VPN, métricas de interface, drivers e configurações da placa de rede.

Mais importante: vamos seguir uma ordem lógica de diagnóstico.

Em vez de modificar várias configurações ao mesmo tempo, primeiro vamos descobrir em qual ponto a comunicação está falhando.


O que é o gateway padrão?

Imagine uma rede doméstica relativamente comum.

O computador recebeu estas configurações:

Endereço IPv4: 192.168.1.50
Máscara:        255.255.255.0
Gateway:        192.168.1.1
DNS:            192.168.1.1

O endereço 192.168.1.50 identifica o computador dentro dessa rede.

O endereço 192.168.1.1, neste exemplo, pertence ao roteador.

Quando o computador precisa conversar com outro equipamento pertencente à mesma sub-rede, normalmente não precisa enviar o tráfego ao gateway para que o roteador encaminhe esse tráfego para a Internet.

Mas imagine que você tente acessar um servidor cujo endereço seja:

8.8.8.8

Esse endereço não pertence à rede local 192.168.1.0/24.

O Windows precisa descobrir o que fazer com o pacote.

É nesse momento que a tabela de roteamento entra em ação.

Se nenhuma rota mais específica atender ao destino, o Windows normalmente utiliza a chamada rota padrão, que aponta para um próximo salto — geralmente o roteador da sua rede.

De maneira simplificada:

PC
192.168.1.50
     |
     v
Gateway
192.168.1.1
     |
     v
Internet

Portanto, possuir um endereço IP não significa automaticamente possuir acesso à Internet.

O computador precisa saber para onde encaminhar o tráfego que não pertence à rede local.


Estar conectado ao Wi-Fi não significa que a rota para a Internet está funcionando

Essa distinção é extremamente importante.

Quando o Windows mostra que o computador está conectado ao Wi-Fi, ele está indicando principalmente que existe uma associação com a rede sem fio e que a interface está ativa.

Isso não garante que todas as etapas seguintes estejam funcionando corretamente.

Podemos separar a comunicação, de maneira simplificada, assim:

Computador
     ↓
Adaptador Wi-Fi/Ethernet
     ↓
Rede local
     ↓
Gateway
     ↓
Operadora
     ↓
Internet

Uma falha pode acontecer em qualquer ponto.

Por isso, quando alguém diz:

“O Wi-Fi está conectado, mas não entra na Internet.”

a informação ainda é insuficiente para determinar a causa.

Precisamos descobrir até onde o computador consegue chegar.


Parte 1 — Descobrindo se o gateway realmente desapareceu

Antes de alterar qualquer configuração do Windows 11, precisamos confirmar o problema.

O primeiro comando é bastante conhecido:

ipconfig

Abra o Terminal ou Prompt de Comando e procure o adaptador que realmente está sendo utilizado.

Em uma conexão Ethernet, você poderá encontrar algo semelhante a:

Adaptador Ethernet Ethernet:

   Endereço IPv4. . . . . . . . . . : 192.168.1.50
   Máscara de Sub-rede . . . . . . . : 255.255.255.0
   Gateway Padrão. . . . . . . . . . : 192.168.1.1

Em uma conexão sem fio, procure o adaptador Wi-Fi.

O primeiro detalhe importante está no campo:

Gateway Padrão

Se ele estiver vazio quando deveria existir um gateway fornecido pela rede, já encontramos uma pista importante.

Mas não pare no ipconfig.

O Windows trabalha internamente com rotas, e precisamos verificar o que existe na tabela de roteamento.


Use route print para verificar a rota padrão

Execute:

route print

O resultado pode parecer complicado porque o Windows apresenta várias interfaces e rotas.

O ponto que nos interessa inicialmente está na tabela de rotas IPv4.

Procure uma entrada semelhante a:

Destino de rede    Máscara          Gateway        Interface       Métrica
0.0.0.0            0.0.0.0          192.168.1.1    192.168.1.50    25

A combinação:

0.0.0.0
0.0.0.0

representa a rota padrão IPv4.

Em termos simplificados, ela diz ao Windows:

Se não existir uma rota mais específica para o endereço de destino, envie o tráfego por este caminho.

Nesse exemplo, o próximo salto é:

192.168.1.1

Ou seja, o roteador.

Se o computador possui IP local válido, mas não existe uma rota padrão apropriada, ele pode continuar conversando com equipamentos da própria rede enquanto perde a capacidade normal de alcançar destinos externos.

Essa diferença fornece uma pista extremamente valiosa.


Um teste simples separa rede local de Internet

Vamos imaginar novamente:

PC:      192.168.1.50
Gateway: 192.168.1.1

Primeiro teste o próprio gateway:

ping 192.168.1.1

Se houver resposta, já sabemos que existe comunicação entre o computador e o roteador naquele momento.

Agora teste um endereço externo:

ping 8.8.8.8

Existem várias razões pelas quais um host pode não responder a ICMP, portanto um ping isolado não deve ser tratado como prova absoluta de indisponibilidade. Ainda assim, combinado com outros testes, ele ajuda bastante no diagnóstico.

Se o gateway responde, mas destinos externos deixam de funcionar, precisamos investigar o que acontece depois da rede local.

Agora existe outro cenário ainda mais interessante.

Imagine executar:

ping 192.168.1.1

e receber respostas normalmente.

Em seguida:

route print

e descobrir que não existe uma rota padrão IPv4 válida.

Isso ajuda a explicar por que a rede local continua funcionando enquanto o acesso externo apresenta problemas.


PowerShell oferece uma visão mais limpa das rotas

Para diagnósticos mais detalhados no Windows 11, podemos utilizar o PowerShell.

Execute:

Get-NetRoute

Como existem muitas rotas, podemos filtrar somente a rota padrão IPv4:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Um resultado típico pode conter informações como:

ifIndex DestinationPrefix NextHop      RouteMetric
------- ----------------- -------      -----------
12      0.0.0.0/0         192.168.1.1  0

O NextHop indica o próximo salto.

Neste exemplo:

192.168.1.1

Outro campo importante é o índice da interface, ifIndex.

Ele identifica qual adaptador está associado à rota.

Podemos relacionar essa informação aos adaptadores existentes usando:

Get-NetAdapter

Isso se torna especialmente útil em computadores que possuem várias interfaces.

Por exemplo:

Ethernet
Wi-Fi
VPN
Hyper-V
WSL
VirtualBox
VMware

Quanto mais interfaces existem, mais interessante fica analisar como o Windows escolhe suas rotas.


O computador pode possuir mais de um gateway padrão?

Sim.

E isso pode ser parte do problema.

Imagine um notebook conectado simultaneamente por Ethernet e Wi-Fi.

A tabela poderia possuir duas rotas:

0.0.0.0/0 → 192.168.1.1 → Ethernet
0.0.0.0/0 → 192.168.1.1 → Wi-Fi

Também podemos encontrar cenários como:

0.0.0.0/0 → roteador → Wi-Fi
0.0.0.0/0 → VPN → adaptador virtual

Nesse momento entra outro conceito importante:

Métrica

Quando existem diferentes caminhos possíveis, o Windows precisa decidir qual deles deve receber preferência.

As métricas fazem parte desse processo de seleção.

Você pode visualizar informações das interfaces com:

Get-NetIPInterface

Para concentrar a análise em IPv4:

Get-NetIPInterface -AddressFamily IPv4

Você poderá encontrar valores associados a interfaces como:

Ethernet
Wi-Fi
VPN

Uma métrica menor geralmente representa um caminho mais preferido, embora a seleção efetiva de rota também dependa da especificidade da rota e de outros elementos da tabela.

Isso significa que simplesmente encontrar duas rotas não prova que existe um problema.

Precisamos observar qual rota será escolhida para determinado destino.


Teste qual caminho o Windows realmente está utilizando

Outro comando bastante útil é:

tracert 8.8.8.8

O tracert tenta mostrar os saltos percorridos até o destino.

Em uma rede doméstica, o primeiro salto frequentemente será o roteador:

1    <1 ms    <1 ms    <1 ms    192.168.1.1

Isso confirma que o tráfego está sendo encaminhado inicialmente pelo gateway esperado.

Entretanto, roteadores e equipamentos intermediários podem limitar ou ignorar as respostas usadas pelo tracert. Portanto, a presença de asteriscos no resultado não significa automaticamente que aquele equipamento esteja com defeito.

O diagnóstico de rede precisa combinar evidências.

É justamente aí que muitos procedimentos dão errado: um único comando apresenta um resultado estranho e imediatamente recebe a culpa.


O teste que ajuda a diferenciar DNS de roteamento

Quando a Internet para de funcionar, muitas pessoas alteram imediatamente o DNS para servidores conhecidos.

Antes disso, faça uma comparação.

Teste:

ping 8.8.8.8

Depois:

ping google.com

Se um endereço IP externo funciona, mas nomes não são resolvidos, DNS passa a ser uma hipótese muito mais relevante.

Por outro lado, se o computador sequer possui uma rota adequada para alcançar redes externas, trocar o servidor DNS dificilmente corrigirá a causa principal.

Essa diferença evita uma quantidade enorme de tentativas aleatórias.


Verifique as configurações completas recebidas pelo DHCP

Execute:

ipconfig /all

Agora temos muito mais informações.

Procure:

DHCP Habilitado
Servidor DHCP
Endereço IPv4
Máscara de Sub-rede
Gateway Padrão
Servidores DNS
Concessão Obtida
Concessão Expira

Esses dados ajudam a responder uma pergunta fundamental:

o computador recebeu corretamente sua configuração de rede?

Em uma rede doméstica típica, o DHCP do roteador pode fornecer ao computador não apenas um endereço IP, mas também parâmetros importantes, como gateway e DNS.

Se o endereço IP foi obtido, mas o gateway esperado não aparece, precisamos investigar o DHCP e a configuração da rede.

Se tudo aparece corretamente no ipconfig /all, mas a rota desaparece posteriormente, a investigação muda de direção.

Agora precisamos descobrir:

quem está alterando a tabela de roteamento depois que o Windows já está conectado?


Por que o gateway pode desaparecer ou mudar no Windows 11?

Confirmar que a rota padrão desapareceu é apenas metade do diagnóstico.

Agora precisamos descobrir por que isso aconteceu.

Existem diferenças importantes entre estes cenários:

O roteador não forneceu um gateway
        ↓
O Windows não criou a rota esperada

e:

O Windows recebeu o gateway
        ↓
A rota foi criada
        ↓
Alguma coisa alterou o roteamento posteriormente

Os sintomas para o usuário podem parecer praticamente iguais.

A origem do problema, entretanto, pode ser completamente diferente.

Por isso, um bom diagnóstico deve comparar o estado da rede quando ela funciona com o estado encontrado no momento exato da falha.


1. DHCP: o gateway pode simplesmente não ter sido recebido corretamente

Em muitas redes domésticas, o computador não possui manualmente todas as informações necessárias para se comunicar.

Ele recebe esses parâmetros através do DHCP.

De maneira simplificada, o roteador pode fornecer:

  • endereço IPv4;
  • máscara de sub-rede;
  • gateway padrão;
  • servidores DNS;
  • período da concessão.

Isso significa que uma falha envolvendo DHCP pode produzir uma configuração incompleta.

Quando a conexão estiver com problema, execute:

ipconfig /all

Observe principalmente:

DHCP Habilitado
Servidor DHCP
Endereço IPv4
Gateway Padrão
Concessão Obtida
Concessão Expira

Se o gateway estiver ausente, não devemos concluir imediatamente que o Windows “apagou” a rota.

Pode ser que a interface simplesmente não tenha recebido corretamente essa informação.

Essa distinção muda completamente o diagnóstico.


2. Compare a configuração antes e depois da falha

Existe uma técnica simples que ajuda muito nesse tipo de problema intermitente.

Quando a Internet estiver funcionando, execute:

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

Depois:

route print > "%USERPROFILE%\Desktop\rotas-funcionando.txt"

Quando o problema acontecer novamente, repita os comandos usando nomes diferentes:

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

e:

route print > "%USERPROFILE%\Desktop\rotas-com-falha.txt"

Agora temos dois retratos da rede.

Um quando tudo estava normal.

Outro durante a falha.

Essa comparação pode revelar mudanças que passariam despercebidas.


3. Renovar o DHCP pode ajudar no diagnóstico

Quando suspeitamos da configuração recebida pelo DHCP, podemos solicitar uma nova concessão.

Um procedimento conhecido utiliza:

ipconfig /release

seguido por:

ipconfig /renew

Existe um detalhe importante: o primeiro comando libera a configuração DHCP da interface. Portanto, a conexão pode ser interrompida durante o procedimento.

Depois da renovação, execute novamente:

ipconfig /all

e:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Se o gateway e a rota retornarem imediatamente depois da renovação, temos uma pista importante.


4. Descubra se o problema acontece somente neste computador

Quando a Internet cair no computador problemático, teste outro dispositivo conectado à mesma rede.

Se somente um computador apresentar a falha, o problema provavelmente está mais próximo daquele equipamento.

Se todos perderem acesso simultaneamente, precisamos ampliar a investigação para roteador, conexão WAN ou operadora.


5. VPN pode alterar completamente a tabela de roteamento

VPNs podem criar rotas próprias.

Execute:

Get-NetAdapter

e:

Get-NetRoute -AddressFamily IPv4

Observe se aparecem interfaces virtuais e rotas associadas.

Se o problema surge imediatamente depois de conectar ou desconectar a VPN, essa correlação possui grande valor diagnóstico.


6. Hyper-V, WSL e máquinas virtuais também criam interfaces

Ambientes de virtualização frequentemente adicionam adaptadores virtuais.

O importante não é simplesmente encontrá-los, mas descobrir se alguma rota associada interfere no tráfego comum.

Use:

Get-NetIPInterface -AddressFamily IPv4

e:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Cruze o ifIndex das rotas com o índice das interfaces.


7. A métrica ajuda na seleção entre caminhos equivalentes

Execute:

Get-NetIPInterface -AddressFamily IPv4

Observe:

InterfaceAlias
InterfaceIndex
AutomaticMetric
InterfaceMetric

Rotas mais específicas continuam tendo prioridade sobre rotas menos específicas.

Quando duas rotas possuem o mesmo prefixo, as métricas ajudam na escolha.


8. Configuração manual pode ficar errada depois de trocar de rede

Se o computador utiliza IPv4 manual, vale conferir:

ipconfig /all

e verificar se:

DHCP Habilitado

aparece como Não.

Uma configuração estática correta em uma rede pode estar completamente errada em outra.


9. Problemas depois da suspensão apontam para outra classe de causas

Quando o defeito aparece sempre depois de suspensão ou hibernação, investigue:

  • driver;
  • gerenciamento de energia;
  • reconexão Wi-Fi;
  • renovação DHCP;
  • VPN;
  • estado das interfaces.

O ideal é capturar o estado antes e depois da suspensão.


10. Reiniciar cedo demais pode apagar a evidência

Antes de reiniciar, se possível, registre:

ipconfig /all
route print
Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Get-NetAdapter

Essa coleta aumenta muito a chance de descobrir a causa real.


Fluxo prático de diagnóstico quando o Windows 11 perde a Internet

Agora podemos organizar todo o processo em uma sequência lógica.

O objetivo não é executar vinte comandos aleatoriamente.

O objetivo é fazer cada teste responder uma pergunta.


Passo 1 — O adaptador continua conectado?

Comece com:

Get-NetAdapter

Observe o adaptador utilizado.

O estado esperado normalmente será:

Up

Se a interface aparece como desconectada, o problema precisa ser tratado antes do gateway.

Nesse momento, investigar rotas seria prematuro.


Passo 2 — O computador ainda possui endereço IPv4 válido?

Execute:

ipconfig

Procure o endereço IPv4.

Uma rede doméstica pode utilizar faixas como:

192.168.x.x
10.x.x.x
172.16.x.x até 172.31.x.x

Agora atenção a outro padrão:

169.254.x.x

Um endereço nessa faixa pode aparecer quando o Windows não consegue obter normalmente uma configuração IPv4 via DHCP e utiliza um endereço APIPA.

Nesse cenário, a falta de Internet não deve ser tratada apenas como “gateway perdido”.

Existe um problema anterior: a obtenção da configuração de rede.


Passo 3 — Existe gateway padrão?

Execute:

ipconfig /all

Procure:

Gateway Padrão

Se estiver vazio, registre essa informação.

Depois confirme a tabela:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Se não houver uma rota padrão IPv4 válida, temos uma forte evidência para explicar a incapacidade de alcançar redes externas.


Passo 4 — O gateway responde?

Supondo que o gateway seja:

192.168.1.1

teste:

ping 192.168.1.1

Agora podemos dividir o diagnóstico.

Cenário A: gateway não responde

Investigue:

  • conexão Wi-Fi;
  • cabo;
  • placa de rede;
  • roteador;
  • VLAN ou isolamento;
  • endereço IP incorreto;
  • máscara errada;
  • conflito de rede;
  • perda severa de pacotes.

Cenário B: gateway responde

A comunicação local até o roteador existe.

Continue.


Passo 5 — Um endereço externo responde?

Teste:

ping 8.8.8.8

Se funcionar, o computador consegue atingir pelo menos aquele destino externo usando IP.

Se nomes ainda não abrirem, DNS ganha força como hipótese.

Se não funcionar, continue investigando rota e conectividade externa.


Passo 6 — Teste resolução de nomes separadamente

Você pode usar:

nslookup google.com

Esse comando ajuda a verificar se existe resposta do serviço DNS configurado.

Se ping 8.8.8.8 funciona, mas nslookup google.com falha, o problema provavelmente está mais próximo da resolução de nomes do que da existência do gateway.

Essa separação evita trocar DNS quando o problema é roteamento e evita mexer em rotas quando o problema é apenas DNS.


Passo 7 — Verifique a rota padrão

Use:

route print

ou:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Confira:

DestinationPrefix
NextHop
InterfaceIndex
RouteMetric

Pergunte:

o NextHop é realmente o roteador esperado?

Se sim, continue.

Se não, precisamos descobrir qual interface criou aquela rota.


Passo 8 — Descubra qual adaptador está associado à rota

Use:

Get-NetIPInterface -AddressFamily IPv4

Compare o InterfaceIndex com o ifIndex da rota.

Podemos descobrir algo como:

12 → Wi-Fi
18 → Ethernet
24 → VPN
37 → vEthernet

Se a rota padrão problemática pertence à interface VPN, já temos outra direção de investigação.


Passo 9 — Existem várias rotas padrão?

Execute:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Se aparecer algo como:

0.0.0.0/0 → 192.168.1.1 → Wi-Fi
0.0.0.0/0 → 10.10.0.1 → VPN

analise:

  • índice da interface;
  • métrica da rota;
  • métrica da interface;
  • estado da VPN;
  • momento em que o problema começou.

Duas rotas não significam automaticamente erro.

O importante é descobrir qual caminho está sendo selecionado.


Passo 10 — Use tracert para observar o início do caminho

Execute:

tracert 8.8.8.8

Se o primeiro salto esperado é o roteador e ele aparece corretamente, isso reforça que o tráfego está sendo entregue ao gateway.

Se aparece outro primeiro salto relacionado a VPN ou rede virtual, investigue esse caminho.

Lembre-se: asteriscos no tracert não provam defeito isoladamente.


Cenário real 1 — Wi-Fi conectado, gateway ausente

Imagine:

IPv4:     192.168.1.80
Máscara:  255.255.255.0
Gateway:

E:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

não retorna uma rota padrão adequada.

Agora temos uma situação coerente:

Conexão local existe
       ↓
Endereço IPv4 existe
       ↓
Gateway não existe
       ↓
Rota padrão não existe
       ↓
Internet não funciona normalmente

Nesse caso, investigue DHCP e configuração da interface antes de alterar DNS.


Cenário real 2 — Gateway aparece no ipconfig, mas a Internet não funciona

Imagine:

IPv4:     192.168.1.50
Gateway:  192.168.1.1

O gateway responde:

ping 192.168.1.1

mas destinos externos não.

Agora verifique:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Se a rota existe e aponta corretamente para 192.168.1.1, a causa pode estar além do computador.

Pode envolver:

  • roteador sem acesso WAN;
  • falha da operadora;
  • regras de segurança;
  • VPN;
  • firewall;
  • filtragem;
  • outro problema de conectividade externa.

O gateway existir não significa que ele possui Internet.


Cenário real 3 — O problema aparece somente após conectar uma VPN

Antes da VPN:

0.0.0.0/0 → 192.168.1.1 → Wi-Fi

Depois da VPN:

0.0.0.0/0 → 10.8.0.1 → VPN

Se a conexão para de funcionar exatamente nesse momento, a investigação deve considerar as políticas e rotas criadas pelo software VPN.

Desconectar e reconectar apenas confirma uma correlação.

Para entender o motivo, compare as tabelas antes e depois.


Cenário real 4 — Ethernet e Wi-Fi estão ativos ao mesmo tempo

Execute:

Get-NetIPConfiguration

Imagine:

Ethernet
IPv4:    192.168.1.60
Gateway: 192.168.1.1

Wi-Fi
IPv4:    192.168.1.75
Gateway: 192.168.1.1

Agora consulte:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Pode haver uma rota associada a cada interface.

Esse cenário normalmente funciona, mas se houver métricas inadequadas ou comportamentos específicos de software, uma interface pode receber preferência inesperada.


Cenário real 5 — A Internet volta depois de ipconfig /renew

Esse comportamento não fecha o diagnóstico sozinho.

Ele apenas informa que uma renovação DHCP modificou o estado da rede.

O próximo passo é comparar:

ipconfig /all

antes e depois da renovação.

Observe se mudou:

  • endereço IPv4;
  • gateway;
  • servidor DHCP;
  • DNS;
  • período da concessão.

Depois compare:

route print

A pergunta importante é:

o que exatamente mudou quando a conexão voltou?


Cenário real 6 — Internet para depois da suspensão

Esse é um dos casos em que comparar estados ajuda bastante.

Antes de suspender:

Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Depois da retomada, quando ocorrer a falha:

Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Observe mudanças de:

  • endereço;
  • gateway;
  • interface;
  • rota;
  • métrica;
  • estado do adaptador.

Se a falha sempre acompanha a retomada, vale investigar também driver e gerenciamento de energia.


Quando usar redefinição de rede no Windows 11?

A redefinição de rede pode ser útil em determinados cenários, mas deve ficar mais para o final da investigação.

Ela pode remover e reinstalar adaptadores e redefinir componentes de rede.

O problema é que ela também pode eliminar configurações que ajudariam a explicar o defeito.

Por isso, antes de usar uma medida ampla, registre:

ipconfig /all
route print

e:

Get-NetAdapter
Get-NetIPConfiguration
Get-NetRoute

Assim, mesmo que a redefinição resolva o problema, você ainda terá dados do estado anterior.


E os comandos netsh winsock reset e netsh int ip reset?

Eles aparecem com frequência em tutoriais de Internet.

Podem ajudar em determinados problemas relacionados à pilha de rede, mas não devem virar resposta automática para qualquer queda de conexão.

Antes de executá-los, descubra:

  • existe IP?
  • existe gateway?
  • existe rota padrão?
  • o gateway responde?
  • existem rotas de VPN?
  • outro dispositivo funciona?

Se o gateway simplesmente não foi recebido pelo DHCP, redefinir Winsock não é a primeira hipótese lógica.

A ordem do diagnóstico importa.


Um procedimento rápido para salvar quando a Internet cair

Se você quiser uma sequência compacta para capturar o problema, execute:

ipconfig /all

Depois:

route print

Em seguida:

Get-NetAdapter
Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Depois teste o gateway:

ping 192.168.1.1

Troque o endereço pelo gateway real da sua rede.

E teste um destino externo:

ping 8.8.8.8

Por último:

tracert 8.8.8.8

Essa sequência já consegue separar uma grande quantidade de cenários.


O principal erro: procurar uma solução antes de identificar a camada da falha

Problemas de Internet no Windows 11 costumam gerar uma sequência de tentativas:

Troca DNS
Reinicia roteador
Atualiza driver
Reseta rede
Desinstala placa
Reinicia Windows

Alguma dessas ações pode funcionar.

Mas se você não sabe qual condição estava errada antes da mudança, não sabe exatamente o que resolveu.

Um diagnóstico melhor segue outra lógica:

Existe link?
↓
Existe IP?
↓
Existe gateway?
↓
Existe rota?
↓
O gateway responde?
↓
Existe conectividade externa?
↓
DNS funciona?
↓
Há outra interface interferindo?

Essa ordem transforma um problema aparentemente aleatório em um conjunto de perguntas objetivas.


Conclusão

Quando o Windows 11 permanece conectado ao Wi-Fi ou Ethernet, mas perde acesso à Internet, o problema não está necessariamente no sinal, no DNS ou na operadora.

Uma rota padrão ausente, incorreta ou associada a uma interface inesperada pode produzir exatamente esse tipo de comportamento.

O ponto mais importante é não confundir estar conectado à rede local com possuir um caminho válido até a Internet.

Comandos como:

ipconfig /all
route print
Get-NetRoute
Get-NetIPConfiguration
Get-NetIPInterface
Get-NetAdapter
tracert

permitem observar o que o Windows está realmente fazendo.

Quando a falha é intermitente, a melhor estratégia é capturar o estado da rede antes de reiniciar.

Compare o computador funcionando com o momento da falha.

Veja se o gateway desapareceu, se outra rota assumiu prioridade, se uma VPN criou um novo caminho ou se o DHCP deixou de entregar alguma informação.

Essa abordagem evita uma das maiores armadilhas do suporte técnico: corrigir o sintoma sem descobrir a causa.


FAQ — Gateway padrão e Internet no Windows 11

O que significa gateway padrão no Windows 11?

O gateway padrão normalmente representa o equipamento para o qual o Windows encaminha tráfego destinado a redes que não possuem uma rota mais específica. Em redes domésticas, geralmente corresponde ao roteador.

Como descobrir meu gateway padrão?

Execute:

ipconfig

ou:

ipconfig /all

Procure o campo Gateway Padrão no adaptador utilizado.

Como saber se o Windows possui uma rota padrão?

Execute:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Também é possível usar:

route print

e procurar uma rota com destino 0.0.0.0 e máscara 0.0.0.0.

Posso ter Internet sem gateway padrão IPv4?

Em um cenário IPv4 convencional, o computador normalmente precisa de uma rota apropriada para alcançar destinos externos. Redes que utilizam outros mecanismos ou IPv6 podem apresentar comportamentos diferentes.

Por que o gateway desaparece depois de algumas horas?

As possíveis causas incluem alterações de DHCP, reconexões de interface, drivers, VPNs, mudanças de estado de energia e softwares que modificam rotas. É importante comparar o estado antes e durante a falha.

Trocar DNS corrige gateway ausente?

Não. DNS resolve nomes para endereços. Se o computador não possui uma rota válida para alcançar redes externas, trocar DNS não corrige a ausência dessa rota.

O gateway responde ao ping, mas a Internet não funciona. O que significa?

Significa que existe comunicação local entre o computador e o gateway naquele momento. O problema pode estar depois do roteador, na rota utilizada, na conexão WAN, em uma VPN, em regras de segurança ou em outros elementos da conectividade.

Duas rotas padrão sempre causam problema?

Não. O Windows pode possuir várias interfaces e rotas. O que importa é verificar especificidade, métricas e qual rota será selecionada para o destino.

Uma VPN pode mudar o gateway?

Sim. VPNs podem criar interfaces virtuais e adicionar ou modificar rotas para direcionar tráfego através do túnel.

Hyper-V ou WSL podem interferir na rede?

Eles podem criar interfaces e redes virtuais. Isso não significa que causarão problemas automaticamente. A investigação deve verificar as rotas e interfaces envolvidas.

Vale a pena usar redefinição de rede?

Pode ser útil em determinados casos, mas é melhor capturar as informações de diagnóstico antes. Uma redefinição ampla pode fazer o problema desaparecer sem revelar a causa.

Devo criar uma rota padrão manualmente?

Somente se você souber exatamente por que ela precisa existir e qual configuração a rede exige. Criar uma rota manual apenas para “fazer funcionar” pode mascarar problemas de DHCP ou criar conflitos.


Precisa de ajuda para diagnosticar quedas de Internet no Windows 11?

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores, notebooks, redes Wi-Fi, roteadores, problemas de DHCP, IP, DNS, gateway, impressoras em rede e falhas de conectividade no Windows.

O atendimento pode ser realizado por acesso remoto ou visita técnica agendada, dependendo do problema.

VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291 – Vila Mariana – São Paulo – SP
Telefone e WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog técnico: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br

Se a Internet cai apenas em um computador, funciona e para depois de algum tempo ou apresenta comportamentos diferentes entre Wi-Fi e cabo, um diagnóstico da tabela de roteamento pode revelar muito mais do que simplesmente reiniciar o roteador.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*