Métrica de rede no Windows 11 mostrando prioridade entre Ethernet e Wi-Fi — Windows 11 utiliza métricas e rotas para determinar qual interface de rede terá preferência entre Ethernet e Wi-Fi.

76 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Você conecta um cabo de rede ao computador, confirma que a Ethernet está funcionando e espera que o Windows 11 passe automaticamente a usar essa conexão. Mesmo assim, o Wi-Fi continua conectado. Em algumas situações, parece até que parte da comunicação continua acontecendo pela rede sem fio.

Isso gera uma dúvida bastante comum: quando Wi-Fi e Ethernet estão conectados ao mesmo tempo, como o Windows 11 decide qual conexão usar?

A resposta está principalmente na tabela de roteamento, nas interfaces de rede e nas métricas utilizadas pelo Windows.

O sistema operacional não escolhe uma conexão simplesmente porque ela é cabeada. Também não existe uma regra universal dizendo que Ethernet sempre terá prioridade sobre Wi-Fi. O Windows analisa as rotas disponíveis para chegar ao destino e utiliza critérios que ajudam a determinar qual caminho deve ser usado.

Entender esse funcionamento é especialmente útil quando o computador possui várias interfaces de rede, como:

Ethernet;
Wi-Fi;
adaptadores de VPN;
adaptadores virtuais;
Hyper-V;
VMware;
VirtualBox;
interfaces criadas por determinados programas;
diferentes gateways configurados no computador.

Em condições normais, o Windows faz essa escolha sozinho e o usuário nem percebe que existe um sistema de prioridades funcionando nos bastidores.

O problema aparece quando a rota escolhida não é aquela esperada.

Um computador pode estar conectado por cabo e Wi-Fi simultaneamente, por exemplo, e apresentar lentidão, dificuldade para acessar determinado equipamento da rede, comportamento diferente depois da instalação de uma VPN ou até utilizar uma interface diferente daquela que o usuário imaginava.

Neste guia, vamos entender como a métrica de rede do Windows 11 participa dessa decisão, como visualizar as métricas existentes, como interpretar a tabela de rotas e em quais situações realmente faz sentido alterar manualmente a prioridade de uma interface.

O Windows 11 sempre prefere Ethernet ao Wi-Fi?

Não necessariamente.

É comum imaginar uma regra simples:

Ethernet conectada = Windows usa Ethernet.

Na prática, a escolha é mais sofisticada.

Quando um programa precisa enviar dados para determinado endereço IP, o Windows consulta sua tabela de roteamento para descobrir qual caminho pode alcançar aquele destino.

Essa tabela contém informações como:

rede de destino;
máscara ou prefixo;
gateway;
interface;
métrica.

Portanto, o Windows não começa a decisão perguntando:

“Existe um cabo conectado?”

Ele precisa descobrir qual rota corresponde ao endereço de destino.

Isso também explica por que analisar apenas o ícone de rede da barra de tarefas pode ser insuficiente durante um diagnóstico.

O computador pode possuir várias interfaces ativas ao mesmo tempo.

Para verificar rapidamente os adaptadores existentes, abra o PowerShell e execute:

Get-NetAdapter

O comando pode mostrar interfaces Ethernet, Wi-Fi e outros adaptadores presentes no sistema.

Uma saída simplificada poderia ter uma estrutura semelhante a esta:

Name        InterfaceDescription                Status
----        --------------------                ------
Ethernet    Realtek PCIe GbE Family Controller  Up
Wi-Fi       Intel Wi-Fi Adapter                 Up

Nesse exemplo, tanto Ethernet quanto Wi-Fi estão ativos.

Isso, sozinho, ainda não responde qual interface será utilizada para determinado tráfego.

É justamente aí que entram as rotas e suas métricas.

O que é a métrica de rede no Windows 11?

A métrica funciona como um dos custos utilizados para comparar caminhos possíveis.

De forma simplificada:

quanto menor a métrica de uma rota, mais atraente ela tende a ser quando existem rotas equivalentes para o mesmo destino.

Imagine duas possibilidades equivalentes para alcançar determinado destino:

Rota A → métrica 10
Rota B → métrica 35

Se os demais critérios relevantes forem equivalentes, a rota com métrica 10 terá preferência.

Mas existe um detalhe essencial.

A menor métrica não vence qualquer rota

O Windows primeiro precisa determinar qual rota corresponde melhor ao endereço de destino.

Isso envolve o tamanho do prefixo da rota.

Uma rota específica normalmente tem prioridade sobre uma rota mais genérica.

Por exemplo:

192.168.1.0/24

é muito mais específica que:

0.0.0.0/0

A rota:

0.0.0.0/0

é conhecida como rota padrão.

Ela funciona, de maneira simplificada, como:

“Se nenhuma rota mais específica atender ao destino, tente este caminho.”

Por isso, afirmar simplesmente que “o Windows sempre escolhe a menor métrica” pode levar a uma interpretação errada.

A lógica correta precisa considerar primeiro a correspondência da rota com o destino e, depois, os critérios utilizados para escolher entre rotas concorrentes.

O que é a rota padrão?

Em uma rede doméstica típica, o computador possui rotas para a própria rede local e uma rota para alcançar destinos que não pertencem diretamente a ela.

Imagine um computador com:

IP: 192.168.1.50
Máscara: 255.255.255.0
Gateway: 192.168.1.1

O Windows sabe que endereços da rede 192.168.1.0/24 podem ser alcançados diretamente pela interface correspondente.

Para acessar um servidor na Internet, como um endereço que não pertence à rede local, normalmente será necessário encaminhar o tráfego para o gateway.

É nesse contexto que aparece uma rota semelhante a:

0.0.0.0    0.0.0.0    192.168.1.1

Em representação CIDR:

0.0.0.0/0

Ela é a rota padrão IPv4.

Quando Ethernet e Wi-Fi possuem acesso à Internet simultaneamente, podem existir diferentes possibilidades de saída. O Windows precisa decidir qual delas utilizar.

A métrica ajuda nessa escolha.

Como visualizar a prioridade das interfaces no Windows 11

Uma das ferramentas mais úteis para esse diagnóstico é o PowerShell.

Abra o Terminal do Windows ou PowerShell e execute:

Get-NetIPInterface

O comando apresenta informações das interfaces IPv4 e IPv6.

Entre as colunas importantes está:

InterfaceMetric

Podemos deixar a saída mais organizada:

Get-NetIPInterface |
Sort-Object InterfaceMetric |
Format-Table ifIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

Uma saída hipotética poderia ser:

ifIndex InterfaceAlias AddressFamily ConnectionState InterfaceMetric
------- -------------- ------------- --------------- ---------------
8       Ethernet       IPv4          Connected       10
12      Wi-Fi          IPv4          Connected       35
8       Ethernet       IPv6          Connected       10
12      Wi-Fi          IPv6          Connected       35

Nesse cenário, a Ethernet possui uma métrica de interface menor.

Isso pode contribuir para que rotas associadas à Ethernet tenham preferência quando existirem caminhos equivalentes.

Mas ainda não devemos concluir o diagnóstico apenas olhando essa coluna.

Precisamos observar também a tabela de roteamento.

InterfaceMetric e RouteMetric não são exatamente a mesma coisa

Esse é um ponto importante e frequentemente simplificado demais em tutoriais.

No Windows existem conceitos relacionados, mas distintos.

Podemos encontrar:

métrica da interface;
métrica associada à rota.

A escolha efetiva do caminho pode considerar o custo associado à rota juntamente com o custo da interface.

Por isso, durante um diagnóstico mais completo, não basta executar apenas:

Get-NetIPInterface

Também vale consultar:

Get-NetRoute

Esse comando permite visualizar as rotas conhecidas pelo Windows.

Para investigar especificamente as rotas padrão IPv4, podemos usar:

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

Suponha que apareçam duas rotas:

InterfaceAlias    NextHop        RouteMetric
Ethernet          192.168.1.1    0
Wi-Fi             192.168.1.1    0

À primeira vista, ambas parecem possuir a mesma métrica de rota.

Mas as interfaces podem ter métricas diferentes.

É por isso que precisamos analisar o conjunto.

O Windows calcula a métrica automaticamente?

Por padrão, normalmente sim.

O Windows possui um mecanismo de métrica automática que pode atribuir valores às interfaces considerando características da conexão, incluindo sua velocidade.

Essa automação evita que o usuário precise configurar manualmente cada adaptador.

Em uma máquina comum com:

Ethernet Gigabit;
Wi-Fi;
Bluetooth;
adaptadores virtuais;

o sistema tenta organizar as interfaces de forma coerente.

Na maior parte das situações, isso funciona bem.

Portanto, não existe motivo para desativar a métrica automática apenas porque Ethernet e Wi-Fi aparecem conectados ao mesmo tempo.

Alterações manuais fazem mais sentido quando existe um problema concreto ou uma necessidade específica de roteamento.

Por que o Wi-Fi continua conectado mesmo quando o cabo está conectado?

Porque permanecer conectado não significa necessariamente estar sendo usado como caminho principal para a Internet.

Esse detalhe causa muita confusão.

