Route Print no Windows 11 mostrando tabela de rotas IPv4, gateway, métricas, VPN e interfaces para diagnóstico de rede — Route Print permite visualizar a tabela de roteamento do Windows 11 e identificar quais gateways e interfaces serão usados para alcançar diferentes destinos de rede.

68 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Quando um computador possui apenas uma placa de rede conectada a um único roteador, parece simples imaginar por onde os dados estão passando.

O computador está conectado ao Wi-Fi.

O roteador está conectado à Internet.

Logo:

Computador
    ↓
Wi-Fi
    ↓
Roteador
    ↓
Internet

Mas o Windows 11 pode trabalhar simultaneamente com várias interfaces e diferentes caminhos de rede.

Um computador pode possuir:

Ethernet;
Wi-Fi;
VPN;
adaptadores virtuais;
Hyper-V;
máquinas virtuais;
interfaces criadas por programas;
diferentes gateways;
várias rotas configuradas.

Nesse cenário, surge uma pergunta importante:

como o Windows decide por onde enviar cada pacote?

A resposta está na tabela de roteamento.

E uma das maneiras mais simples de visualizá-la no Windows 11 é através do comando:

route print

Apesar de parecer um comando antigo e cheio de números difíceis de interpretar, route print continua extremamente útil para diagnóstico.

Ele pode ajudar a explicar situações como:

“Conectei a VPN e não consigo mais acessar a impressora.”

“Meu notebook está conectado ao cabo e ao Wi-Fi. Qual conexão ele está usando?”

“Consigo acessar a Internet, mas não consigo alcançar outro equipamento da rede.”

“O computador está enviando o tráfego para o gateway errado.”

“Quando conecto determinado adaptador, alguns sistemas deixam de funcionar.”

“Por que existe mais de uma rota 0.0.0.0?”

Neste guia vamos entender como o Windows escolhe uma rota, o significado de cada coluna apresentada pelo route print e como utilizar essas informações para localizar problemas reais.

O objetivo não é decorar comandos.

O objetivo é conseguir olhar para uma tabela de rotas e entender:

se eu tentar acessar determinado endereço IP, por onde o Windows tentará chegar até ele?

O que é uma rota de rede?

Uma rota é uma instrução utilizada pelo sistema operacional para decidir para onde enviar tráfego destinado a determinado endereço ou rede.

Podemos imaginar uma tabela de rotas como um conjunto de placas indicando caminhos.

Por exemplo:

Para chegar à rede 192.168.1.0/24
→ utilize a interface Wi-Fi

Para chegar à rede 10.0.0.0/8
→ utilize a VPN

Para qualquer outro endereço
→ envie para o roteador 192.168.1.1

O Windows consulta essas informações antes de decidir qual caminho utilizar.

Isso acontece constantemente.

Ao abrir um site, acessar uma impressora, conectar a um servidor ou utilizar um compartilhamento, o sistema precisa determinar como alcançar o endereço de destino.

O que é a tabela de roteamento?

A tabela de roteamento reúne as rotas conhecidas pelo computador.

Ela pode conter rotas:

criadas automaticamente;
relacionadas às interfaces;
fornecidas pela configuração da rede;
adicionadas por VPN;
configuradas manualmente;
persistentes;
relacionadas ao IPv4;
relacionadas ao IPv6.

Quando executamos:

route print

o Windows apresenta essas informações.

À primeira vista, a saída pode parecer complicada.

Mas quase toda interpretação começa com poucas perguntas:

Qual é o destino?

Qual máscara ou prefixo corresponde ao destino?

Existe gateway?

Qual interface será utilizada?

Qual é a métrica?

Depois que esses conceitos ficam claros, a tabela começa a fazer sentido.

Como executar Route Print no Windows 11

Abra:

Windows Terminal

ou:

Prompt de Comando

Digite:

route print

e pressione Enter.

Para simplesmente visualizar a tabela, normalmente não precisamos começar alterando nenhuma configuração.

O comando apresentará informações sobre interfaces e rotas do computador.

Uma saída IPv4 simplificada poderia lembrar:

Destino de rede    Máscara de rede    Gateway       Interface       Métrica

0.0.0.0            0.0.0.0            192.168.1.1   192.168.1.50    25

127.0.0.0          255.0.0.0          No vínculo    127.0.0.1       331

192.168.1.0        255.255.255.0      No vínculo    192.168.1.50    281

192.168.1.50       255.255.255.255    No vínculo    192.168.1.50    281

192.168.1.255      255.255.255.255    No vínculo    192.168.1.50    281

Os valores variam de computador para computador.

Não copie esses endereços como se fossem obrigatórios na sua rede.

Eles são apenas exemplos.

As cinco informações que você precisa entender

Em uma rota IPv4, concentre-se inicialmente nestes campos:

Destino de rede
Máscara de rede
Gateway
Interface
Métrica

Vamos entender cada um.

Destino de rede

A coluna de destino informa para qual endereço ou conjunto de endereços aquela rota pode ser utilizada.

Exemplo:

192.168.1.0

com máscara:

255.255.255.0

representa, de maneira tradicional, uma rede equivalente a:

192.168.1.0/24

Ela inclui os endereços pertencentes àquela faixa conforme a máscara.

Agora considere:

0.0.0.0

com:

0.0.0.0

Essa entrada possui um significado especial.

Ela representa a chamada:

rota padrão.

O que significa 0.0.0.0?

Uma entrada parecida com:

0.0.0.0    0.0.0.0    192.168.1.1

pode ser interpretada de forma simplificada como:

“Se nenhuma rota mais específica corresponder ao endereço de destino, utilize este caminho.”

É por isso que essa rota normalmente aponta para o gateway utilizado para alcançar outras redes, incluindo a Internet.

Em notação CIDR, ela corresponde a:

0.0.0.0/0

Esse /0 é extremamente importante.

Significa que a rota corresponde, em princípio, a qualquer endereço IPv4.

Mas isso não significa que ela sempre vence.

Esse detalhe é fundamental.

A rota padrão não vence uma rota mais específica

Imagine que temos:

0.0.0.0/0
→ gateway 192.168.1.1

10.20.0.0/16
→ VPN

Agora tentamos acessar:

10.20.5.50

O endereço combina tanto com:

0.0.0.0/0

quanto com:

10.20.0.0/16

Qual rota deve ser escolhida?

A mais específica.

Nesse exemplo:

10.20.0.0/16

é muito mais específica do que:

0.0.0.0/0

Portanto, o tráfego para:

10.20.5.50

deve seguir a rota específica, considerando a tabela e demais critérios aplicáveis.

Esse princípio é conhecido como:

longest prefix match.

Ou, de maneira mais simples:

a rota que descreve o destino com maior precisão tem prioridade sobre uma rota mais genérica.

Entendendo /0, /8, /16, /24 e /32

Em IPv4 podemos representar máscaras utilizando prefixos.

Por exemplo:

0.0.0.0/0

é extremamente genérica.

10.0.0.0/8

é mais específica.

10.20.0.0/16

é ainda mais específica.

10.20.30.0/24

é mais específica novamente.

10.20.30.40/32

representa uma rota extremamente específica para um único endereço IPv4.

Podemos imaginar:

/0
↓
/8
↓
/16
↓
/24
↓
/32

cada vez mais específico

Quanto maior o prefixo, mais bits do endereço precisam coincidir.

Exemplo prático de escolha de rota

Imagine estas rotas:

0.0.0.0/0
→ 192.168.1.1

10.0.0.0/8
→ VPN

10.20.0.0/16
→ 172.16.1.1

10.20.30.0/24
→ outra interface

Queremos acessar:

10.20.30.50

Esse endereço combina com todas as quatro rotas.

Mas:

10.20.30.0/24

é a correspondência mais específica.

Portanto, ela será considerada antes das rotas mais genéricas.

Esse conceito explica uma quantidade enorme de problemas envolvendo VPN.

O que é a máscara de rede?

No route print, muitas rotas IPv4 ainda aparecem utilizando máscaras no formato decimal.

Por exemplo:

255.255.255.0

Ela corresponde a:

/24

Outro exemplo:

255.255.0.0

corresponde a:

/16

255.255.255.255

corresponde a:

/32

A máscara determina quais bits fazem parte da identificação da rede utilizada para comparar o destino.

Não confunda máscara com gateway

Esse erro é comum para quem está começando.

Considere:

Destino:
192.168.1.0

Máscara:
255.255.255.0

Gateway:
No vínculo

Interface:
192.168.1.50

A máscara:

255.255.255.0

não é um equipamento.

Ela descreve quais endereços pertencem àquela correspondência de rota.

O gateway, quando necessário, indica o próximo salto utilizado para encaminhar o tráfego.