O Windows pode manter:

Ethernet → conectada
Wi-Fi → conectada

simultaneamente.

Isso não significa que metade do tráfego esteja obrigatoriamente passando pelo cabo e a outra metade pelo Wi-Fi.

Também não significa que o Windows esteja somando automaticamente as velocidades das duas conexões.

Manter as duas interfaces ativas pode ser perfeitamente normal.

O importante é descobrir qual rota está sendo escolhida para o destino que estamos investigando.

Ethernet + Wi-Fi não significa soma das velocidades

Imagine:

Ethernet = 500 Mbps
Wi-Fi = 300 Mbps

Não devemos concluir:

500 + 300 = 800 Mbps

O Windows não transforma automaticamente duas interfaces comuns em uma única conexão agregada de 800 Mbps.

Agregação, multipath e balanceamento são assuntos diferentes e dependem de tecnologias, protocolos, equipamentos ou aplicações compatíveis.

Em uma configuração doméstica normal, as duas interfaces podem coexistir, mas cada fluxo seguirá o caminho determinado pelas regras de roteamento aplicáveis.

Como visualizar a tabela de roteamento com route print

O Windows mantém o tradicional comando:

route print

Ele continua extremamente útil para diagnóstico.

Ao executá-lo no Prompt de Comando ou Terminal, encontramos seções relacionadas às interfaces e às rotas IPv4 e IPv6.

Entre as entradas IPv4 pode aparecer algo semelhante a:

Network Destination    Netmask          Gateway       Interface       Metric
0.0.0.0                0.0.0.0          192.168.1.1   192.168.1.50    25

Essa linha representa uma rota padrão.

Os campos ajudam a responder:

Network Destination

Qual rede ou destino aquela rota atende.

Netmask

Ajuda a definir quais endereços pertencem à rota.

Gateway

Próximo equipamento para onde os pacotes devem ser enviados.

Interface

Interface/endereço local utilizado para o envio.

Metric

Custo associado ao caminho.

Durante um diagnóstico com Ethernet e Wi-Fi conectados, uma das primeiras coisas interessantes é procurar quantas rotas:

0.0.0.0

existem.

Se houver mais de uma, precisamos descobrir por quais interfaces elas passam e quais custos estão associados a elas.

Um exemplo prático

Imagine um notebook conectado da seguinte maneira:

Ethernet

IP: 192.168.1.20
Gateway: 192.168.1.1

Wi-Fi

IP: 192.168.1.35
Gateway: 192.168.1.1

As duas interfaces estão na mesma rede e ambas receberam configuração válida.

O usuário abre o Gerenciador de Tarefas e percebe atividade no Wi-Fi mesmo depois de conectar o cabo.

A primeira reação pode ser:

“O Windows está ignorando meu cabo.”

Ainda é cedo para chegar a essa conclusão.

Podemos começar verificando:

Get-NetIPInterface

Depois:

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

E, se necessário:

route print

Esses comandos mostram muito mais sobre a decisão de roteamento do que simplesmente observar se o símbolo do Wi-Fi continua aparecendo.

O problema pode aparecer depois da instalação de uma VPN

Agora o cenário fica ainda mais interessante.

Imagine que o computador possua:

Ethernet
Wi-Fi
VPN
Hyper-V
VirtualBox

De repente, temos várias interfaces.

Uma VPN pode criar:

interface virtual;
novas rotas;
rotas específicas para determinadas redes;
rota padrão;
alterações relacionadas a DNS.

Por isso, depois da instalação de uma VPN, o comportamento de rede pode mudar mesmo que Ethernet e Wi-Fi continuem aparentemente normais.

Nesse caso, mudar aleatoriamente a prioridade da Ethernet pode não resolver nada.

O problema talvez esteja em uma rota criada pela VPN.

É justamente por isso que compreender a tabela de roteamento é muito mais útil do que decorar a regra:

“coloque Ethernet com métrica menor”.

O mesmo vale para máquinas virtuais

Programas de virtualização podem adicionar interfaces ao Windows.

Por exemplo:

vEthernet
VMware Network Adapter
VirtualBox Host-Only Network

Esses adaptadores são normais quando pertencem a softwares instalados conscientemente.

Entretanto, aumentam a quantidade de interfaces e rotas que aparecem durante o diagnóstico.

Um usuário pouco familiarizado com redes pode abrir:

Get-NetAdapter

e encontrar dez interfaces, mesmo tendo apenas:

uma placa Ethernet física;
uma placa Wi-Fi física.

Por isso, antes de alterar métricas, é importante identificar o que cada interface realmente representa.

A pergunta correta não é “qual conexão está ativa?”

Uma forma melhor de diagnosticar é perguntar:

Qual caminho o Windows está utilizando para chegar ao destino que apresenta problema?

Essa mudança de raciocínio é importante.

Imagine que:

Internet funciona;
impressora de rede não responde;
servidor local não abre;
VPN funciona parcialmente.

Talvez o problema não esteja na conexão principal com a Internet.

Pode existir uma rota específica interferindo apenas no endereço da impressora, servidor ou rede remota.

Por isso, a análise de métricas precisa sempre estar associada ao destino.

Na próxima parte vamos entrar justamente nessa etapa prática: descobrir qual interface o Windows 11 realmente está usando, interpretar Get-NetRoute, entender o papel do ifIndex e verificar situações em que uma rota mais específica vence outra mesmo possuindo uma métrica aparentemente maior.

Como descobrir qual conexão o Windows 11 realmente está usando

Depois de entender que Ethernet conectada não significa automaticamente que todo o tráfego passará pelo cabo, podemos avançar para uma pergunta mais útil:

como descobrir qual interface o Windows 11 realmente escolheu para chegar a determinado destino?

Essa resposta exige observar mais do que o status dos adaptadores.

Precisamos relacionar:

endereço de destino;
prefixo da rota;
gateway;
interface;
índice da interface;
métrica da interface;
métrica da rota.

Essa análise também ajuda a evitar um erro comum: alterar a métrica do Wi-Fi ou da Ethernet sem antes saber se a prioridade das interfaces realmente é a causa do problema.

Primeiro: descubra quais interfaces estão realmente ativas

Abra o PowerShell e execute:

Get-NetAdapter

Para deixar a visualização mais limpa:

Get-NetAdapter |
Format-Table Name,InterfaceDescription,ifIndex,Status,LinkSpeed

Podemos encontrar algo semelhante a:

Name       InterfaceDescription                  ifIndex Status LinkSpeed
----       --------------------                  ------- ------ ---------
Ethernet   Realtek PCIe GbE Family Controller          8 Up     1 Gbps
Wi-Fi      Intel Wi-Fi 6 AX201                         12 Up     866 Mbps

O campo ifIndex merece atenção.

Ele representa o índice da interface.

Nesse exemplo:

Ethernet = ifIndex 8
Wi-Fi    = ifIndex 12

Esse número ajuda a relacionar uma interface com as rotas presentes no sistema.

Se encontrarmos uma rota associada ao índice 8, por exemplo, podemos identificar que ela pertence à Ethernet.

Não confunda ifIndex com prioridade

Um detalhe importante:

um ifIndex menor não significa que aquela interface possui prioridade maior.

Se tivermos:

Ethernet = ifIndex 8
Wi-Fi = ifIndex 12

isso não quer dizer que a Ethernet vence porque 8 < 12.

O ifIndex serve para identificar a interface.

A prioridade depende das rotas aplicáveis e das métricas envolvidas.

Essa distinção evita uma interpretação errada bastante comum quando começamos a trabalhar com Get-NetRoute.

Descubra o endereço IP de cada interface

Podemos utilizar:

Get-NetIPAddress -AddressFamily IPv4

Ou filtrar alguns campos:

Get-NetIPAddress -AddressFamily IPv4 |
Format-Table InterfaceAlias,IPAddress,PrefixLength,InterfaceIndex

Uma saída simplificada poderia mostrar:

InterfaceAlias   IPAddress       PrefixLength InterfaceIndex
--------------   ---------       ------------ --------------
Ethernet         192.168.1.20              24              8
Wi-Fi            192.168.1.35              24             12

Agora sabemos que:

Ethernet
IP = 192.168.1.20
ifIndex = 8

Wi-Fi
IP = 192.168.1.35
ifIndex = 12

Essas informações serão úteis quando analisarmos a tabela de roteamento.

Veja a métrica das interfaces

Execute:

Get-NetIPInterface -AddressFamily IPv4

Podemos organizar a saída:

Get-NetIPInterface -AddressFamily IPv4 |
Sort-Object InterfaceMetric |
Format-Table ifIndex,InterfaceAlias,ConnectionState,AutomaticMetric,InterfaceMetric

Imagine o seguinte resultado:

ifIndex InterfaceAlias ConnectionState AutomaticMetric InterfaceMetric
------- -------------- --------------- --------------- ---------------
8       Ethernet       Connected       Enabled         10
12      Wi-Fi          Connected       Enabled         35

Temos:

Ethernet = métrica 10
Wi-Fi = métrica 35

A Ethernet possui um custo de interface menor.