O que é o gateway?

Imagine:

Computador
192.168.1.50

Roteador
192.168.1.1

O computador quer acessar:

8.8.8.8

Esse endereço não pertence à rede local:

192.168.1.0/24

Então o computador precisa entregar o tráfego a um roteador capaz de encaminhá-lo para outra rede.

Normalmente:

192.168.1.1

Esse equipamento atua como próximo salto para aquela rota.

Na tabela podemos encontrar:

0.0.0.0
0.0.0.0
192.168.1.1

De forma simplificada:

destino desconhecido pela tabela específica
↓
rota padrão
↓
192.168.1.1

Gateway padrão não é necessariamente “o caminho de tudo”

Essa frase é muito importante.

Muitas pessoas aprendem:

“Gateway padrão é por onde passa todo o tráfego.”

Essa simplificação funciona para explicar redes básicas, mas pode gerar confusão em diagnósticos mais avançados.

O gateway da rota padrão será utilizado quando nenhuma rota mais específica tiver prioridade para aquele destino.

Se existir:

192.168.1.0/24
→ diretamente conectado

o computador não precisa mandar primeiro o tráfego destinado a outro dispositivo daquela mesma rede para o gateway.

Ele pode alcançar o dispositivo diretamente pela interface correspondente.

O que significa “No vínculo” ou “On-link”?

Dependendo do idioma e da apresentação do Windows, você pode encontrar uma indicação equivalente a:

On-link

ou uma tradução indicando que o destino está diretamente acessível pelo vínculo/interface.

Isso significa, de forma simplificada:

o Windows considera aquela rede diretamente alcançável pela interface.

Exemplo:

192.168.1.0
255.255.255.0
No vínculo
192.168.1.50

O Windows sabe que:

192.168.1.x

pode ser alcançado diretamente através da interface:

192.168.1.50

Não é necessário enviar primeiro o pacote ao gateway padrão.

Exemplo com uma impressora

Computador:

192.168.1.50/24

Impressora:

192.168.1.150/24

Roteador:

192.168.1.1

A tabela possui:

192.168.1.0/24
→ diretamente conectado

Ao acessar:

192.168.1.150

o computador percebe que o endereço pertence à mesma rede diretamente conectada.

O fluxo lógico é:

PC 192.168.1.50
        ↓
rede local
        ↓
impressora 192.168.1.150

O roteador não precisa atuar como gateway entre esses dois dispositivos apenas porque existe um gateway padrão configurado.

ARP entra nessa história

Se o destino IPv4 está na rede local diretamente alcançável, o computador precisa descobrir como entregar o quadro ao dispositivo correto na rede local.

É aí que mecanismos como ARP entram no processo.

Simplificando:

Quero falar com 192.168.1.150
↓
está na minha rede local
↓
qual endereço MAC corresponde a 192.168.1.150?
↓
ARP
↓
envio local

Por isso route print e:

arp -a

podem se complementar em determinados diagnósticos.

A tabela de rotas ajuda a descobrir por qual caminho o destino deve ser alcançado.

ARP ajuda em aspectos da resolução entre IPv4 e endereço de camada de enlace na rede local.

O que significa Interface?

A coluna:

Interface

ajuda a indicar por qual interface/endereço local o Windows utilizará aquela rota.

Imagine um notebook com:

Ethernet:
192.168.1.50

Wi-Fi:
192.168.1.60

Agora a escolha da rota começa a ficar mais interessante.

O computador possui dois caminhos físicos possíveis.

A tabela pode conter rotas relacionadas a ambos.

O problema clássico: Wi-Fi e cabo conectados

Imagine:

Ethernet
192.168.1.50

Wi-Fi
192.168.1.60

Ambos possuem acesso à Internet.

O usuário pergunta:

“Qual deles o Windows está usando?”

Não podemos responder apenas:

“Cabo sempre tem prioridade.”

Isso depende da configuração de interfaces, rotas e métricas.

Precisamos verificar.

Podemos começar com:

route print

E complementar com:

Get-NetIPInterface

O que é métrica?

A métrica é um valor utilizado na escolha entre rotas que competem dentro do processo de seleção.

Em termos simplificados:

quando temos rotas equivalentes em especificidade, a métrica ajuda o Windows a escolher a preferida.

Normalmente, menor custo/métrica é preferível.

Mas existe um erro frequente:

“O Windows sempre escolhe a rota com a menor métrica da tabela inteira.”

Não.

Primeiro precisamos considerar a correspondência mais específica com o destino.

Só depois faz sentido comparar custos entre rotas candidatas equivalentes.

Prefixo primeiro, métrica depois

Essa é uma das regras mais importantes deste artigo.

Imagine:

Rota A

0.0.0.0/0
Métrica: 5

Rota B

10.20.30.0/24
Métrica: 100

Queremos acessar:

10.20.30.50

Não devemos escolher automaticamente a rota A apenas porque:

5 < 100

A rota B possui uma correspondência muito mais específica:

/24

contra:

/0

Logo, ela possui prioridade pela especificidade para esse destino.

A métrica não deve ser interpretada isoladamente.

Por que essa confusão acontece?

Porque em redes domésticas normalmente vemos duas rotas padrão competindo.

Por exemplo:

0.0.0.0/0
→ Ethernet
Métrica menor

0.0.0.0/0
→ Wi-Fi
Métrica maior

Como ambas são:

/0

a especificidade é igual.

Agora a métrica realmente se torna decisiva.

É daí que vem a percepção:

menor métrica
=
rota escolhida

Mas isso só faz sentido depois de considerar a especificidade.

Exemplo: cabo e Wi-Fi

Imagine:

Ethernet
IP: 192.168.1.50
Gateway: 192.168.1.1

Wi-Fi
IP: 192.168.1.60
Gateway: 192.168.1.1

A tabela pode possuir duas rotas padrão.

Simplificando:

0.0.0.0/0
→ Ethernet
Métrica 20

0.0.0.0/0
→ Wi-Fi
Métrica 45

Como ambas correspondem igualmente ao destino:

/0

a rota de menor custo tende a ser preferida.

Nesse exemplo:

Ethernet

Mas não assuma.

Confira a configuração real.

Métrica da rota e métrica da interface

Existe mais um detalhe importante.

No Windows, a escolha envolve custos associados às rotas e interfaces.

Por isso, simplesmente olhar um único número sem compreender a origem pode causar interpretações erradas.

O PowerShell ajuda bastante nessa investigação.

Execute:

Get-NetIPInterface

Você poderá visualizar informações como:

InterfaceAlias
AddressFamily
InterfaceMetric
ConnectionState

Isso permite entender melhor como cada interface participa do processo.

Automatic Metric

O Windows pode utilizar cálculo automático de métrica para interfaces.

Isso permite que o sistema atribua valores com base em características da conexão.

Na maioria das redes domésticas, não existe motivo para sair alterando métricas manualmente apenas porque encontramos dois valores diferentes.

Primeiro precisamos descobrir se existe realmente um problema.

Não altere a métrica só porque o Wi-Fi está maior

Imagine:

Ethernet: 25
Wi-Fi: 50

Isso não representa um erro por si só.

Pode ser exatamente o comportamento desejado.

Se a Ethernet está conectada e possui um caminho preferencial para a Internet, faz sentido que o sistema utilize esse caminho.

Alterar valores aleatoriamente pode criar um problema que antes não existia.

Route Print mostra as interfaces

No início da saída podemos encontrar uma lista de interfaces.

Algo parecido com:

Lista de interfaces

seguida de identificadores e adaptadores.

Isso é importante porque rotas podem estar associadas a índices de interface.

Para obter uma visualização mais amigável, podemos complementar com PowerShell:

Get-NetAdapter

Get-NetIPInterface

Assim conseguimos relacionar:

índice
↓
adaptador
↓
IP
↓
métrica
↓
rota

Get-NetRoute: o equivalente moderno para investigação

Embora route print seja excelente para uma visão geral, o PowerShell possui:

Get-NetRoute

Esse cmdlet permite consultar rotas de maneira estruturada.

Por exemplo:

Get-NetRoute -AddressFamily IPv4

Podemos encontrar propriedades como:

DestinationPrefix
NextHop
InterfaceIndex
RouteMetric

Isso facilita bastante filtros e automações.

Route Print ou Get-NetRoute?

Não precisamos escolher apenas um.

Para diagnóstico manual:

route print

é excelente porque apresenta rapidamente uma visão geral.

Para análise estruturada:

Get-NetRoute

é muito poderoso.

Podemos pensar:

route print
→ visão geral rápida

Get-NetRoute
→ investigação estruturada

As ferramentas se complementam.

Como visualizar apenas IPv4 com Route