Entretanto, ainda precisamos descobrir quais rotas estão associadas às duas interfaces.

Agora procure as rotas padrão

Para IPv4:

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

Podemos deixar a saída mais clara:

Get-NetRoute -AddressFamily IPv4 -DestinationPrefix "0.0.0.0/0" |
Format-Table ifIndex,InterfaceAlias,DestinationPrefix,NextHop,RouteMetric

Imagine:

ifIndex InterfaceAlias DestinationPrefix NextHop       RouteMetric
------- -------------- ----------------- -------       -----------
8       Ethernet       0.0.0.0/0         192.168.1.1             0
12      Wi-Fi          0.0.0.0/0         192.168.1.1             0

Existem duas rotas padrão.

Uma passa pela Ethernet.

Outra passa pelo Wi-Fi.

As duas possuem:

RouteMetric = 0

Porém, as métricas das interfaces eram:

Ethernet = 10
Wi-Fi = 35

Quando rotas concorrentes possuem o mesmo comprimento de prefixo, o custo efetivo leva em consideração as métricas associadas à rota e à interface.

Nesse exemplo simplificado, a Ethernet apresenta vantagem.

Isso explica por que olhar somente para RouteMetric pode gerar uma conclusão incompleta.

RouteMetric + InterfaceMetric

Uma maneira didática de compreender a comparação entre rotas equivalentes é considerar o custo associado à rota junto ao custo da interface.

Podemos representar isso de forma simplificada como:

Custo efetivo ≈ RouteMetric + InterfaceMetric

Imagine:

Ethernet

RouteMetric = 5
InterfaceMetric = 10

Total = 15

Wi-Fi

RouteMetric = 5
InterfaceMetric = 35

Total = 40

Entre rotas equivalentes, a Ethernet teria o menor custo.

Mas existe uma regra anterior que não podemos esquecer:

primeiro precisamos verificar qual rota possui a correspondência de prefixo mais específica para o destino.

Essa regra é fundamental.

Prefixo mais específico: uma das regras mais importantes do roteamento

Imagine que queremos alcançar:

10.20.30.50

O computador possui estas duas rotas:

0.0.0.0/0

10.20.30.0/24

As duas podem, em princípio, oferecer algum caminho.

Porém:

10.20.30.0/24

é muito mais específica para 10.20.30.50.

Portanto, ela será considerada antes da rota padrão.

Isso acontece mesmo que a rota padrão pareça ter uma métrica mais atraente.

Esse comportamento é conhecido como escolha pelo prefixo mais longo, ou longest prefix match.

Exemplo: por que uma VPN pode “vencer” a Ethernet

Imagine este cenário.

A Ethernet possui:

0.0.0.0/0
Métrica efetiva baixa

Uma VPN possui:

10.20.30.0/24
Métrica maior

Queremos acessar:

10.20.30.100

Seria incorreto concluir:

“A Ethernet tem métrica menor, então o Windows vai usar Ethernet.”

A rota:

10.20.30.0/24

corresponde muito melhor ao destino que:

0.0.0.0/0

Portanto, o tráfego destinado àquela rede pode seguir pela VPN.

É exatamente assim que muitas VPNs corporativas conseguem direcionar apenas determinadas redes pelo túnel.

Split tunneling: um exemplo perfeito

Imagine uma VPN empresarial.

O administrador deseja que somente a rede da empresa:

10.50.0.0/16

passe pela VPN.

A Internet comum deve continuar utilizando a conexão doméstica.

A tabela pode possuir algo conceitualmente parecido com:

0.0.0.0/0
→ roteador doméstico

10.50.0.0/16
→ VPN

Quando acessamos:

8.8.8.8

a rota específica da empresa não corresponde ao destino.

O Windows utiliza outro caminho disponível, normalmente a rota padrão.

Mas quando acessamos:

10.50.20.15

a rota:

10.50.0.0/16

corresponde ao endereço.

O tráfego segue pela VPN.

Isso demonstra por que perguntar apenas:

“Qual interface possui a menor métrica?”

não é suficiente.

Precisamos perguntar:

“Qual rota atende melhor ao endereço que estou tentando alcançar?”

Como procurar rotas específicas

Podemos visualizar todas as rotas IPv4:

Get-NetRoute -AddressFamily IPv4

Dependendo da quantidade de interfaces e programas instalados, a lista pode ser grande.

Uma forma útil de organizar:

Get-NetRoute -AddressFamily IPv4 |
Sort-Object DestinationPrefix,RouteMetric |
Format-Table ifIndex,InterfaceAlias,DestinationPrefix,NextHop,RouteMetric

Você pode encontrar rotas relacionadas a:

rede local;
loopback;
multicast;
rota padrão;
VPN;
interfaces virtuais;
redes adicionais.

Não altere rotas apenas porque parecem desconhecidas.

Primeiro identifique qual programa, interface ou serviço criou aquela entrada.

Como descobrir a rota usada para um destino específico

O PowerShell possui uma ferramenta particularmente interessante:

Find-NetRoute

Podemos fornecer um endereço remoto:

Find-NetRoute -RemoteIPAddress 8.8.8.8

O Windows procura a melhor rota disponível para alcançar aquele endereço.

Isso é muito mais útil do que simplesmente observar todas as rotas e tentar adivinhar qual delas será utilizada.

Podemos testar, por exemplo:

Find-NetRoute -RemoteIPAddress 1.1.1.1

ou um equipamento local:

Find-NetRoute -RemoteIPAddress 192.168.1.100

A grande vantagem é mudar a pergunta de:

“Qual interface parece ter prioridade?”

para:

“Qual rota o Windows selecionaria para este endereço?”

Esse é um diagnóstico muito mais objetivo.

Testando Ethernet e Wi-Fi na mesma rede

Considere:

Roteador = 192.168.1.1

Ethernet:
192.168.1.20/24

Wi-Fi:
192.168.1.35/24

Agora queremos descobrir o caminho escolhido para:

8.8.8.8

Execute:

Find-NetRoute -RemoteIPAddress 8.8.8.8

Observe principalmente:

interface;
endereço IP local;
próximo salto;
rota selecionada.

Depois podemos comparar com:

Get-NetIPInterface -AddressFamily IPv4

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

Com isso, conseguimos relacionar:

Destino
↓
Rota selecionada
↓
Interface
↓
Gateway

Essa sequência é muito mais confiável do que observar apenas o ícone de rede.

O tracert também ajuda?

Sim, mas responde outra pergunta.

Execute:

tracert 8.8.8.8

O tracert tenta revelar os saltos encontrados ao longo do caminho.

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

Exemplo:

1    192.168.1.1
2    ...
3    ...

Isso ajuda a investigar o caminho depois que o tráfego deixa o computador.

Entretanto, se Ethernet e Wi-Fi estiverem conectados ao mesmo roteador, ambas podem utilizar:

192.168.1.1

como gateway.

Nesse caso, olhar apenas o primeiro salto pode não revelar claramente qual interface local originou o tráfego.

Para essa investigação, Find-NetRoute, Get-NetRoute e Get-NetIPInterface fornecem informações mais diretamente relacionadas à decisão local.

E o Test-NetConnection?

Outra ferramenta extremamente útil do Windows é:

Test-NetConnection

Podemos executar:

Test-NetConnection 8.8.8.8 -InformationLevel Detailed

Dependendo da versão e do cenário, a saída pode trazer informações como:

ComputerName
RemoteAddress
InterfaceAlias
SourceAddress
PingSucceeded

Os dois campos particularmente interessantes são:

InterfaceAlias
SourceAddress

Eles ajudam a identificar qual interface e qual endereço local participaram do teste.

Imagine:

InterfaceAlias : Ethernet
SourceAddress  : 192.168.1.20

Agora temos uma evidência muito mais concreta de que aquele teste utilizou a Ethernet.

Test-NetConnection com rota

Também podemos utilizar:

Test-NetConnection 8.8.8.8 -TraceRoute

Isso combina diagnóstico de conectividade com informações de caminho.

É uma ferramenta excelente para complementar:

ping
tracert
route print
Get-NetRoute
Find-NetRoute

Cada comando responde a uma parte diferente do diagnóstico.

Como saber se a Internet está saindo pelo cabo

Uma sequência prática pode ser:

1. Veja as interfaces

Get-NetAdapter

2. Veja as métricas

Get-NetIPInterface -AddressFamily IPv4

3. Veja as rotas padrão

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

4. Descubra a rota para um endereço externo

Find-NetRoute -RemoteIPAddress 1.1.1.1

5. Faça um teste detalhado

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Observe especialmente:

InterfaceAlias
SourceAddress

Essa sequência permite construir um diagnóstico com evidências em vez de simplesmente concluir que o Windows está usando Wi-Fi porque o Wi-Fi continua conectado.

Um teste simples: desligar temporariamente o Wi-Fi

Existe ainda uma experiência simples para diagnóstico.

Primeiro faça:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Anote:

InterfaceAlias
SourceAddress

Depois desative temporariamente o Wi-Fi pelo próprio Windows e repita o teste.

Se a Ethernet estiver corretamente configurada, o acesso deverá continuar funcionando por ela.