Podemos utilizar:

route print -4

Isso reduz a saída quando nosso diagnóstico envolve somente IPv4.

Para IPv6:

route print -6

Essa separação facilita bastante a leitura.

Por que IPv6 aparece no Route Print?

O Windows 11 trabalha nativamente com IPv6.

Portanto, a tabela também pode possuir rotas como:

::/0

Essa é uma rota padrão IPv6.

Assim como:

0.0.0.0/0

representa a rota padrão IPv4, temos:

::/0

no IPv6.

Não desative IPv6 apenas porque a tabela parece complicada.

Primeiro entenda qual protocolo está sendo utilizado no problema investigado.

IPv4 e IPv6 podem utilizar caminhos diferentes

Imagine um nome:

servidor.exemplo

Ele pode possuir:

A
→ IPv4

AAAA
→ IPv6

Dependendo da conectividade e das políticas de seleção de endereços, o comportamento observado pode envolver IPv6.

Isso explica situações nas quais o técnico olha apenas:

route print -4

e não encontra a explicação completa.

Quando necessário, consulte também:

route print -6

O que são rotas persistentes?

Na saída do route print, podemos encontrar uma área relacionada a rotas persistentes.

Uma rota persistente é configurada para permanecer disponível após reinicializações, conforme a configuração utilizada.

Isso é diferente de determinadas rotas temporárias criadas dinamicamente.

Rotas persistentes podem ser úteis em ambientes específicos, mas também podem provocar problemas quando ficam esquecidas.

O perigo de uma rota antiga

Imagine que anos atrás alguém adicionou:

10.0.0.0/8
→ gateway específico

Depois a infraestrutura mudou.

A rota continua presente.

Agora um novo sistema utiliza:

10.50.20.30

O Windows pode continuar tentando utilizar aquele caminho antigo.

Para o usuário:

"Esse sistema não abre."

Para o técnico:

rota antiga está desviando o tráfego

É justamente por isso que route print pode revelar problemas difíceis de perceber.

VPNs adicionam rotas

Quando conectamos uma VPN, ela pode modificar a tabela de roteamento.

Dependendo da configuração, podem surgir rotas para:

redes corporativas

ou até uma nova rota padrão.

Exemplo:

Antes da VPN

0.0.0.0/0
→ roteador doméstico

Depois da VPN

0.0.0.0/0
→ VPN

ou:

10.0.0.0/8
→ VPN

Esses dois exemplos representam comportamentos bem diferentes.

Split tunnel e full tunnel

Em uma VPN podemos encontrar, de forma simplificada, dois modelos.

Split tunnel

Somente determinados destinos passam pela VPN.

Exemplo:

10.0.0.0/8
→ VPN

restante
→ Internet local

Full tunnel

Grande parte ou todo o tráfego pode ser direcionado através da VPN.

Exemplo simplificado:

0.0.0.0/0
→ VPN

Essa diferença pode explicar por que uma impressora ou outro dispositivo local deixa de funcionar quando a VPN é conectada.

Por que a impressora pode parar quando a VPN conecta?

Imagine:

PC:
192.168.1.50

Impressora:
192.168.1.150

Sem VPN:

192.168.1.0/24
→ interface Wi-Fi

Tudo funciona.

Depois a VPN conecta e altera:

rotas;
políticas;
firewall;
DNS;
acesso à LAN.

Agora a impressão falha.

O primeiro impulso costuma ser:

reinstalar impressora

Mas a impressora pode não ter absolutamente nada de errado.

Compare:

route print

antes e depois de conectar a VPN.

Essa comparação pode revelar uma mudança importante.

O método de comparação

Essa técnica é extremamente útil.

Execute:

route print

quando tudo funciona.

Depois reproduza a situação problemática.

Execute novamente:

route print

Agora compare:

ANTES
versus
DEPOIS

Procure:

novas rotas;
rota padrão diferente;
métricas diferentes;
interfaces diferentes;
rotas específicas adicionadas.

Essa técnica também funciona para adaptadores virtuais e outros softwares de rede.

Route Print e Test-NetConnection

Podemos combinar ferramentas.

Imagine que:

Test-NetConnection 192.168.1.150 -Port 9100

falha quando a VPN está conectada.

Observe na saída:

SourceAddress
InterfaceAlias

Depois consulte:

route print

Agora podemos perguntar:

Por qual rota o Windows está tentando alcançar 192.168.1.150?

Essa combinação é muito mais poderosa do que olhar cada ferramenta isoladamente.

Route Print e Tracert

Outra combinação interessante:

tracert destino

O route print mostra as decisões disponíveis localmente.

O tracert ajuda a observar o caminho percebido através dos saltos até o destino, dentro das limitações desse tipo de teste.

Podemos pensar:

route print
→ como o Windows pretende encaminhar

tracert
→ quais saltos conseguimos observar no caminho

Não são ferramentas equivalentes.

Route Print e Ping

Ping responde:

Existe resposta ICMP?

Route Print ajuda a responder:

Qual rota o Windows possui para alcançar o endereço?

Imagine:

ping 10.20.30.40

falhando.

Antes de culpar o servidor, pergunte:

Existe uma rota correta para 10.20.30.40?

Então:

route print -4

pode ser uma excelente próxima etapa.

Uma regra prática para começar a ler Route Print

Quando estiver investigando um endereço, faça isto:

1. Anote o IP de destino.

2. Procure a rota mais específica correspondente.

3. Observe o gateway/Next Hop.

4. Observe a interface.

5. Só então analise a métrica.

6. Verifique se existe uma rota ainda mais específica.

7. Compare com o comportamento esperado.

Essa ordem evita a maioria das interpretações erradas.

Exemplo completo

Queremos acessar:

10.20.30.50

Tabela simplificada:

0.0.0.0/0
→ 192.168.1.1
Métrica 20

10.0.0.0/8
→ VPN
Métrica 5

10.20.30.0/24
→ 192.168.1.254
Métrica 100

Qual rota corresponde melhor?

10.20.30.0/24

Não escolha:

10.0.0.0/8

apenas porque a métrica é menor.

O /24 é mais específico que /8.

Essa é a base para entender roteamento no Windows.

A pergunta que muda o diagnóstico

Em vez de perguntar:

“Por que a rede não funciona?”

pergunte:

“Qual rota o Windows está escolhendo para chegar a este endereço?”

Essa segunda pergunta pode ser investigada.

Temos:

destino
↓
prefixo
↓
gateway
↓
interface
↓
métrica

E podemos testar cada etapa.

É assim que route print deixa de parecer apenas uma tabela cheia de números e se transforma em uma poderosa ferramenta de diagnóstico.

Route Print na Prática: Wi-Fi, Ethernet, Métricas, VPN e Rotas Conflitantes

Na primeira parte deste guia, vimos que a tabela de roteamento funciona como um conjunto de instruções utilizadas pelo Windows 11 para decidir por onde determinado tráfego deve seguir.

Também estabelecemos uma regra fundamental:

rota mais específica
↓
depois critérios como métrica

Esse princípio precisa estar claro antes de começarmos a investigar situações mais complexas.

Agora vamos aplicar essa lógica a problemas reais.

Um dos mais comuns ocorre quando um notebook possui simultaneamente:

Wi-Fi
+
Ethernet

Outro aparece quando acrescentamos:

VPN

Nesse momento podemos ter três ou mais caminhos possíveis.

E a pergunta passa a ser:

qual deles o Windows está realmente utilizando para determinado destino?

Wi-Fi e Ethernet conectados ao mesmo tempo

Imagine um notebook conectado desta forma:

Ethernet:
192.168.1.50

Wi-Fi:
192.168.1.60

Gateway:
192.168.1.1

As duas interfaces possuem acesso à Internet.

O usuário abre o navegador.

Por onde os dados sairão?

Não devemos responder simplesmente:

“Sempre pelo cabo.”

É comum que a Ethernet seja preferida em muitas configurações, mas precisamos observar a tabela e as métricas reais.

Comece com:

route print -4

Procure as rotas padrão.

Podemos encontrar algo conceitualmente parecido com:

0.0.0.0    0.0.0.0    192.168.1.1    192.168.1.50    25

0.0.0.0    0.0.0.0    192.168.1.1    192.168.1.60    50

As duas rotas possuem o mesmo destino:

0.0.0.0/0

Portanto, possuem a mesma especificidade.

Agora a diferença de custo passa a ser importante.

No exemplo:

Ethernet → 25
Wi-Fi → 50

A rota Ethernet possui menor custo.

Como identificar cada interface corretamente

Não confie apenas nos endereços IP.

Use:

Get-NetIPInterface

Uma saída simplificada pode mostrar:

ifIndex  InterfaceAlias  AddressFamily  ConnectionState  InterfaceMetric

8        Ethernet        IPv4           Connected        5
12       Wi-Fi           IPv4           Connected        35

Agora conseguimos relacionar:

índice
+
nome
+
família de endereços
+
estado
+
métrica

Também podemos consultar:

Get-NetAdapter

para visualizar os adaptadores.

Por que o índice da interface é importante?

Diversos comandos do Windows utilizam:

InterfaceIndex

ou:

ifIndex

para identificar uma interface.

Imagine:

8 = Ethernet
12 = Wi-Fi
27 = VPN

Agora uma rota associada a:

InterfaceIndex 27

pode ser relacionada diretamente à VPN.

Isso facilita muito a leitura de tabelas complexas.

Get-NetRoute facilita a análise

Podemos consultar:

Get-NetRoute -AddressFamily IPv4

A saída é estruturada em objetos do PowerShell.

Campos importantes incluem:

DestinationPrefix
NextHop
InterfaceIndex
RouteMetric

Podemos filtrar apenas a rota padrão:

Get-NetRoute -AddressFamily IPv4 -DestinationPrefix "0.0.0.0/0"

Agora fica muito mais fácil identificar se existe mais de uma rota padrão.

Duas rotas padrão significam problema?

Não necessariamente.

Um computador com Wi-Fi e Ethernet conectados pode possuir duas rotas:

0.0.0.0/0
→ Ethernet

0.0.0.0/0
→ Wi-Fi

O Windows pode escolher uma delas com base nos custos associados.

A existência das duas entradas não representa, por si só, erro.

O problema aparece quando:

o caminho escolhido
≠
o caminho esperado

Um exemplo de problema real

Imagine:

Ethernet:
rede corporativa
sem Internet

Wi-Fi:
rede doméstica
com Internet

O usuário quer:

Ethernet → acessar servidor local
Wi-Fi → acessar Internet

Mas a Ethernet recebeu:

gateway padrão

e sua rota possui menor custo.

Agora o Windows pode tentar enviar tráfego genérico pela Ethernet.

Para o usuário:

“Quando conecto o cabo, minha Internet para.”

O Wi-Fi continua conectado.

O sinal está excelente.

O problema pode estar na tabela de rotas.

Como diagnosticar esse caso

Primeiro:

ipconfig /all

Observe:

IP da Ethernet;
IP do Wi-Fi;
gateways;
servidores DNS.

Depois:

route print -4

Procure:

0.0.0.0/0

Depois:

Get-NetIPInterface -AddressFamily IPv4

Agora conseguimos relacionar:

interface
↓
gateway
↓
rota padrão
↓
métrica

Não confunda DNS com rota

Imagine:

ping 8.8.8.8

funciona.

Mas:

ping exemplo.com

falha.

Nesse caso, existe uma boa razão para investigar DNS antes de concluir que a tabela de rotas está errada.

Podemos utilizar:

Resolve-DnsName exemplo.com

Uma regra útil é:

IP funciona
nome falha
↓
investigue resolução de nomes

Isso não é uma regra absoluta, mas reduz bastante o espaço de diagnóstico.

Não confunda firewall com rota

Outro cenário:

Test-NetConnection 192.168.1.100 -Port 445

retorna:

TcpTestSucceeded : False

Isso não significa automaticamente que a rota está errada.

Pode existir:

firewall;
serviço parado;
porta fechada;
ACL;
filtragem;
problema de rede;
rota incorreta.

Precisamos investigar.

O route print responde uma pergunta específica:

qual caminho o Windows possui para alcançar o destino?

Ele não informa sozinho se o serviço remoto está funcionando.

Como descobrir a rota para um destino específico

Suponha que queremos acessar:

10.20.30.50

Podemos consultar as rotas:

Get-NetRoute -AddressFamily IPv4

e procurar os prefixos correspondentes.

Mas existe uma forma ainda mais interessante de observar informações relacionadas à rota durante um teste:

Test-NetConnection 10.20.30.50 -DiagnoseRouting -InformationLevel Detailed

Esse modo pode fornecer informações úteis para diagnóstico de roteamento, permitindo observar elementos da seleção de rota realizada pelo Windows.

Dependendo da versão e do ambiente, a saída pode apresentar informações relacionadas a:

SelectedSourceAddress
OutgoingInterfaceIndex
SelectedNetRoute

Isso é extremamente útil.

Route Print mostra possibilidades; DiagnoseRouting ajuda no destino

Podemos pensar:

route print
↓
mostra a tabela

enquanto:

Test-NetConnection DESTINO -DiagnoseRouting

pode ajudar a investigar:

qual rota será selecionada para esse destino?

Essa combinação é excelente para troubleshooting.

Exemplo com servidor corporativo

Servidor:

10.20.30.50

O computador possui:

Wi-Fi
Ethernet
VPN

Execute:

Test-NetConnection 10.20.30.50 -DiagnoseRouting -InformationLevel Detailed

Agora observe qual interface e rota aparecem na seleção.

Se o servidor deveria ser acessado pela VPN, mas a rota escolhida aponta para a rede local, encontramos uma pista muito importante.

VPN: onde Route Print se torna extremamente útil

Conecte uma VPN e execute:

route print -4

Depois desconecte a VPN e execute novamente.

Compare.

Você pode descobrir que a VPN adicionou:

10.0.0.0/8

ou:

172.16.0.0/12

ou:

192.168.100.0/24

ou até modificou o caminho padrão.

Essas rotas dependem da configuração específica da VPN.

Exemplo de split tunnel

Imagine:

Rede doméstica:
192.168.1.0/24

Rede corporativa:
10.20.0.0/16

A tabela pode possuir:

0.0.0.0/0
→ 192.168.1.1

10.20.0.0/16
→ VPN

Agora:

google.com

tende a seguir a rota padrão local.

Enquanto:

10.20.30.50

combina com:

10.20.0.0/16

e segue pela VPN.

Esse é um exemplo simplificado de split tunnel.

Exemplo de full tunnel

Agora imagine que a VPN instala rotas que direcionam praticamente todo o tráfego para o túnel.

Conceitualmente:

Internet
↓
VPN
↓
rede corporativa
↓
saída corporativa

Dependendo da implementação, isso pode aparecer através de uma rota padrão ou de rotas que, em conjunto, cobrem grande parte do espaço de endereçamento.

Por isso não devemos procurar exclusivamente:

0.0.0.0/0

e concluir que entendemos toda a configuração da VPN.

O truque das duas metades da Internet

Algumas soluções podem utilizar rotas mais específicas para capturar praticamente todo o IPv4.

Por exemplo, conceitualmente:

0.0.0.0/1

128.0.0.0/1

Essas duas redes juntas cobrem o espaço IPv4.

E ambas são mais específicas do que:

0.0.0.0/0

Isso significa que olhar apenas para a rota padrão pode levar a uma conclusão errada.

Essa é uma das razões pelas quais precisamos procurar a rota mais específica para o destino, e não simplesmente perguntar qual é o gateway padrão.

Por que uma VPN pode usar /1?

Considere:

0.0.0.0/1

cobrindo aproximadamente a primeira metade do espaço IPv4.

128.0.0.0/1

cobrindo a outra metade.

Como:

/1

é mais específico do que:

/0

essas rotas podem ser preferidas para seus respectivos destinos, mesmo que a rota padrão local continue presente.

Esse é um excelente exemplo de por que:

“Minha rota 0.0.0.0 ainda aponta para o roteador, então a VPN não está levando minha Internet.”

pode ser uma conclusão incorreta.

Impressora para de funcionar quando VPN conecta

Agora vamos aplicar tudo isso a um caso muito comum.

Temos:

PC:
192.168.1.50

Impressora:
192.168.1.150

Roteador:
192.168.1.1

Sem VPN:

Test-NetConnection 192.168.1.150 -Port 9100

Resultado:

TcpTestSucceeded : True

Conectamos a VPN.

Agora:

Test-NetConnection 192.168.1.150 -Port 9100

retorna:

TcpTestSucceeded : False

Não reinstale imediatamente a impressora.

Primeiro compare as rotas

Sem VPN:

route print -4

Salve ou observe a saída.

Conecte a VPN.

Execute novamente:

route print -4

Procure rotas relacionadas a:

192.168.1.0/24

e outras que possam englobar:

192.168.1.150

Também observe:

interfaces;
métricas;
rotas mais específicas;
alterações criadas pela VPN.

Mas a rota local continua correta e mesmo assim não funciona

Isso também pode acontecer.

Se:

192.168.1.0/24
→ Wi-Fi

continua sendo a rota selecionada corretamente, o problema pode não ser roteamento.