Esse teste pode ajudar a separar:

problema de prioridade

de:

problema real na Ethernet.

Se a Internet deixa de funcionar assim que o Wi-Fi é desligado, talvez a Ethernet estivesse conectada fisicamente, mas sem uma configuração funcional de acesso à Internet.

Nesse caso, alterar métricas não resolverá a causa.

Cabo conectado não significa Ethernet funcional

Esse ponto merece destaque.

O Windows pode mostrar:

Ethernet
Connected

porque existe um link físico entre:

computador ↔ switch/roteador

Mas ainda podem existir problemas como:

DHCP;
gateway;
DNS;
VLAN;
autenticação;
configuração manual incorreta;
rota;
driver;
switch;
cabo;
porta do roteador.

Portanto, antes de forçar prioridade para Ethernet, confirme que ela realmente consegue alcançar os destinos necessários.

Teste o gateway pela interface

Comece descobrindo a configuração:

ipconfig

Ou:

ipconfig /all

Identifique na Ethernet:

IPv4 Address
Subnet Mask
Default Gateway

Depois teste o gateway:

ping 192.168.1.1

substituindo pelo endereço real do seu roteador.

Se houver falha de comunicação com o próprio gateway, a prioridade da interface provavelmente não é o primeiro problema a resolver.

Quando Ethernet e Wi-Fi estão em redes diferentes

Agora considere um cenário mais interessante:

Ethernet

192.168.10.50/24
Gateway: 192.168.10.1

Wi-Fi

192.168.20.50/24
Gateway: 192.168.20.1

Temos duas redes diferentes.

O Windows pode possuir rotas para:

192.168.10.0/24

pela Ethernet e:

192.168.20.0/24

pelo Wi-Fi.

Nesse cenário, manter as duas interfaces ativas pode ser necessário.

Talvez um servidor esteja na rede:

192.168.10.0/24

enquanto outro equipamento esteja em:

192.168.20.0/24

Desativar arbitrariamente uma interface poderia eliminar o acesso a uma das redes.

Novamente, o destino é que determina qual rota faz sentido.

E quando as duas interfaces estão na mesma sub-rede?

Esse cenário merece atenção especial.

Imagine:

Ethernet:
192.168.1.20/24

Wi-Fi:
192.168.1.30/24

As duas pertencem:

192.168.1.0/24

Agora o computador possui duas interfaces capazes de alcançar diretamente a mesma rede.

Isso pode funcionar, mas aumenta a complexidade do diagnóstico.

Podemos encontrar rotas semelhantes associadas às duas interfaces.

Nesse caso, métricas ganham ainda mais importância para determinar qual caminho terá preferência entre alternativas equivalentes.

Para um computador doméstico comum, muitas vezes não existe benefício prático em manter simultaneamente Wi-Fi e Ethernet conectados à mesma LAN.

Mas isso não significa que devemos sair desativando interfaces como primeira solução.

Primeiro devemos identificar se existe realmente um problema.

O erro de alterar a métrica para 1 em tudo

Alguns tutoriais sugerem:

“Coloque a Ethernet com métrica 1 e pronto.”

Isso pode funcionar em um cenário simples, mas não é uma boa regra universal.

Imagine que o computador possui:

Ethernet;
Wi-Fi;
VPN corporativa;
rede virtual;
acesso a servidor remoto.

Forçar métricas sem compreender as rotas pode mudar comportamentos necessários.

Uma VPN, por exemplo, pode depender de rotas específicas.

Por isso, o melhor procedimento é:

1. Identificar o problema
2. Identificar o destino
3. Descobrir a rota selecionada
4. Identificar a interface
5. Comparar as métricas
6. Alterar somente se houver motivo

Esse processo é muito mais seguro do que modificar números até a Internet aparentemente voltar a funcionar.

Como comparar Ethernet e Wi-Fi rapidamente

Podemos reunir algumas informações úteis com:

Get-NetIPInterface -AddressFamily IPv4 |
Where-Object {$_.ConnectionState -eq "Connected"} |
Sort-Object InterfaceMetric |
Format-Table ifIndex,InterfaceAlias,AutomaticMetric,InterfaceMetric

Depois:

Get-NetRoute -AddressFamily IPv4 -DestinationPrefix "0.0.0.0/0" |
Format-Table ifIndex,InterfaceAlias,NextHop,RouteMetric

E finalmente:

Find-NetRoute -RemoteIPAddress 1.1.1.1

Com esses três testes, conseguimos responder boa parte das dúvidas sobre qual conexão o Windows pretende utilizar para alcançar a Internet.

Não use apenas um comando para concluir o diagnóstico

Cada ferramenta revela uma parte do cenário.

Get-NetAdapter

Mostra os adaptadores e seus estados.

Get-NetIPAddress

Mostra os endereços atribuídos às interfaces.

Get-NetIPInterface

Ajuda a visualizar configurações da interface, incluindo sua métrica.

Get-NetRoute

Mostra a tabela de rotas.

Find-NetRoute

Ajuda a descobrir a melhor rota para um destino específico.

route print

Oferece uma visão tradicional da tabela de roteamento.

Test-NetConnection

Ajuda a testar conectividade e pode revelar a interface e o endereço de origem utilizados.

tracert

Ajuda a observar o caminho depois que os pacotes começam a atravessar os roteadores.

Usados em conjunto, esses comandos transformam uma suspeita em um diagnóstico.

Até aqui, ainda não alteramos nenhuma configuração

Isso é proposital.

Antes de executar comandos como:

Set-NetIPInterface

precisamos saber exatamente:

qual interface está sendo utilizada;
qual deveria ser utilizada;
quais rotas existem;
quais métricas estão configuradas;
se a métrica automática está ativa;
se existe VPN;
se existem adaptadores virtuais;
se as interfaces estão na mesma rede;
se a Ethernet realmente possui conectividade.

Somente depois disso faz sentido alterar a prioridade.

Como alterar a métrica da Ethernet e do Wi-Fi no Windows 11

Depois de identificar qual rota o Windows 11 está utilizando, qual interface participa da comunicação e quais métricas estão associadas ao caminho, podemos partir para a configuração manual.

Essa é justamente a etapa em que muitos usuários começam cedo demais.

Alterar a métrica pode resolver um problema de prioridade entre interfaces, mas não corrige falhas de DHCP, gateway, DNS, cabo, driver, VPN ou roteamento incorreto. Por isso, a mudança só faz sentido quando o diagnóstico mostrou que duas ou mais interfaces válidas disputam caminhos equivalentes e o Windows está escolhendo uma delas de forma diferente da desejada.

Em um cenário doméstico comum, por exemplo, pode ser interessante preferir a Ethernet sempre que o cabo estiver conectado e manter o Wi-Fi disponível como alternativa.

Nesse caso, podemos configurar uma métrica menor para a Ethernet e uma métrica maior para o Wi-Fi.

Antes de alterar: anote os valores atuais

Abra o PowerShell e execute:

Get-NetIPInterface -AddressFamily IPv4 |
Where-Object {$_.ConnectionState -eq "Connected"} |
Format-Table ifIndex,InterfaceAlias,AutomaticMetric,InterfaceMetric

Você pode encontrar algo como:

ifIndex InterfaceAlias AutomaticMetric InterfaceMetric
------- -------------- --------------- ---------------
8       Ethernet       Enabled         10
12      Wi-Fi          Enabled         35

Antes de modificar qualquer valor, anote:

nome da interface;
ifIndex;
estado de AutomaticMetric;
valor atual de InterfaceMetric.

Isso facilita bastante a reversão caso a alteração produza um comportamento inesperado.

Como alterar a métrica pelo PowerShell

O comando utilizado é:

Set-NetIPInterface

Suponha que desejamos deixar:

Ethernet = métrica 10
Wi-Fi = métrica 50

Podemos executar:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10

Depois:

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50

Em seguida, confirme:

Get-NetIPInterface -AddressFamily IPv4 |
Format-Table ifIndex,InterfaceAlias,AutomaticMetric,InterfaceMetric

A saída deve refletir os novos valores.

O objetivo desse exemplo é fazer com que a Ethernet tenha um custo menor que o Wi-Fi quando ambas participarem de rotas equivalentes.

É necessário usar métrica 1?

Não.

Esse é um detalhe importante.

Não existe necessidade de colocar:

Ethernet = 1

simplesmente porque queremos dar prioridade a ela.

O que normalmente importa é a relação entre os valores.

Por exemplo:

Ethernet = 10
Wi-Fi = 50

já cria uma diferença suficientemente clara.

Também poderíamos utilizar:

Ethernet = 15
Wi-Fi = 40

O número absoluto não é tão importante quanto a comparação entre interfaces que disputam caminhos equivalentes.

Utilizar números extremos sem necessidade também pode dificultar diagnósticos futuros.

Como alterar pelo ifIndex

Também podemos utilizar o índice da interface.

Se:

Ethernet = ifIndex 8

podemos executar:

Set-NetIPInterface -InterfaceIndex 8 -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10

Para o Wi-Fi:

Set-NetIPInterface -InterfaceIndex 12 -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50