Alguns clientes VPN possuem políticas que impedem acesso à LAN enquanto o túnel está ativo.

Nesse caso podemos ter:

rota correta
+
política bloqueando

Ou:

rota correta
+
firewall bloqueando

É exatamente por isso que não devemos tratar route print como ferramenta que responde tudo.

Como separar rota de bloqueio?

Utilize:

Test-NetConnection 192.168.1.150 -DiagnoseRouting -InformationLevel Detailed

Observe a rota selecionada.

Depois:

Test-NetConnection 192.168.1.150 -Port 9100

Se a seleção de rota parece correta, mas a conexão TCP falha, investigue:

política da VPN;
firewall;
isolamento;
filtros;
comportamento do túnel.

Se necessário, avançamos para captura.

Netsh Trace entra novamente

Esse é um ótimo exemplo de integração entre os artigos da VMIA.

Temos:

route print
↓
rota parece correta

Depois:

Test-NetConnection
↓
TCP falha

Agora:

Netsh Trace
↓
observar comunicação

Podemos iniciar uma captura direcionada para a impressora e reproduzir o problema.

Assim o diagnóstico evolui em etapas.

Rotas sobrepostas

Outro cenário importante ocorre quando duas redes se sobrepõem.

Imagine:

Rede local:
10.0.0.0/8

VPN:

10.20.0.0/16

Queremos acessar:

10.20.30.50

O endereço pertence tanto a:

10.0.0.0/8

quanto a:

10.20.0.0/16

A rota /16 é mais específica.

Portanto, ela deve ter prioridade sobre /8 para aquele destino.

E se a rede doméstica usar a mesma faixa da empresa?

Esse é um problema clássico.

Imagine:

Casa:
192.168.1.0/24

Empresa pela VPN:
192.168.1.0/24

Agora temos uma sobreposição real.

O endereço:

192.168.1.100

pode representar:

um servidor corporativo

e ao mesmo tempo existir:

um dispositivo doméstico

na mesma faixa.

Isso cria um conflito conceitual sério para roteamento.

Por que trocar a rede doméstica pode resolver?

Uma solução estrutural pode ser alterar a rede local para uma faixa que não conflite.

Por exemplo:

192.168.50.0/24

em vez de:

192.168.1.0/24

Mas não faça isso apenas por tentativa.

Primeiro confirme a sobreposição.

Use:

route print -4

e verifique as redes utilizadas pela VPN.

Rota /32

Uma rota:

10.20.30.50/32

corresponde especificamente a:

10.20.30.50

Imagine:

10.20.30.0/24
→ VPN A

mas:

10.20.30.50/32
→ VPN B

Para:

10.20.30.50

a rota /32 é mais específica.

Ela vence a /24, considerando a correspondência de prefixo.

Uma rota /32 esquecida pode causar um problema estranho

Imagine:

todos os servidores 10.20.30.x funcionam

exceto:

10.20.30.50

Esse tipo de sintoma merece uma pergunta:

Existe alguma rota específica /32 para esse endereço?

Execute:

Get-NetRoute -AddressFamily IPv4

e procure rotas extremamente específicas.

Uma única entrada pode explicar por que somente um endereço segue um caminho diferente.

Adaptadores virtuais

Programas podem criar interfaces de rede virtuais.

Exemplos incluem tecnologias relacionadas a:

VPN;
Hyper-V;
virtualização;
containers;
emuladores;
softwares de segurança.

Execute:

Get-NetAdapter

Você pode encontrar muito mais interfaces do que esperava.

Nem todas estarão ativas.

Nem todas participarão do roteamento atual.

Mas algumas podem adicionar rotas.

Hyper-V e switches virtuais

Quando Hyper-V entra na configuração, podemos encontrar:

vEthernet

e switches virtuais.

A topologia deixa de ser simplesmente:

Windows
↓
placa Ethernet

Podemos ter:

Windows
↓
adaptador virtual
↓
switch virtual
↓
adaptador físico

Dependendo da configuração.

Isso pode gerar novas interfaces e novas redes na tabela.

Não delete rotas só porque parecem estranhas

Essa regra é muito importante.

Você pode encontrar:

172.x.x.x
10.x.x.x
192.168.x.x

associadas a adaptadores virtuais.

Não conclua:

“Não conheço essa rota, vou apagar.”

Ela pode pertencer a:

Hyper-V;
VPN;
WSL;
virtualização;
software legítimo.

Primeiro identifique a interface.

Como relacionar rota e adaptador

Utilize:

Get-NetRoute -AddressFamily IPv4

Observe:

InterfaceIndex

Depois:

Get-NetAdapter

Compare o:

ifIndex

Agora você pode descobrir:

essa rota
↓
pertence a esta interface
↓
que pertence a este software/adaptador

Isso evita alterações perigosas.

Como verificar métricas das interfaces

Execute:

Get-NetIPInterface -AddressFamily IPv4

Observe:

InterfaceMetric

Você também pode selecionar campos para facilitar a leitura:

Get-NetIPInterface -AddressFamily IPv4 |
Select-Object ifIndex,InterfaceAlias,ConnectionState,InterfaceMetric

Agora a saída fica mais limpa.

Métrica automática

O Windows pode gerenciar automaticamente métricas de interface.

Antes de alterar valores, pergunte:

Existe realmente uma escolha errada?

Se não existe sintoma, não há motivo para modificar a configuração apenas para fazer a tabela “parecer bonita”.

Como testar se a interface mudou

Uma ferramenta muito útil é:

Test-NetConnection exemplo.com -Port 443 -InformationLevel Detailed

Observe informações como:

RemoteAddress
SourceAddress
InterfaceAlias

Agora conecte ou desconecte uma interface e repita.

Exemplo:

Antes

InterfaceAlias : Wi-Fi
SourceAddress  : 192.168.1.60

Depois

InterfaceAlias : Ethernet
SourceAddress  : 192.168.1.50

Temos evidência de mudança no caminho local utilizado pelo teste.

Gateway incorreto

Imagine:

PC:
192.168.1.50

Máscara:
/24

Gateway correto:
192.168.1.1

Mas a configuração contém:

192.168.1.254

Se esse endereço não representa um roteador funcional para o destino, a rota padrão pode levar o tráfego ao lugar errado.

Execute:

ipconfig /all

route print -4

Compare o gateway configurado com o gateway utilizado na rota padrão.

Testando o gateway

Podemos começar com:

ping 192.168.1.1

Mas lembre-se:

um equipamento pode não responder a ICMP e ainda funcionar como roteador.

Portanto, ausência de resposta ao Ping não prova sozinha que o gateway está indisponível.

Também podemos verificar:

arp -a

para observar informações ARP da rede local.

Quando o gateway funciona, mas a Internet não

Fluxo de teste:

IP local
↓
gateway
↓
IP externo
↓
DNS
↓
serviço

Exemplo:

ping 192.168.1.1

Depois:

ping 8.8.8.8

Depois:

Resolve-DnsName exemplo.com

Depois:

Test-NetConnection exemplo.com -Port 443

Cada teste responde uma pergunta diferente.

Como diferenciar rota de DNS

Cenário

8.8.8.8 funciona
exemplo.com não resolve

Investigue DNS.

Outro cenário

gateway funciona
8.8.8.8 não funciona

Agora roteamento ou conectividade externa ganha relevância.

Outro

8.8.8.8 funciona
exemplo.com resolve
porta 443 falha

Agora precisamos investigar TCP, firewall ou serviço.

Essa sequência evita culpar a rota por qualquer falha.

Como diferenciar rota de firewall

Imagine:

rota para 192.168.1.100
→ interface correta

Ping funciona.

Mas:

Test-NetConnection 192.168.1.100 -Port 445

falha.

A tabela de rotas pode estar perfeitamente correta.

Agora investigamos:

firewall do cliente;
firewall do servidor;
SMB;
serviço;
política de rede.

Se necessário:

Netsh Trace

ou:

Pktmon

podem aprofundar a análise.

Como diferenciar rota de serviço parado

Servidor:

192.168.1.100

A rota está correta.

O servidor responde.

Mas:

Test-NetConnection 192.168.1.100 -Port 3389

falha.

Talvez:

RDP não esteja escutando

ou exista bloqueio.

No servidor podemos investigar:

Get-NetTCPConnection -State Listen

Assim conectamos novamente as ferramentas.

Route Print não deve ser analisado sozinho

Uma metodologia melhor é:

ipconfig
↓
route print
↓
Get-NetIPInterface
↓
Get-NetRoute
↓
Test-NetConnection
↓
Resolve-DnsName
↓
tracert
↓
captura se necessário

Não precisamos executar tudo em todos os chamados.

Escolhemos conforme a pergunta.