Essa abordagem pode ser útil quando existem nomes de interfaces semelhantes ou quando estamos trabalhando com scripts.

Para um usuário comum, entretanto, InterfaceAlias costuma ser mais fácil de identificar.

O PowerShell precisa ser aberto como administrador?

Para alterações de configuração de rede, é recomendável abrir o Terminal ou PowerShell com privilégios administrativos.

Clique com o botão direito no menu Iniciar e abra:

Terminal (Admin)

ou procure por PowerShell e escolha a opção para executar como administrador.

Se o comando não possuir os privilégios necessários, o Windows poderá impedir a alteração.

Como voltar para a métrica automática

Essa é uma das informações mais importantes do procedimento.

Se você quiser devolver o controle da métrica ao Windows, execute:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -AutomaticMetric Enabled

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv4 -AutomaticMetric Enabled

Depois confirme:

Get-NetIPInterface -AddressFamily IPv4 |
Format-Table InterfaceAlias,AutomaticMetric,InterfaceMetric

Assim, o Windows volta a calcular automaticamente a métrica das interfaces.

Isso também significa que testar uma configuração manual não precisa ser uma mudança permanente.

Se o comportamento piorar, podemos restaurar a configuração automática.

E o IPv6?

Até agora utilizamos:

-AddressFamily IPv4

porque muitos exemplos domésticos ficam mais fáceis de visualizar dessa maneira.

Mas o Windows 11 também utiliza IPv6.

Podemos verificar as interfaces IPv6:

Get-NetIPInterface -AddressFamily IPv6

E as rotas:

Get-NetRoute -AddressFamily IPv6

Portanto, alterar apenas a métrica IPv4 não significa necessariamente que todo comportamento de rede será idêntico para IPv6.

Se o diagnóstico envolver conectividade IPv6, também devemos examinar:

rotas IPv6
métricas IPv6
gateway IPv6
DNS

Isso é particularmente importante porque sistemas modernos podem preferir IPv6 quando o protocolo está funcionando corretamente.

Não desative IPv6 apenas para “resolver”

Outro erro comum em tutoriais de rede é recomendar imediatamente:

“Desative IPv6.”

Isso pode mascarar o problema em vez de corrigi-lo.

O Windows 11 foi desenvolvido para operar com IPv4 e IPv6. Serviços modernos, redes corporativas e aplicações podem utilizar IPv6 normalmente.

Se existe um problema específico de roteamento IPv6, o correto é investigá-lo.

Por exemplo:

Get-NetRoute -AddressFamily IPv6

Get-NetIPInterface -AddressFamily IPv6

Desabilitar todo o protocolo sem diagnóstico pode criar novos problemas.

Como alterar a métrica pela interface gráfica

Também é possível modificar a métrica sem PowerShell.

No Windows 11, abra as configurações das conexões de rede e localize as propriedades do adaptador correspondente.

Em interfaces que expõem as configurações tradicionais de TCP/IP, podemos chegar às propriedades do protocolo IPv4 e abrir as opções avançadas.

Normalmente existe uma configuração relacionada a:

Métrica automática

Ao desmarcá-la, podemos informar manualmente uma métrica para aquela interface.

O resultado conceitual é semelhante ao obtido com:

Set-NetIPInterface

O PowerShell, porém, possui algumas vantagens:

mostra exatamente qual interface foi alterada;
facilita documentação;
permite confirmar valores;
permite reverter rapidamente;
facilita comparação entre várias interfaces.

Para diagnóstico técnico, ele costuma ser mais prático.

Depois de alterar, não confie apenas no valor configurado

Imagine que configuramos:

Ethernet = 10
Wi-Fi = 50

Isso não significa que podemos simplesmente fechar o PowerShell e considerar o problema resolvido.

Precisamos testar.

Comece novamente com:

Get-NetIPInterface -AddressFamily IPv4

Depois:

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

Em seguida:

Find-NetRoute -RemoteIPAddress 1.1.1.1

E finalmente:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Observe:

InterfaceAlias
SourceAddress

Se o teste mostrar a Ethernet como interface de origem, temos uma evidência concreta de que a alteração produziu o efeito esperado para aquele destino.

Faça mais de um teste

Evite testar apenas um endereço.

Você pode comparar:

Find-NetRoute -RemoteIPAddress 1.1.1.1

Find-NetRoute -RemoteIPAddress 8.8.8.8

E, se houver equipamento local:

Find-NetRoute -RemoteIPAddress 192.168.1.100

Isso é especialmente importante quando existem rotas específicas.

Talvez a Internet saia pela Ethernet, mas determinado servidor continue sendo acessado pela VPN.

Nesse caso, o comportamento pode estar perfeitamente correto.

Um cenário clássico: cabo conectado, mas Wi-Fi continua sendo usado

Imagine:

Ethernet
Métrica = 25

Wi-Fi
Métrica = 10

As duas interfaces possuem:

gateway válido;
Internet;
rota padrão.

Para destinos externos com rotas equivalentes, o Wi-Fi pode ter vantagem.

Se desejamos preferir a Ethernet, podemos inverter a relação:

Ethernet
Métrica = 10

Wi-Fi
Métrica = 50

Depois repetimos:

Find-NetRoute -RemoteIPAddress 1.1.1.1

Se o resultado mudar para Ethernet, encontramos uma causa relacionada à prioridade das interfaces.

Esse é um cenário em que alterar a métrica faz sentido.

Agora um cenário em que alterar a métrica NÃO resolve

Imagine:

Ethernet
IP = 169.254.25.10
Sem gateway válido

Wi-Fi
IP = 192.168.1.30
Gateway = 192.168.1.1

O computador está conectado fisicamente pelo cabo, mas a Ethernet não recebeu uma configuração IPv4 funcional da rede.

O endereço:

169.254.x.x

indica um cenário em que o Windows utilizou um endereço APIPA por não obter uma configuração IPv4 apropriada via DHCP.

Nesse caso, colocar:

Ethernet = métrica 1

não cria magicamente um gateway funcional.

O problema está em outra camada do diagnóstico.

Precisamos investigar:

servidor DHCP;
cabo;
porta do roteador;
switch;
driver;
VLAN;
configuração manual;
placa de rede.

Prioridade de interface e conectividade são problemas diferentes.

Outro cenário: Ethernet possui IP, mas não possui gateway

Imagine:

Ethernet
IP = 192.168.10.50
Máscara = /24
Gateway = vazio

Wi-Fi
IP = 192.168.1.30
Gateway = 192.168.1.1

A Ethernet pode funcionar perfeitamente para acessar dispositivos em:

192.168.10.0/24

mas não possuir uma rota padrão para a Internet.

Nesse caso, o Windows pode utilizar:

Ethernet → rede local específica
Wi-Fi → Internet

Isso pode ser exatamente o comportamento desejado.

Se o usuário olhar somente para o Wi-Fi sendo usado para Internet, poderá concluir incorretamente que existe um problema de prioridade.

Na verdade, a configuração pode ter sido planejada dessa maneira.

Quando uma rede Ethernet serve apenas para equipamentos locais

Esse cenário aparece bastante em ambientes técnicos.

Um computador pode estar conectado:

Wi-Fi → Internet
Ethernet → equipamento específico

Por exemplo:

Wi-Fi
192.168.1.50
Gateway 192.168.1.1

Ethernet
10.10.10.20
Sem gateway

A Ethernet poderia conectar o computador a:

equipamento industrial;
câmera;
servidor;
dispositivo de laboratório;
controlador;
appliance;
outro computador.

A ausência de gateway na Ethernet pode ser proposital.

Não devemos adicionar um gateway apenas para “completar” a configuração.

Ter dois gateways padrão sem necessidade pode tornar o roteamento mais confuso.

Dois gateways podem causar comportamento inesperado?

Podem.

Imagine:

Ethernet
Gateway = 192.168.1.1

Wi-Fi
Gateway = 192.168.2.1

Agora o Windows possui dois possíveis caminhos padrão para a Internet.

As métricas ajudam a determinar qual caminho tende a ser utilizado.

Isso pode ser legítimo.

Mas também pode produzir comportamento inesperado quando:

uma conexão possui Internet e outra não;
uma rede possui acesso restrito;
VPN adiciona outra rota padrão;
métricas são semelhantes;
adaptadores mudam de estado;
DHCP modifica configurações.

Por isso, múltiplos gateways merecem atenção durante o diagnóstico.

Um erro clássico: colocar gateway em todas as interfaces

Imagine um computador conectado a:

Internet via Wi-Fi
Equipamento local via Ethernet

Alguns usuários configuram manualmente um gateway na Ethernet porque acreditam que todo adaptador precisa de:

IP
Máscara
Gateway
DNS

Isso não é verdade.

Uma interface usada apenas para acessar uma sub-rede diretamente conectada pode não precisar de gateway padrão.

Adicionar um gateway desnecessário pode criar uma rota padrão adicional.

Então o problema deixa de ser:

“Como acessar meu equipamento?”

e passa a ser:

“Por que meu computador possui duas saídas para Internet?”

Uma configuração desnecessária pode criar a própria dificuldade que depois tentamos resolver com métricas.