Um método VMIA para problemas de rota

Quando suspeitar de roteamento no Windows 11:

1. Identifique o destino

Qual IP estou tentando acessar?

2. Descubra as interfaces

Get-NetAdapter

3. Descubra os IPs

ipconfig /all

4. Veja a tabela IPv4

route print -4

5. Procure a rota mais específica

Não comece pela métrica.

Comece pelo prefixo.

6. Identifique a interface

Use:

Get-NetIPInterface -AddressFamily IPv4

7. Analise o destino diretamente

Test-NetConnection DESTINO -DiagnoseRouting -InformationLevel Detailed

8. Teste a porta real do serviço

Test-NetConnection DESTINO -Port PORTA

9. Compare com e sem VPN

Quando o sintoma depender dela.

10. Capture somente se ainda houver dúvida

Use Netsh Trace ou outra ferramenta adequada.

Exemplo completo: “VPN conecta e a impressora desaparece”

Situação:

PC:
192.168.1.50

Impressora:
192.168.1.150

Porta:
TCP 9100

Sem VPN

Test-NetConnection 192.168.1.150 -Port 9100

Resultado:

True

Com VPN

Resultado:

False

Primeira pergunta:

A rota mudou?

Execute:

Test-NetConnection 192.168.1.150 -DiagnoseRouting -InformationLevel Detailed

Depois:

route print -4

Se a rota mudou:

investigue roteamento da VPN

Se não mudou:

investigue política/firewall da VPN

Esse é um diagnóstico muito mais preciso do que reinstalar a impressora.

Exemplo completo: “Internet para quando conecto o cabo”

Situação:

Wi-Fi:
Internet funcionando

Ethernet:
rede interna sem saída para Internet

Ao conectar Ethernet:

Internet para

Execute:

Get-NetRoute -AddressFamily IPv4 -DestinationPrefix "0.0.0.0/0"

Talvez encontremos:

Ethernet → rota padrão com menor custo
Wi-Fi → rota padrão com maior custo

Agora temos uma explicação plausível para o comportamento.

A solução deve considerar a configuração correta da rede, e não simplesmente desativar o Wi-Fi ou reinstalar o driver.

Exemplo completo: apenas um servidor não funciona

Rede:

10.20.30.0/24

Todos os servidores funcionam menos:

10.20.30.50

Antes de culpar o servidor:

Get-NetRoute -AddressFamily IPv4

Procure algo como:

10.20.30.50/32

Se existir uma rota específica apontando para outra interface, ela pode explicar por que apenas esse endereço segue caminho diferente.

Exemplo completo: rede doméstica conflita com VPN

Casa:

192.168.1.0/24

Empresa:

192.168.1.0/24

O servidor corporativo:

192.168.1.100

Mas existe também um equipamento local com endereço na mesma rede.

Agora a pergunta:

192.168.1.100 é local ou remoto pela VPN?

não pode ser respondida apenas pelo endereço.

A sobreposição precisa ser resolvida pela arquitetura de roteamento/VPN.

Esse tipo de conflito pode gerar comportamentos extremamente confusos.

O princípio mais importante continua o mesmo

Sempre comece pelo destino.

Se queremos alcançar:

10.20.30.50

não pergunte primeiro:

qual rota tem menor métrica?

Pergunte:

qual é a rota mais específica que corresponde a 10.20.30.50?

Depois analise:

gateway
interface
métrica

Essa ordem é a base para interpretar corretamente a tabela.

Route Print Avançado: Rotas Estáticas, Persistentes e Diagnóstico Completo no Windows 11

Nas duas primeiras partes deste guia, vimos como o Windows 11 lê a tabela de roteamento, como escolhe a rota mais específica e por que Wi-Fi, Ethernet e VPN podem mudar completamente o caminho utilizado pelos pacotes.

Agora vamos avançar para a parte mais delicada:

alterar a tabela de rotas.

Até aqui, o foco foi observar e diagnosticar.

Nesta parte, entraremos em comandos capazes de adicionar, modificar e remover rotas.

Por isso, existe uma regra importante:

não altere a tabela de roteamento apenas para testar hipóteses sem antes registrar como ela estava.

Uma rota incorreta pode derrubar acesso à Internet, servidores, VPN, impressoras ou outros equipamentos.

Antes de alterar qualquer rota, salve o estado atual

Execute:

route print -4

Se quiser guardar a saída em um arquivo:

route print -4 > C:\Logs\rotas-antes.txt

Também podemos registrar com PowerShell:

Get-NetRoute -AddressFamily IPv4 |
Sort-Object DestinationPrefix,RouteMetric |
Out-File C:\Logs\rotas-antes.txt

Assim temos uma referência para comparação.

O comando route

O utilitário route permite consultar e administrar rotas IPv4 e IPv6.

Podemos visualizar ajuda com:

route ?

Entre as operações mais conhecidas estão:

PRINT
ADD
DELETE
CHANGE

Essas operações devem ser utilizadas com cuidado.

Route Add

O comando:

route add

permite adicionar uma rota.

Imagine uma rede:

Rede local:
192.168.1.0/24

Gateway:
192.168.1.1

Outra rede:
10.20.30.0/24

Suponha que exista um roteador interno em:

192.168.1.254

capaz de alcançar:

10.20.30.0/24

Uma rota conceitual poderia ser:

route add 10.20.30.0 mask 255.255.255.0 192.168.1.254

Isso informa ao Windows:

Para alcançar 10.20.30.0/24
use o próximo salto 192.168.1.254

Mas isso só faz sentido se esse gateway realmente souber encaminhar o tráfego.

Adicionar uma rota não cria conectividade sozinho

Esse ponto é fundamental.

Se executarmos:

route add 10.20.30.0 mask 255.255.255.0 192.168.1.254

não estamos criando magicamente um caminho.

Estamos apenas dizendo ao Windows:

envie esse tráfego para 192.168.1.254

Para funcionar, esse equipamento precisa:

estar acessível;
atuar como roteador;
possuir rota para a rede remota;
permitir o tráfego;
possuir retorno adequado.

Roteamento precisa funcionar nos dois sentidos.

O problema da rota de volta

Imagine:

PC:
192.168.1.50

Servidor:
10.20.30.10

Gateway intermediário:
192.168.1.254

O PC envia corretamente:

192.168.1.50
↓
192.168.1.254
↓
10.20.30.10

Mas o servidor não sabe como responder para:

192.168.1.0/24

Agora temos:

ida funciona
volta falha

Para o usuário, a conexão simplesmente não funciona.

Esse é um excelente exemplo de por que uma rota no cliente não resolve tudo.

Route Add com métrica

Podemos definir uma métrica:

route add 10.20.30.0 mask 255.255.255.0 192.168.1.254 metric 20

Novamente, lembre-se:

métrica não substitui especificidade.

Essa rota:

10.20.30.0/24

continua mais específica que uma rota:

10.0.0.0/8

mesmo que a segunda possua uma métrica menor.

Rotas temporárias

Quando adicionamos uma rota normalmente, ela pode não sobreviver à reinicialização.

Isso é útil para testes.

Podemos criar uma rota temporária, validar o comportamento e depois reiniciar ou removê-la.

Essa estratégia é preferível a transformar imediatamente uma hipótese em configuração permanente.

Rotas persistentes

Para criar uma rota que permaneça após reinicializações, o comando route permite utilizar:

-p

Exemplo:

route -p add 10.20.30.0 mask 255.255.255.0 192.168.1.254

Agora a rota é criada como persistente.

Use isso somente quando existe uma necessidade real e documentada.

Por que rotas persistentes causam problemas anos depois?

Porque são fáceis de esquecer.

Imagine:

2023:
rede 10.20.30.0/24 precisava passar por 192.168.1.254

A infraestrutura muda.

Em 2026:

10.20.30.0/24 deveria passar por VPN

Mas o computador ainda possui:

10.20.30.0/24
→ 192.168.1.254

Como a rota é específica, ela pode continuar desviando o tráfego.

O usuário vê:

VPN conecta
mas servidor não abre

A causa pode ser uma rota persistente antiga.

Como identificar rotas persistentes

Execute:

route print

Procure a seção relacionada a rotas persistentes.

Também podemos utilizar PowerShell para investigar rotas e políticas de armazenamento.

Se encontrar uma rota desconhecida, antes de apagá-la pergunte:

Quem criou?
Quando?
Para qual rede?
Qual interface?
Qual software pode depender dela?

Route Delete

Para remover uma rota:

route delete

Exemplo:

route delete 10.20.30.0

Dependendo da existência de múltiplas entradas semelhantes, pode ser necessário fornecer parâmetros adicionais para identificar exatamente a rota desejada.

Por isso:

confira a tabela imediatamente antes de apagar.

Nunca remova a rota padrão sem entender o impacto

Uma rota como:

0.0.0.0/0

é crítica.

Apagá-la pode deixar o computador sem caminho para destinos externos.

Em um atendimento remoto, isso pode inclusive derrubar sua própria sessão.

Esse é um dos motivos pelos quais mudanças de roteamento exigem planejamento.

Cuidado ao trabalhar por acesso remoto

Imagine que você está conectado remotamente ao computador do cliente.

Você decide modificar:

rota padrão

ou:

interface utilizada

Se errar:

sessão remota cai

e você pode não conseguir reconectar.

Antes de fazer mudanças que podem derrubar conectividade:

tenha plano de retorno;
registre a configuração original;
faça mudanças pequenas;
prefira testes temporários;
evite alterações desnecessárias em gateway padrão.

Route Change

O comando:

route change

permite alterar determinados parâmetros de uma rota existente.

Porém, em diagnóstico, muitas vezes é mais seguro:

remover rota específica
↓
adicionar rota correta

do que tentar modificar uma entrada sem compreender completamente sua origem.

Cada alteração deve ser documentada.

Get-NetRoute

No PowerShell, podemos trabalhar com:

Get-NetRoute

Para IPv4:

Get-NetRoute -AddressFamily IPv4

Podemos selecionar propriedades importantes:

Get-NetRoute -AddressFamily IPv4 |
Select-Object DestinationPrefix,NextHop,InterfaceIndex,RouteMetric

Isso produz uma visualização muito mais objetiva.

Ordenando rotas

Uma tabela grande pode ficar confusa.

Podemos ordenar:

Get-NetRoute -AddressFamily IPv4 |
Sort-Object DestinationPrefix

Ou:

Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric

Mas cuidado:

ordenar por métrica serve apenas para visualização.

Não significa que a primeira rota da lista seja usada para todos os destinos.

Filtrando por interface

Imagine que queremos visualizar apenas rotas da interface 12:

Get-NetRoute -InterfaceIndex 12

Isso é excelente para investigar:

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

New-NetRoute

O PowerShell também possui:

New-NetRoute

Ele permite criar rotas de maneira estruturada.

Um exemplo conceitual:

New-NetRoute `
-DestinationPrefix "10.20.30.0/24" `
-InterfaceIndex 12 `
-NextHop "192.168.1.254"

Antes de executar algo desse tipo, confirme:

destino
interface
next hop
necessidade
rota de retorno

Nunca copie uma rota de outro computador sem adaptar ao ambiente.

Remove-NetRoute

Para remover uma rota específica via PowerShell existe:

Remove-NetRoute

Como esse comando pode alterar conectividade, revise o objeto que será removido antes de confirmar qualquer ação.

Uma boa prática é primeiro localizar:

Get-NetRoute -DestinationPrefix "10.20.30.0/24"

Somente depois decidir se a remoção realmente é necessária.

Não use Remove-NetRoute em filtros amplos

Evite comandos do tipo:

remover todas as rotas de determinada faixa

sem revisar o que corresponde ao filtro.

Em computadores com VPN, virtualização ou redes corporativas, várias rotas podem ser legítimas.

Como descobrir quem adicionou uma rota?

Nem sempre é possível olhar para uma entrada e saber imediatamente sua origem.

Podemos correlacionar com:

Get-NetAdapter

Get-NetIPInterface

Depois observar:

InterfaceIndex

Se a rota pertence a uma interface chamada:

VPN Empresa

já temos uma pista.

Se pertence a:

vEthernet

podemos investigar Hyper-V ou virtualização.

Rotas criadas por VPN não devem ser alteradas manualmente sem necessidade

Muitos clientes VPN adicionam e removem rotas dinamicamente.

Você pode executar:

route print -4

com VPN desligada e ligada.

Se as rotas aparecem somente durante a VPN, provavelmente fazem parte da política do cliente.

Apagar manualmente pode:

quebrar acesso corporativo;
ser revertido automaticamente;
violar política da empresa;
não resolver a causa.

Exemplo: VPN adiciona rota incorreta

Imagine:

Rede doméstica:
192.168.50.0/24

Rede corporativa:
10.20.0.0/16

A VPN deveria adicionar:

10.20.0.0/16
→ túnel

Mas por erro de configuração adiciona:

10.0.0.0/8
→ túnel

Agora diversos endereços privados:

10.x.x.x

seguem pela VPN.

Isso pode afetar equipamentos locais que utilizam a mesma faixa.

A solução correta pode estar na política da VPN, não em criar várias exceções no Windows.

Rotas IPv6

Assim como IPv4, o Windows mantém tabela de roteamento IPv6.

Podemos visualizar:

route print -6

Ou:

Get-NetRoute -AddressFamily IPv6

Uma rota importante é:

::/0

que representa a rota padrão IPv6.

Não ignore IPv6 em diagnósticos modernos

Imagine:

site abre em um computador
não abre em outro

Nos dois:

IPv4 parece correto

Mas o nome possui registro AAAA e um dos computadores está tentando IPv6.

Se a rota IPv6 ou conectividade estiver quebrada, o comportamento pode parecer estranho.

Use:

Resolve-DnsName exemplo.com

e observe registros:

A
AAAA

Depois:

route print -6

quando necessário.

Prefixos IPv6 seguem o mesmo princípio

A regra fundamental continua:

rota mais específica
vence rota menos específica

Por exemplo:

::/0

é genérica.

Uma rota:

2001:db8:1234::/48

é muito mais específica.

Não é necessário decorar todos os detalhes de IPv6 para entender esse princípio.

Como descobrir se o gateway é realmente o problema?

Vamos montar um diagnóstico.

PC:

192.168.1.50

Gateway:

192.168.1.1

Internet não funciona.

Primeiro:

ipconfig /all

Confirme IP, máscara e gateway.

Depois:

route print -4

Procure:

0.0.0.0/0
→ 192.168.1.1

Depois teste:

ping 192.168.1.1

Se responde, existe conectividade ICMP até o gateway.

Se não responde, ainda não podemos concluir sozinho que está indisponível.

Verifique ARP

Execute:

arp -a

Procure:

192.168.1.1

Se existe um endereço MAC associado, sabemos que houve resolução ARP recente para aquele IP.

Isso não prova funcionamento completo do roteador, mas fornece mais uma evidência.

Teste um destino externo por IP

Por exemplo:

ping 8.8.8.8

Se:

gateway responde
IP externo não

podemos investigar:

roteamento do roteador;
operadora;
firewall;
NAT;
rota errada;
conectividade WAN.

Depois teste DNS

Resolve-DnsName exemplo.com

Se o IP externo funciona, mas nomes não resolvem:

roteamento básico pode estar funcionando
DNS ganha prioridade no diagnóstico

Depois teste a aplicação

Test-NetConnection exemplo.com -Port 443

Agora estamos testando TCP.

Essa sequência evita misturar problemas diferentes.

Diagnóstico completo: impressora em outra sub-rede

PC:

192.168.10.50/24

Impressora:

192.168.20.100/24

Gateway do PC:

192.168.10.1

A impressora não está na mesma sub-rede.

Logo:

PC
↓
roteador
↓
rede 192.168.20.0/24
↓
impressora

Agora o roteador precisa saber como alcançar a rede da impressora.

Testando a rota

Execute:

Test-NetConnection 192.168.20.100 -DiagnoseRouting -InformationLevel Detailed

Observe a rota selecionada.

Depois:

Test-NetConnection 192.168.20.100 -Port 9100

Se a rota está correta, mas TCP falha, investigue o restante do caminho.

Diagnóstico completo: servidor acessível sem VPN, inacessível com VPN

Servidor:

203.0.113.10

Sem VPN:

Test-NetConnection 203.0.113.10 -Port 443

funciona.

Com VPN:

False

Agora:

route print -4

Compare antes e depois.

Se a VPN direciona aquele endereço para o túnel:

mudança de rota

pode explicar o comportamento.

Mas o servidor pode estar bloqueando a saída da VPN

Imagine que a rota esteja funcionando exatamente como projetado.

Sem VPN, o servidor enxerga um IP público.

Com VPN, enxerga outro.

O servidor pode permitir um e bloquear o outro.

Nesse caso:

rota está correta

mas:

política remota bloqueia

Novamente, Route Print é uma peça do diagnóstico, não o diagnóstico inteiro.

Diagnóstico completo: Internet pelo caminho errado

Notebook:

Wi-Fi
→ Internet doméstica

Ethernet
→ equipamento técnico sem Internet

Ao conectar o cabo:

Internet para

Execute:

Get-NetRoute -DestinationPrefix "0.0.0.0/0"

Se a Ethernet instalou uma rota padrão preferida:

tráfego externo
↓
Ethernet
↓
sem saída

Agora temos uma explicação lógica.

Uma correção possível não é necessariamente alterar métrica

Talvez a interface Ethernet nem devesse possuir gateway padrão.

Em uma rede técnica isolada, podemos ter:

IP
máscara
sem gateway

e usar Wi-Fi para Internet.

Mas isso depende da arquitetura.

Não existe uma receita universal.

A correção deve refletir o desenho correto da rede.

Erro comum 1: menor métrica sempre vence

Errado.

Primeiro:

prefixo mais específico

Depois, entre candidatas equivalentes:

métricas e outros critérios

Erro comum 2: rota padrão é usada para tudo

Errado.

Uma rota específica:

192.168.1.0/24

tem prioridade sobre:

0.0.0.0/0

para destinos daquela rede.

Erro comum 3: gateway é necessário para comunicação local

Nem sempre.

Se:

PC 192.168.1.50/24
impressora 192.168.1.150/24

ambos estão na mesma rede.

A comunicação pode ocorrer diretamente na LAN.

Erro comum 4: duas rotas padrão significam conflito

Não necessariamente.

Wi-Fi e Ethernet podem gerar duas rotas padrão e o Windows escolher normalmente entre elas.

O problema é quando a rota escolhida não atende ao objetivo.

Erro comum 5: qualquer rota 10.x.x.x é suspeita

Não.

Pode pertencer a:

VPN;
Hyper-V;
WSL;
Docker;
rede corporativa;
virtualização.

Identifique a interface antes de alterar.

Erro comum 6: apagar a rota e testar

Essa estratégia pode causar perda de conectividade.

Primeiro:

registre
analise
entenda

Depois altere.

Erro comum 7: usar route add para “forçar” funcionamento

Adicionar uma rota sem conhecer a topologia pode apenas mascarar outro problema.

Você precisa saber:

qual rede
qual gateway
qual retorno
qual interface

Erro comum 8: esquecer rota persistente antiga

Quando um único endereço ou rede segue um caminho estranho, procure:

rotas persistentes
rotas /32
rotas antigas

Erro comum 9: ignorar a VPN

Quando o problema surge apenas depois de conectar VPN, compare a tabela imediatamente.

Não comece reinstalando programas.

Erro comum 10: ignorar IPv6

Se o destino utiliza IPv6, olhar somente:

route print -4

pode não mostrar o caminho relevante.

Procedimento final de diagnóstico com Route Print

Podemos consolidar o artigo em uma metodologia.

1. Identifique o endereço de destino

Exemplo:

10.20.30.50

2. Veja a configuração IP

ipconfig /all

3. Liste os adaptadores

Get-NetAdapter

4. Confira métricas das interfaces

Get-NetIPInterface -AddressFamily IPv4

5. Visualize as rotas

route print -4

6. Encontre a rota mais específica

Primeiro compare:

/32
/24
/16
/8
/0

conforme o destino.

7. Verifique Next Hop e interface

Confirme se correspondem ao caminho esperado.

8. Faça diagnóstico de roteamento

Test-NetConnection DESTINO -DiagnoseRouting -InformationLevel Detailed

9. Teste o serviço

Test-NetConnection DESTINO -Port PORTA

10. Teste DNS quando usar nome

Resolve-DnsName nome

11. Use Tracert quando fizer sentido

tracert destino

12. Compare com e sem VPN

Quando o problema depende dela.

13. Faça captura se necessário

Netsh Trace
ou
Pktmon

14. Só então altere rotas

Se existir evidência clara de configuração incorreta.

Conclusão

O comando route print parece complicado principalmente porque apresenta muitas informações de uma só vez.

Mas o raciocínio necessário para interpretá-lo pode ser reduzido a poucas perguntas:

Qual é o destino?

Qual rota corresponde melhor ao destino?

Qual gateway será utilizado?

Qual interface será utilizada?

Existe outra rota mais específica?

Qual é a métrica entre rotas equivalentes?

Quando essas perguntas ficam claras, problemas aparentemente misteriosos começam a fazer sentido.

Wi-Fi e Ethernet conectados ao mesmo tempo deixam de ser uma caixa-preta.

VPN deixa de parecer simplesmente “um programa que muda a Internet”.

Uma impressora que desaparece ao conectar a VPN pode deixar de ser tratada como falha de driver.

Um servidor que funciona em uma rede e falha em outra pode revelar uma diferença de rota.

E uma única rota /32 pode explicar por que apenas um endereço específico está seguindo um caminho errado.

O ponto central é simples:

o Windows precisa decidir por onde enviar cada pacote. A tabela de rotas registra grande parte dessa decisão.

Quanto melhor entendermos essa tabela, menor será a necessidade de tentar soluções aleatórias.

FAQ — Route Print no Windows 11

O que faz o comando route print?

Ele exibe a tabela de roteamento do Windows, incluindo destinos, máscaras ou prefixos, gateways, interfaces e métricas.

Como executar?

Abra o Prompt de Comando ou Windows Terminal e use:

route print

Como mostrar apenas IPv4?

route print -4

Como mostrar apenas IPv6?

route print -6

O que significa 0.0.0.0/0?

Representa a rota padrão IPv4, utilizada quando nenhuma rota mais específica corresponde ao destino.

O que significa ::/0?

É a rota padrão IPv6.

Menor métrica sempre vence?

Não.

O Windows primeiro considera a rota mais específica para o destino. A métrica ganha importância entre rotas candidatas equivalentes.

O que significa /32?

Em IPv4, representa uma rota específica para um único endereço.

O que significa On-link ou No vínculo?

Indica que o destino ou rede é considerado diretamente alcançável pela interface correspondente, sem necessidade de um gateway intermediário para aquela rota.

Posso ter duas rotas padrão?

Sim.

Isso pode ocorrer com Ethernet, Wi-Fi, VPN e outras interfaces.

Não significa necessariamente erro.

Como descobrir qual interface está sendo utilizada?

Podemos combinar:

Get-NetIPInterface

com:

Test-NetConnection destino -InformationLevel Detailed

e analisar a tabela de rotas.

O que é Get-NetRoute?

É um cmdlet do PowerShell que permite consultar as rotas de forma estruturada.

O que é DiagnoseRouting?

O parâmetro:

Test-NetConnection destino -DiagnoseRouting

ajuda a investigar a seleção de rota para um destino.

VPN pode alterar a tabela de rotas?

Sim.

Clientes VPN frequentemente adicionam ou modificam rotas enquanto o túnel está ativo.

VPN pode fazer a impressora parar?

Pode.

A causa pode envolver roteamento, política da VPN, firewall ou bloqueio de acesso à LAN.

O que é split tunnel?

É uma configuração na qual apenas determinados destinos passam pela VPN, enquanto o restante utiliza outro caminho.

O que é full tunnel?

É uma configuração na qual grande parte ou todo o tráfego é direcionado pelo túnel VPN.

O que são rotas persistentes?

São rotas configuradas para permanecer após reinicializações.

Como criar uma rota persistente?

O utilitário route permite utilizar -p na criação de uma rota. Faça isso somente quando a arquitetura da rede exigir.

Devo apagar uma rota desconhecida?

Não.

Primeiro identifique a interface e a provável origem da rota.

Route Print detecta firewall?

Não.

Ele ajuda a entender o caminho de roteamento. Firewall e serviço precisam ser investigados com outras ferramentas.

Route Print substitui Ping?

Não.

Cada ferramenta responde uma pergunta diferente.

Route Print substitui Tracert?

Não.

Route Print mostra a tabela local. Tracert ajuda a observar saltos no caminho até o destino.

Route Print combina com Test-NetConnection?

Sim.

Essa é uma das melhores combinações para diagnosticar problemas de rota e portas TCP.

Atendimento VMIA

Problemas de rede nem sempre estão no roteador ou na placa Wi-Fi.

Em muitos casos, o Windows possui mais de um caminho disponível e escolhe uma rota diferente daquela que o usuário espera.

Isso pode acontecer com notebooks conectados simultaneamente ao Wi-Fi e ao cabo, computadores com VPN, adaptadores virtuais, redes corporativas, impressoras em outra sub-rede e equipamentos que utilizam gateways diferentes.

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores Windows, redes, Wi-Fi, roteadores, VPNs, impressoras e problemas de conectividade.

O foco do diagnóstico é descobrir a causa antes de alterar configurações importantes.

Em problemas de roteamento, isso significa verificar interfaces, métricas, gateways, tabela de rotas, resolução DNS, portas TCP e comportamento da comunicação antes de simplesmente reinstalar programas ou redefinir a rede.