Como verificar quantos gateways padrão existem

Use:

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

Observe:

InterfaceAlias
NextHop
RouteMetric

Se aparecer:

Ethernet  192.168.1.1
Wi-Fi     192.168.2.1
VPN       ...

há várias rotas padrão disponíveis.

Isso não significa automaticamente que existe erro.

Mas é um ótimo ponto de investigação.

Pergunte:

todas essas interfaces realmente precisam fornecer Internet?
alguma rota foi criada por VPN?
algum gateway foi configurado manualmente sem necessidade?
uma das conexões deixou de funcionar?
as métricas fazem sentido?

VPN e métrica: cuidado redobrado

Quando uma VPN está ativa, alterar métricas pode produzir resultados diferentes do esperado.

Existem VPNs configuradas para enviar todo o tráfego pelo túnel.

Outras utilizam split tunneling.

Uma VPN pode adicionar:

0.0.0.0/0

ou rotas mais específicas como:

10.0.0.0/8
172.16.0.0/12
192.168.100.0/24

dependendo da configuração.

Por isso, antes de alterar métricas enquanto uma VPN está conectada, examine:

Get-NetRoute -AddressFamily IPv4

Uma rota específica da VPN poderá vencer uma rota da Ethernet independentemente da preferência geral atribuída às interfaces.

Isso pode ser intencional e necessário para acessar recursos corporativos.

Adaptadores virtuais também entram no diagnóstico

Hyper-V, VMware, VirtualBox e outros programas podem criar interfaces virtuais.

Ao executar:

Get-NetAdapter

podemos encontrar algo semelhante a:

Ethernet
Wi-Fi
vEthernet (Default Switch)
VMware Network Adapter VMnet1
VMware Network Adapter VMnet8

Não conclua que os adaptadores virtuais são um problema apenas porque aparecem na lista.

Eles podem ser perfeitamente legítimos.

O importante é descobrir:

possuem gateway?
possuem rota padrão?
estão associados ao destino problemático?
pertencem a algum software em uso?

Desabilitar adaptadores aleatoriamente pode interromper máquinas virtuais ou outros recursos.

Como descobrir rapidamente quem possui rota padrão

Podemos combinar informações:

Get-NetRoute -AddressFamily IPv4 -DestinationPrefix "0.0.0.0/0" |
Format-Table ifIndex,InterfaceAlias,NextHop,RouteMetric

Depois:

Get-NetIPInterface -AddressFamily IPv4 |
Format-Table ifIndex,InterfaceAlias,AutomaticMetric,InterfaceMetric

Compare o mesmo:

ifIndex

entre as duas saídas.

Isso ajuda a visualizar a relação:

Interface
+
RouteMetric
+
InterfaceMetric
=
custo do caminho

desde que as rotas comparadas tenham a mesma especificidade para o destino.

E se as métricas forem iguais?

Imagine:

Ethernet
InterfaceMetric = 25

Wi-Fi
InterfaceMetric = 25

e as rotas padrão também possuem custos equivalentes.

Nesse tipo de situação, o comportamento pode ficar menos intuitivo para o usuário.

Isso não significa necessariamente que o Windows distribuirá tráfego igualmente entre as duas conexões.

Existem outros detalhes envolvidos na seleção e no estabelecimento de conexões.

Para um computador doméstico em que desejamos claramente preferir Ethernet, pode ser útil criar uma diferença explícita:

Ethernet = 10
Wi-Fi = 50

Isso reduz a ambiguidade entre rotas equivalentes.

A conexão já estabelecida pode continuar usando a interface anterior

Outro detalhe importante:

alterar a métrica não significa necessariamente que todas as conexões já abertas serão instantaneamente transferidas para outra interface.

Aplicações podem possuir conexões TCP já estabelecidas.

Nesses casos, pode ser necessário:

fechar e reabrir o programa;
repetir o teste;
desconectar e reconectar a interface;
em situações específicas, reiniciar o computador.

Por isso, depois da alteração, execute novos testes em vez de observar apenas uma aplicação que já estava aberta.

Como testar corretamente depois da mudança

Uma sequência prática pode ser:

Get-NetIPInterface -AddressFamily IPv4

Confirme as métricas.

Depois:

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

Confirme as rotas padrão.

Depois:

Find-NetRoute -RemoteIPAddress 1.1.1.1

Identifique a rota selecionada.

Finalmente:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Verifique:

InterfaceAlias
SourceAddress

Se necessário, repita com outro endereço externo.

Esse processo deixa o teste reproduzível.

Posso simplesmente desligar o Wi-Fi quando uso cabo?

Sim, em muitos computadores domésticos essa é uma solução perfeitamente válida.

Se você não precisa do Wi-Fi enquanto utiliza Ethernet, desativar a conexão sem fio elimina qualquer dúvida sobre qual interface será utilizada.

Entretanto, isso é diferente de corrigir um problema de roteamento.

Desligar o Wi-Fi pode esconder uma configuração incorreta.

Se o objetivo é apenas usar cabo em casa, tudo bem.

Mas se estamos investigando por que o Windows tomou determinada decisão, compreender métricas e rotas fornece uma resposta muito mais completa.

Alguns notebooks podem desligar o Wi-Fi automaticamente?

Certos equipamentos e utilitários de fabricantes podem oferecer recursos relacionados à troca automática entre Ethernet e Wi-Fi.

O comportamento varia conforme:

fabricante;
driver;
BIOS/UEFI;
utilitário instalado;
política empresarial.

Por isso, se o Wi-Fi desaparece automaticamente ao conectar o cabo, não devemos assumir imediatamente que isso é uma regra nativa universal do Windows 11.

Pode existir um recurso do fabricante interferindo no comportamento.

Métrica não mede velocidade da Internet

Outro conceito importante:

InterfaceMetric = 10

não significa:

10 Mbps

nem:

10 ms

A métrica é um valor utilizado para ajudar na seleção de rotas.

Ela não representa diretamente:

velocidade;
latência;
perda de pacotes;
qualidade do sinal Wi-Fi;
largura de banda.

Uma interface com métrica menor pode ser escolhida mesmo que naquele momento esteja apresentando desempenho pior.

O roteamento não executa um Speedtest antes de cada conexão.

Ethernet pode ter prioridade e ainda ser mais lenta

Imagine:

Ethernet
Métrica = 10
Link negociado = 100 Mbps

Wi-Fi
Métrica = 30
Link = 866 Mbps

O Windows pode preferir a Ethernet para rotas equivalentes porque ela possui menor custo.

Isso não significa que ela será necessariamente mais rápida.

Talvez exista:

cabo antigo;
porta Fast Ethernet;
problema de negociação;
adaptador limitado a 100 Mbps.

Nesse caso, o problema é desempenho físico ou de enlace, não roteamento.

Podemos verificar a velocidade negociada com:

Get-NetAdapter |
Format-Table Name,Status,LinkSpeed

Se Ethernet aparecer como:

100 Mbps

quando deveria negociar:

1 Gbps

vale investigar cabo, conector, switch e placa.

Wi-Fi com métrica maior ainda pode aparecer com tráfego

Mesmo depois de priorizar Ethernet, o Gerenciador de Tarefas pode eventualmente mostrar algum tráfego no Wi-Fi.

Isso não prova que toda Internet está passando por ele.

Podem existir:

broadcasts;
multicast;
comunicações locais;
processos relacionados à interface;
protocolos específicos;
conexões iniciadas anteriormente.

O diagnóstico precisa ser feito em relação ao fluxo ou destino que realmente interessa.

Quando vale a pena configurar a métrica manualmente?

A configuração manual pode fazer sentido quando existe um objetivo claro, como:

Preferir Ethernet para Internet
Manter Wi-Fi conectado como alternativa

ou quando:

há duas conexões ativas;
ambas possuem rota válida;
o Windows está escolhendo uma interface diferente da desejada;
uma aplicação depende de uma rota previsível;
existe uma topologia específica de rede.

Nesses casos, definir métricas manualmente pode tornar o comportamento mais previsível.

Quando é melhor deixar automático?

Para a maioria dos computadores domésticos:

AutomaticMetric = Enabled

é uma boa escolha.

O Windows consegue administrar a prioridade das interfaces sem intervenção manual na maior parte das situações.

Se:

a Internet funciona;
a Ethernet é utilizada quando necessário;
VPN funciona;
rede local funciona;
não existem sintomas;

não existe vantagem em alterar métricas apenas por curiosidade.

Uma configuração manual cria algo que precisará ser lembrado futuramente.

Meses depois, o usuário pode trocar:

roteador;
placa de rede;
VPN;
adaptador Wi-Fi;

e esquecer que existe uma métrica fixa configurada.

Diagnóstico antes da configuração

Podemos resumir a lógica correta em uma sequência.

Primeiro:

Get-NetAdapter

Descubra quais interfaces existem.

Depois:

Get-NetIPAddress -AddressFamily IPv4

Confira os IPs.

Depois:

Get-NetIPInterface -AddressFamily IPv4

Observe métricas.

Depois:

Get-NetRoute -AddressFamily IPv4

Examine as rotas.

Então:

Find-NetRoute -RemoteIPAddress ENDERECO

Descubra qual caminho o Windows prefere para o destino real.

Por último:

Test-NetConnection ENDERECO -InformationLevel Detailed

Confirme interface e endereço de origem.

Somente depois, se necessário:

Set-NetIPInterface

Exemplo completo: quero que Ethernet tenha prioridade

Suponha que o diagnóstico encontrou:

Ethernet
ifIndex = 8
InterfaceMetric = 40

Wi-Fi
ifIndex = 12
InterfaceMetric = 20

Ambas possuem Internet e rotas padrão equivalentes.

O objetivo é preferir Ethernet.

Execute como administrador:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10

Depois:

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50

Confira:

Get-NetIPInterface -AddressFamily IPv4 |
Format-Table InterfaceAlias,AutomaticMetric,InterfaceMetric

Teste:

Find-NetRoute -RemoteIPAddress 1.1.1.1

Depois:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Procure:

InterfaceAlias : Ethernet

Se aparecer, a alteração atingiu o objetivo para aquele teste.

Como desfazer tudo

Se quiser devolver a decisão ao Windows:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -AutomaticMetric Enabled

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv4 -AutomaticMetric Enabled

Se também alterou IPv6, faça o equivalente:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv6 -AutomaticMetric Enabled

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv6 -AutomaticMetric Enabled

Depois confirme:

Get-NetIPInterface |
Format-Table InterfaceAlias,AddressFamily,AutomaticMetric,InterfaceMetric

Guardar esse procedimento de reversão é muito mais importante do que memorizar um valor específico de métrica.

O principal aprendizado sobre métricas no Windows 11

Quando Ethernet e Wi-Fi estão conectados ao mesmo tempo, não devemos pensar apenas em:

cabo versus Wi-Fi

O Windows trabalha com algo mais próximo de:

Destino
↓
Rotas compatíveis
↓
Prefixo mais específico
↓
Custos das rotas
↓
Interface selecionada

A métrica é importante, mas faz parte de uma decisão maior.

Isso explica situações que à primeira vista parecem estranhas:

Ethernet conectada, mas Wi-Fi continua ativo;
Internet sai pelo cabo, mas determinado servidor passa pela VPN;
Ethernet funciona apenas para a rede local;
duas interfaces possuem gateway;
uma rota específica vence outra de menor métrica;
adaptadores virtuais aparecem no roteamento;
alterar a prioridade não corrige uma interface sem gateway.

Depois que entendemos essa lógica, a rede deixa de parecer uma escolha misteriosa feita pelo Windows.

Ela passa a ser algo que podemos observar, testar e diagnosticar.

Depois de compreender como o Windows 11 escolhe entre Ethernet, Wi-Fi, VPNs e outras interfaces, fica mais fácil perceber que muitos problemas atribuídos à “prioridade da rede” na verdade possuem outra origem.

A métrica é importante, mas ela não substitui um diagnóstico completo.

Em muitos casos, alterar InterfaceMetric apenas muda o caminho preferido sem resolver a causa da falha.

Por isso, vale encerrar este guia com alguns cenários práticos, erros frequentes e uma sequência de diagnóstico que pode ser usada tanto por usuários domésticos quanto por técnicos.

Erro 1: achar que Ethernet sempre tem prioridade

Esse talvez seja o erro mais comum.

O usuário conecta o cabo e espera que o Windows 11 abandone automaticamente o Wi-Fi.

Quando isso não acontece, conclui que existe um problema.

Mas manter Wi-Fi e Ethernet ativos simultaneamente pode ser perfeitamente normal.

O que realmente importa é descobrir qual rota está sendo escolhida para o destino.

Para isso, utilize:

Find-NetRoute -RemoteIPAddress 1.1.1.1

E complemente com:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Se aparecer:

InterfaceAlias : Ethernet

o tráfego daquele teste está utilizando a Ethernet, mesmo que o Wi-Fi continue conectado.

Erro 2: alterar a métrica sem verificar se a Ethernet possui Internet

Considere:

Ethernet
Status: Connected

Isso não garante:

Internet funcionando

A interface pode possuir link físico e ainda apresentar problemas de:

DHCP;
gateway;
DNS;
VLAN;
cabo;
switch;
roteador;
driver.

Antes de alterar a prioridade, verifique:

ipconfig /all

Confirme se a Ethernet recebeu:

IPv4 válido
Máscara
Gateway

Depois teste o gateway:

ping 192.168.1.1

substituindo pelo endereço real do roteador.

Se o próprio gateway não responde, a métrica não é o primeiro problema a resolver.

Erro 3: confundir métrica com velocidade

Métrica não representa Mbps.

Também não representa latência.

Portanto:

InterfaceMetric = 10

não significa que a conexão possui:

10 Mbps

nem:

10 ms

A métrica funciona como um custo utilizado pelo Windows durante a seleção de rotas.

Uma interface pode possuir métrica menor e desempenho pior.

Exemplo:

Ethernet
Métrica = 10
Link = 100 Mbps

Wi-Fi
Métrica = 30
Link = 866 Mbps

O Windows pode preferir a Ethernet mesmo que o Wi-Fi possua um link nominalmente mais rápido.

Se a Ethernet deveria negociar a 1 Gbps, mas aparece como 100 Mbps, investigue:

Get-NetAdapter |
Format-Table Name,Status,LinkSpeed

Erro 4: configurar gateway em uma interface que não precisa dele

Imagine:

Wi-Fi
Internet

Ethernet
Equipamento local

Talvez a Ethernet exista apenas para acessar:

10.10.10.0/24

Nesse caso, ela pode não precisar de gateway padrão.

Adicionar um gateway sem necessidade cria uma nova rota:

0.0.0.0/0

Isso pode gerar uma segunda saída para Internet.

Depois o usuário começa a alterar métricas para resolver um conflito que não existiria se o gateway desnecessário não tivesse sido configurado.

Erro 5: colocar métrica 1 em tudo

Alguns procedimentos encontrados na Internet recomendam valores extremamente baixos.

Por exemplo:

Ethernet = 1

Não há necessidade de fazer isso na maioria dos casos.

Se o objetivo é apenas diferenciar duas interfaces, algo como:

Ethernet = 10
Wi-Fi = 50

já cria uma preferência clara.

Mais importante do que o número exato é compreender:

qual rota está sendo comparada;
qual interface participa dela;
qual destino está sendo acessado.

Erro 6: ignorar rotas específicas

Imagine:

Ethernet
0.0.0.0/0

VPN
10.20.0.0/16

Agora acessamos:

10.20.50.10

Mesmo que a Ethernet possua uma métrica muito menor, a rota da VPN é mais específica.

Portanto, o tráfego pode passar pelo túnel.

Isso não é um erro.

Pode ser exatamente o comportamento desejado.

É por isso que métricas nunca devem ser analisadas isoladamente.

Caso prático 1: Ethernet conectada, mas Internet continua no Wi-Fi

Sintoma:

Ethernet: conectada
Wi-Fi: conectado
Internet: funcionando

O usuário acredita que o Windows está ignorando o cabo.

Passo 1

Execute:

Get-NetIPInterface -AddressFamily IPv4 |
Where-Object {$_.ConnectionState -eq "Connected"} |
Format-Table InterfaceAlias,AutomaticMetric,InterfaceMetric

Passo 2

Verifique as rotas padrão:

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

Passo 3

Teste:

Find-NetRoute -RemoteIPAddress 1.1.1.1

Passo 4

Confirme:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Se aparecer:

InterfaceAlias : Wi-Fi

e ambas as conexões estiverem funcionando corretamente, então faz sentido comparar suas métricas.

Se a intenção for priorizar Ethernet, podemos configurar:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50

Depois repita os testes.

Caso prático 2: Ethernet recebe 169.254.x.x

Sintoma:

Ethernet
169.254.32.18

Wi-Fi:

192.168.1.50
Gateway 192.168.1.1

Nesse caso, o problema principal não é métrica.

A Ethernet não recebeu uma configuração IPv4 normal da rede.

Comece investigando:

ipconfig /all

Depois verifique:

DHCP;
cabo;
porta LAN;
switch;
driver;
configuração manual.

Não adianta transformar a Ethernet em “prioridade máxima” se ela não possui um caminho funcional até o gateway.

Caso prático 3: Internet usa Wi-Fi e Ethernet acessa equipamento local

Imagine:

Wi-Fi
192.168.1.30/24
Gateway 192.168.1.1

Ethernet:

10.10.10.20/24
Sem gateway

Equipamento:

10.10.10.50

Esse computador pode perfeitamente utilizar:

Wi-Fi → Internet
Ethernet → equipamento

Não existe problema.

Para confirmar a rota do equipamento:

Find-NetRoute -RemoteIPAddress 10.10.10.50

Depois compare com:

Find-NetRoute -RemoteIPAddress 1.1.1.1

É possível que cada endereço utilize uma interface diferente.

Isso demonstra claramente por que a pergunta:

“Qual interface o Windows está usando?”

é incompleta.

A pergunta correta é:

“Qual interface o Windows está usando para este destino?”

Caso prático 4: tudo funciona até conectar uma VPN

Sintoma:

Internet funciona;
rede local funciona;
VPN conecta;
depois alguns recursos deixam de responder.

Não altere imediatamente a métrica do Wi-Fi ou Ethernet.

Primeiro execute:

Get-NetRoute -AddressFamily IPv4

Compare as rotas antes e depois de conectar a VPN.

Procure por:

0.0.0.0/0

e redes específicas adicionadas pelo cliente VPN.

Depois teste o destino problemático:

Find-NetRoute -RemoteIPAddress ENDERECO_DO_DESTINO

Se a VPN criou uma rota mais específica, talvez ela esteja deliberadamente direcionando aquele tráfego.

Caso prático 5: Internet funciona no cabo, mas fica limitada a 100 Mbps

Isso pode parecer um problema de escolha entre Wi-Fi e Ethernet, mas provavelmente não é.

Verifique:

Get-NetAdapter |
Format-Table Name,InterfaceDescription,Status,LinkSpeed

Se aparecer:

Ethernet
100 Mbps

em uma rede Gigabit, investigue:

cabo;
conectores;
porta do roteador;
switch;
adaptador;
negociação.

Um cabo com pares defeituosos, por exemplo, pode permitir conexão Ethernet, mas impedir uma negociação Gigabit.

Alterar a métrica não resolverá esse problema.

Caso prático 6: o Windows troca de conexão depois de sair da suspensão

Se o comportamento ocorre após suspensão ou hibernação, não assuma que a métrica foi alterada.

Também vale investigar:

driver da placa;
gerenciamento de energia;
tempo de renegociação da Ethernet;
tempo de reconexão do Wi-Fi;
DHCP;
políticas do fabricante.

A Ethernet pode demorar alguns segundos para restabelecer link, enquanto o Wi-Fi se conecta antes.

Nesse intervalo, o Windows pode utilizar a rota disponível naquele momento.

Depois a situação pode mudar.

Por isso, repita:

Get-NetIPInterface

Get-NetRoute

depois que todas as interfaces estiverem estabilizadas.

Checklist rápido de diagnóstico

Quando houver dúvida entre Ethernet e Wi-Fi, siga esta sequência:

1. Verificar adaptadores
2. Verificar IPs
3. Verificar gateways
4. Verificar métricas
5. Verificar rotas padrão
6. Procurar a rota do destino
7. Confirmar a interface usada
8. Alterar métrica somente se necessário
9. Repetir os testes

Os comandos correspondentes são:

Get-NetAdapter

Get-NetIPAddress -AddressFamily IPv4

Get-NetIPInterface -AddressFamily IPv4

Get-NetRoute -AddressFamily IPv4

Find-NetRoute -RemoteIPAddress 1.1.1.1

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Essa pequena sequência resolve boa parte das dúvidas de roteamento em computadores Windows.

FAQ — Métrica de rede no Windows 11

O Windows 11 sempre prefere Ethernet?

Não.

O sistema analisa as rotas disponíveis para o destino e os custos associados a elas. Ethernet frequentemente recebe uma preferência favorável em configurações automáticas, mas isso não deve ser tratado como uma regra absoluta.

Posso deixar Wi-Fi e Ethernet conectados ao mesmo tempo?

Sim.

O Windows 11 consegue trabalhar com várias interfaces simultaneamente.

Isso não significa que suas velocidades serão somadas.

Também não significa que ambas serão usadas igualmente para Internet.

Como saber se o Windows está usando Wi-Fi ou Ethernet?

Um teste útil é:

Test-NetConnection 1.1.1.1 -InformationLevel Detailed

Observe:

InterfaceAlias
SourceAddress

Você também pode utilizar:

Find-NetRoute -RemoteIPAddress 1.1.1.1

para identificar a rota preferida para aquele destino.

Qual métrica devo colocar na Ethernet?

Não existe um número universal.

Se o objetivo for apenas fazer Ethernet ter preferência sobre Wi-Fi em rotas equivalentes, valores como:

Ethernet = 10
Wi-Fi = 50

podem criar uma diferença clara.

Não existe necessidade de utilizar obrigatoriamente métrica 1.

Métrica menor significa Internet mais rápida?

Não.

Métrica representa custo de roteamento.

Velocidade da conexão depende de outros fatores, como:

link negociado;
Wi-Fi;
cabo;
roteador;
operadora;
servidor;
congestionamento.

O Wi-Fi deve desligar quando conecto o cabo?

Não obrigatoriamente.

O Windows pode manter ambas as interfaces ativas.

Alguns notebooks ou utilitários de fabricantes possuem recursos próprios para desativar Wi-Fi quando Ethernet está conectada, mas isso não deve ser considerado comportamento universal.

Posso desativar o Wi-Fi manualmente?

Sim.

Se você utiliza Ethernet e não precisa da conexão sem fio naquele momento, desativar Wi-Fi pode simplificar o cenário.

Mas isso é diferente de diagnosticar por que determinada rota foi escolhida.

Como restaurar a métrica automática?

Para Ethernet:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -AutomaticMetric Enabled

Para Wi-Fi:

Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AddressFamily IPv4 -AutomaticMetric Enabled

Depois confira:

Get-NetIPInterface -AddressFamily IPv4

Alterar a métrica pode prejudicar uma VPN?

Pode alterar o comportamento de roteamento em determinados cenários.

VPNs podem criar rotas próprias e interfaces virtuais.

Antes de mudar métricas em computadores que utilizam VPN, verifique:

Get-NetRoute

e identifique quais rotas pertencem ao túnel.

Uma rota de métrica maior pode vencer outra de métrica menor?

Sim, quando ela possui um prefixo mais específico para o destino.

Exemplo:

0.0.0.0/0

é uma rota genérica.

Já:

10.20.30.0/24

é muito mais específica para um endereço como:

10.20.30.50

A especificidade da rota é analisada antes da simples comparação entre custos de rotas equivalentes.

Por que o Wi-Fi mostra tráfego mesmo com Ethernet prioritária?

Pode existir tráfego local, multicast, broadcast, processos de sistema ou conexões estabelecidas anteriormente.

Ver alguma atividade no Wi-Fi não significa automaticamente que a navegação principal esteja saindo por ele.

Preciso reiniciar o Windows depois de mudar a métrica?

Nem sempre.

As novas decisões de roteamento podem ser observadas sem reinicialização.

No entanto, conexões já estabelecidas por determinados programas podem continuar utilizando o caminho anterior.

Fechar e abrir novamente o aplicativo costuma ser um teste útil.

O comando route print ainda funciona no Windows 11?

Sim.

Execute:

route print

Ele continua sendo uma ótima ferramenta para visualizar a tabela de roteamento.

O PowerShell, porém, oferece comandos mais fáceis de filtrar, como:

Get-NetRoute

Find-NetRoute

Conclusão

A escolha entre Wi-Fi e Ethernet no Windows 11 é mais interessante do que parece.

O sistema não olha simplesmente para o cabo e conclui:

Ethernet conectada = usar Ethernet

Ele precisa decidir qual caminho atende melhor cada destino.

Essa decisão envolve:

tabela de roteamento;
prefixos;
interfaces;
gateways;
métricas;
rotas específicas;
VPNs;
adaptadores virtuais.

Em uma rede simples, o Windows normalmente consegue administrar tudo automaticamente.

Por isso, a configuração:

AutomaticMetric = Enabled

deve ser considerada um bom ponto de partida.

A alteração manual faz sentido quando existe um objetivo concreto e o diagnóstico mostra que rotas equivalentes estão utilizando uma interface diferente daquela desejada.

Mais importante ainda: métrica não corrige falta de conectividade.

Se a Ethernet possui endereço 169.254.x.x, não alcança o gateway ou negocia apenas 100 Mbps em uma infraestrutura Gigabit, devemos investigar essas causas antes de mexer na prioridade.

A melhor abordagem é sempre começar perguntando:

Qual destino apresenta problema e qual rota o Windows está utilizando para alcançá-lo?

Com comandos como:

Get-NetAdapter
Get-NetIPInterface
Get-NetRoute
Find-NetRoute
Test-NetConnection

é possível transformar uma impressão vaga de que “o Windows prefere o Wi-Fi” em um diagnóstico preciso da rota realmente utilizada.

Precisa de ajuda com problemas de rede no Windows?

A VMIA realiza diagnóstico e configuração de computadores, notebooks, redes domésticas, roteadores, Wi-Fi, impressoras e Windows.

Problemas de rede nem sempre estão no roteador ou na operadora. Configurações de DHCP, DNS, gateway, adaptadores, drivers, rotas e interfaces também podem alterar completamente o comportamento da conexão.

A VMIA pode analisar o problema por acesso remoto ou atendimento técnico agendado, dependendo do tipo de falha.

VMIA – Manutenção e Configuração

Telefone e WhatsApp: (11) 99779-7772

Site: https://vmia.site

Blog técnico: https://vmia.com.br

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

Atendimento com agendamento em São Paulo e suporte remoto para problemas compatíveis com acesso à distância.