PowerShell: Comandos de Diagnóstico de Conetividade no Windows

Neste artigo:

1. Test-NetConnection: a porta responde?
2. Test-Connection: o ping em objectos
3. Resolve-DnsName: DNS primeiro, suspeitas depois
4. Get-NetIPConfiguration e Get-NetAdapter: a placa de rede e o IP
5. Get-NetRoute, Get-NetNeighbor e Find-NetRoute: o caminho e o vizinho
6. Get-NetTCPConnection: portas em uso, o netstat em objectos
7. Invoke-WebRequest: quando a porta responde mas a aplicação não
8. Diagnóstico guiado em 60 segundos
9. Erros comuns
10. Checklist rápido de verificação
11. Artigos Relacionados
12. Fontes Oficiais

“O site X está em baixo”. “O servidor não responde”. “A impressora de rede desapareceu”. Antes de abrir o ecrã de diagnóstico do Windows ou trocar de cabo, os cmdlets de rede do PowerShell respondem a quase todas as perguntas do dia-a-dia: a porta responde? O nome resolve para o IP correcto? A rota existe? Que aplicação está a usar a porta? Este artigo é a referência prática desses comandos — cada secção usa um cmdlet com exemplos directos, do adaptador de rede ao HTTP. Para o cenário avançado (Get-NetAdapter avançado, PktMon, SMB Multichannel, w32tm), existe o artigo dedicado ao Windows Server 2026. Aqui é o dia-a-dia em qualquer Windows 10/11 ou Windows Server.

1. Test-NetConnection: a porta responde?

O Test-NetConnection (módulo NetTCPIP) é o comando de entrada em qualquer diagnóstico de conetividade: testa uma porta TCP, faz ping e faz trace, tudo num cmdlet. Está presente em qualquer Windows moderno, sem instalação adicional — ideal quando estás num computador de utilizador onde não podes instalar ferramentas.

A forma mais comum testa uma porta TCP:

PS C:\> Test-NetConnection server01 -Port 445

Saída típica (nomes e IPs de exemplo):

ComputerName           : server01
RemoteAddress          : 192.168.1.10
RemotePort             : 445
InterfaceAlias         : Ethernet
SourceAddress          : 192.168.1.50
TcpTestSucceeded       : True

O campo que importa é o TcpTestSucceeded. True significa que o handshake TCP de três passos (SYN, SYN-ACK, ACK) foi concluído — a porta está aberta e acessível. False pode ser o serviço parado, a firewall a bloquear ou a rota inexistente. Os comandos das secções seguintes servem exactamente para distinguir estes casos.

Atalhos para portas comuns com -CommonTCPPort (HTTP = 80, SMB = 445):

PS C:\> Test-NetConnection portal01 -CommonTCPPort HTTP
PS C:\> Test-NetConnection fileserver01 -CommonTCPPort SMB

Com -InformationLevel Detailed, o comando devolve o caminho completo: o resultado da resolução de nomes, o IP de origem escolhido, o próximo salto da rota e as regras IPsec aplicáveis:

PS C:\> Test-NetConnection server01 -Port 5985 -InformationLevel Detailed

Saída representativa (resumida):

ComputerName           : server01
RemoteAddress          : 192.168.1.10
RemotePort             : 5985
NameResolutionResults  : 192.168.1.10
InterfaceAlias         : Ethernet
SourceAddress          : 192.168.1.50
NetRoute (NextHop)     : 192.168.1.1
TcpTestSucceeded       : True

O modo de diagnóstico de routing serve quando o ping funciona mas a aplicação não liga — mostra a selecção de IP de origem e de rota com as regras IPsec em jogo:

PS C:\> Test-NetConnection -DiagnoseRouting -ConstrainSourceAddress 192.168.1.50 -InformationLevel Detailed

O -ConstrainSourceAddress força a simulação com um IP de origem específico — útil para perceber porque é que uma aplicação que deve sair por um IP concreto está a escolher outro.

Para portas de gestão remota, o Test-WSMan confirma num comando se o WS-Management (o protocolo por trás do PowerShell Remoting, porta 5985 por omissão) responde — devolve um objecto XmlElement com a identidade do serviço WS-Management (versão do produto e do protocolo). Confirma o serviço, não uma sessão de remoting funcional: autorização e configuração do WinRM são um passo à parte. Não substitui o Test-NetConnection para portas arbitrárias, mas é o teste certo para o WS-Management:

PS C:\> Test-WSMan server01

2. Test-Connection: o ping em objectos

O Test-Connection é o ping do PowerShell e devolve objectos — podes ordenar, filtrar e agregar, o que o ping.exe não permite. Na prática usam-se os dois: o Test-Connection para ciclos repetidos e decisões em scripts. O ping.exe fica para uma vista rápida em texto.

Teste simples:

PS C:\> Test-Connection -TargetName gateway01 -Count 4

Saída típica (PowerShell 7, adaptada do exemplo oficial):

Ping Source           Address                   Latency BufferSize Status
                                                   (ms)        (B)
---- ------           -------                   ------- ---------- ------
   1 DESKTOP          192.168.1.1                    24         32 Success
   2 DESKTOP          192.168.1.1                    25         32 Success
   3 DESKTOP          192.168.1.1                    23         32 Success
   4 DESKTOP          192.168.1.1                    24         32 Success

O -BufferSize ajusta o tamanho do payload do echo request (32 bytes por omissão, como mostra a coluna da saída) — a forma mais rápida de verificar se a degradação acontece com pacotes grandes:

PS C:\> Test-Connection -TargetName fileserver01 -Count 10 -BufferSize 1024

O -Repeat corre continuamente. O -Count, o -Delay (segundos entre pings) e o -Quiet (devolve $true/$false) cobrem o dia-a-dia em scripts:

if (Test-Connection -TargetName nas01 -Quiet) { Write-Host 'Ligação OK' } else { Write-Host 'Sem resposta' }

A família de endereços controla-se com -IPv4 e -IPv6 — por exemplo, quando o alvo tem os dois endereços no DNS e precisas de isolar a família v6:

PS C:\> Test-Connection -TargetName webserver01 -IPv6 -Count 2

Estes exemplos usam a sintaxe do PowerShell 7 (6.0+): o -TargetName substituiu o -ComputerName do Windows PowerShell 5.1 e o cmdlet foi reescrito nessa versão — a saída também mudou. No 5.1, troca -TargetName por -ComputerName. O -Traceroute (PowerShell 6.0+) mostra o percurso até ao destino, como o tracert, mas em objectos:

PS C:\> Test-Connection -TargetName webserver01 -Traceroute

3. Resolve-DnsName: DNS primeiro, suspeitas depois

Muitos “problemas de rede” são problemas de DNS: o serviço responde, mas o nome resolve para o IP errado. O Resolve-DnsName (módulo DnsClient) substitui o nslookup com saída em objectos e mais detalhe. Primeiro, a resolução completa tal como o Windows a faz:

PS C:\> Resolve-DnsName www.kbase.pt

Para ver só a resposta do servidor DNS, sem LLMNR ou NetBIOS na mistura, usa -DnsOnly. O Windows consulta LLMNR e NetBIOS sobretudo em nomes de uma etiqueta (hostnames na LAN). Em FQDN a diferença é menor, mas o -DnsOnly deixa a consulta limpa:

PS C:\> Resolve-DnsName fileserver01 -DnsOnly

Consultar um servidor específico — o passo de comparação clássico quando suspeitas do resolver local:

PS C:\> Resolve-DnsName www.kbase.pt -Server 1.1.1.1

Tipos de registo com -Type — os mais usados no diagnóstico:

PS C:\> Resolve-DnsName kbase.pt -Type MX
PS C:\> Resolve-DnsName kbase.pt -Type TXT
PS C:\> Resolve-DnsName webserver01 -Type AAAA

Para ver só a cache local (responde de imediato, confirma uma entrada negativa em cache):

PS C:\> Resolve-DnsName fileserver01 -CacheOnly

Quando o resultado é NONEXISTENT NAME (NXDOMAIN), o problema é de nome — verifica a zona no servidor DNS antes de suspeitar da rede. Quando o resultado traz o IP certo mas a aplicação continua a falhar, segue para as portas. Para trocar os servidores DNS do adaptador (o remédio quando o DHCP entregou um resolver avariado), o Set-DnsClientServerAddress grava os novos servidores. O Get-DnsClientServerAddress mostra os actuais.

PS C:\> Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses 192.168.1.10,1.1.1.1
PS C:\> Clear-DnsClientCache

4. Get-NetIPConfiguration e Get-NetAdapter: a placa de rede e o IP

O Get-NetIPConfiguration (módulo NetTCPIP) devolve a vista “página de estado” do adaptador: interfaces ligadas, endereços IP, gateway e servidores DNS configurados. É o ipconfig /all em objectos:

PS C:\> Get-NetIPConfiguration

Para incluir interfaces virtuais, loopback e desligadas:

PS C:\> Get-NetIPConfiguration -All

O Get-NetIPAddress devolve os endereços IP por interface, incluindo o prefixo, a origem (Dhcp, Manual) e o estado:

PS C:\> Get-NetIPAddress -AddressFamily IPv4 | Format-Table IPAddress, InterfaceAlias, PrefixOrigin

O Get-NetAdapter (módulo NetAdapter) completa o diagnóstico da placa de rede: estado do link, velocidade, driver. Na tabela por omissão:

PS C:\> Get-NetAdapter | Format-Table Name, Status, LinkSpeed

Saída típica:

Name      Status    LinkSpeed
----      ------    ---------
Ethernet  Up        1 Gbps
Wi-Fi     Up        300/400/600 (Mbps)

Para todos os campos, incluindo versão de driver e data:

PS C:\> Get-NetAdapter -IncludeHidden | Format-List -Property *

O -IncludeHidden expõe adaptadores ocultos (loopback, miniportas virtuais). Filtra com -Physical para ficar só com os adaptadores físicos:

PS C:\> Get-NetAdapter -Physical

O Restart-NetAdapter desactiva e volta a activar o adaptador — o equivalente PowerShell de desligar e voltar a ligar a placa de rede, útil quando o driver ficou num estado estranho:

PS C:\> Restart-NetAdapter 'Ethernet'

5. Get-NetRoute, Get-NetNeighbor e Find-NetRoute: o caminho e o vizinho

O Get-NetRoute devolve a tabela de routing — o route print em objectos:

PS C:\> Get-NetRoute -AddressFamily IPv4 | Format-Table DestinationPrefix, NextHop, RouteMetric, InterfaceMetric, InterfaceAlias -AutoSize

Quando duas interfaces (ex.: placa de rede e VPN) apresentam rotas por omissão em conflito, o metric decide: o Windows soma o RouteMetric da rota com o InterfaceMetric da interface e a soma mais baixa vence — duas rotas com o mesmo RouteMetric podem inverter a ordem por causa da métrica da interface.

O Get-NetNeighbor devolve a cache de vizinhos — o equivalente da tabela ARP em IPv4:

PS C:\> Get-NetNeighbor -AddressFamily IPv4 | Format-Table IPAddress, LinkLayerAddress, State -AutoSize

O Find-NetRoute responde directamente a “que IP de origem e que rota o Windows escolhe para chegar a este destino?” — devolve dois objectos: o IP local escolhido e a rota:

PS C:\> Find-NetRoute -RemoteIPAddress 8.8.8.8

Com -InterfaceIndex, força a escolha de rota a uma interface específica — a forma mais rápida de confirmar que caminho o tráfego tomaria pela placa VPN (o parâmetro com o mesmo papel no Test-NetConnection -DiagnoseRouting chama-se -ConstrainInterface, mas não existe no Find-NetRoute):

PS C:\> Find-NetRoute -RemoteIPAddress 8.8.8.8 -InterfaceIndex 12

Para os saltos intermédios, o tracert.exe mantém-se como a ferramenta do dia-a-dia (o Test-Connection -Traceroute cobre o mesmo em objectos) e o pathping.exe soma latência e perdas por hop num período alargado — demorado, mas é o único que quantifica perdas em cada hop do caminho:

PS C:\> pathping -n -q 10 -w 500 fileserver01

6. Get-NetTCPConnection: portas em uso, o netstat em objectos

O Get-NetTCPConnection (módulo NetTCPIP) devolve as ligações TCP activas e as portas em escuta — o equivalente ao netstat -ano com saída filtrável:

PS C:\> Get-NetTCPConnection -State Listen

Para encontrar a aplicação que usa uma porta específica (o caso clássico: a 80/443/3389 já está ocupada e o serviço não arranca):

PS C:\> Get-NetTCPConnection -LocalPort 8080 | Select-Object LocalAddress, LocalPort, State, OwningProcess

O OwningProcess é o PID. Cruza com o nome do processo:

PS C:\> Get-NetTCPConnection -LocalPort 8080 | ForEach-Object { Get-Process -Id $_.OwningProcess }

Para ver as sessões recebidas num serviço local (ex.: clientes ligados ao RDP deste servidor — a porta 3389 do extremo local):

PS C:\> Get-NetTCPConnection -LocalPort 3389 -State Established

7. Invoke-WebRequest: quando a porta responde mas a aplicação não

Um serviço pode aceitar a ligação TCP e devolver um erro HTTP — o Test-NetConnection diz “porta aberta”, o Invoke-WebRequest diz “a aplicação responde”. O teste de dois comandos que distingue rede de aplicação:

PS C:\> (Invoke-WebRequest -Uri 'http://intranet01/').StatusCode

O 200 confirma o serviço web a responder. 401/403 = porta aberta, autenticação em falta. 404 = o caminho não existe. Uma excepção de ligação (timeout, recusado) aponta para a rede ou para um proxy no caminho — volta ao Test-NetConnection e, se a rede tiver proxy, repete com -Proxy. Um TCP bem-sucedido confirma só a porta; um HTTP que falhe a seguir pode ter causas no serviço, no proxy ou na própria aplicação.

Com proxy web na rede, o -Proxy força o teste pelo proxy — separa os erros de proxy dos erros de destino:

PS C:\> (Invoke-WebRequest -Uri 'https://www.kbase.pt' -Proxy 'http://proxy01:8080').StatusCode

8. Diagnóstico guiado em 60 segundos

A ordem de cima para baixo: cada passo confirma o anterior antes de continuar. Corre a sequência na consola e o ponto de falha aparece sozinho:

# 1. O adaptador tem link?
Get-NetAdapter | Format-Table Name, Status, LinkSpeed

# 2. IP, gateway e DNS entregues?
Get-NetIPConfiguration

# 3. A rota por omissão aponta ao gateway certo?
Get-NetRoute -AddressFamily IPv4 -DestinationPrefix 0.0.0.0/0

# 4. O gateway responde?
Test-Connection -TargetName 192.168.1.1 -Count 2 -Quiet

# 5. O nome resolve para o IP certo?
Resolve-DnsName fileserver01 -DnsOnly

# 6. A porta do serviço responde?
Test-NetConnection fileserver01 -Port 445

# 7. O serviço SMB responde? (teste TCP)
Test-NetConnection fileserver01 -CommonTCPPort SMB

Interpretação directa: falha no passo 1-2 = problema local (cabo, driver, DHCP). Passa o 1-2 e falha o 3-4 = problema de configuração ou de gateway. Passa o 4 e falha o 5 = DNS. Passa o 5 e falha o 6 = firewall ou serviço parado. Passa o 6 e falha o 7 = a porta aceita ligações mas o serviço não responde como esperado — pode ser a aplicação, mas também proxy ou configuração do serviço; investiga no servidor antes de culpar a rede. Cada passo tem o cmdlet correspondente nas secções anteriores para ir mais a fundo.

9. Erros comuns

10. Checklist rápido de verificação

• [ ] Adaptador activo com link: Get-NetAdapter (Status = Up)
• [ ] IP, prefixo e gateway correctos: Get-NetIPConfiguration
• [ ] Rota por omissão aponta ao gateway certo: Get-NetRoute -DestinationPrefix 0.0.0.0/0
• [ ] Gateway responde: Test-Connection -TargetName <gateway> -Quiet
• [ ] Nome resolve para o IP esperado: Resolve-DnsName <nome> -DnsOnly
• [ ] Porta do serviço acessível: Test-NetConnection <host> -Port N (TcpTestSucceeded = True)
• [ ] Aplicação responde por HTTP: (Invoke-WebRequest -Uri <url>).StatusCode = 200
• [ ] Porta do serviço em escuta no destino: Get-NetTCPConnection -State Listen

Artigos Relacionados

• PowerShell: Alternativa ao Telnet para Testar Portas no Windows
• Diagnóstico de Conectividade Windows Server 2026: PowerShell Moderno, Hyper-V, Firewall Avançado, PktMon e SMB Multichannel
• Diagnóstico de Conectividade Linux Avançado 2026
• Diagnóstico de Conectividade SSH: Guia Prático para Sysadmins
• Windows 11: Implementação Automatizada com Unattend e OSDCloud

Fontes Oficiais

• Test-NetConnection — Microsoft Learn: sintaxe completa, exemplos de portas e -DiagnoseRouting.
• Test-Connection — Microsoft Learn: parâmetros de versão 7 (-TargetName, -BufferSize, -IPv6, -Traceroute) e reescrita do cmdlet no PowerShell 6.0.
• Resolve-DnsName — Microsoft Learn: -Type, -Server, -DnsOnly, -CacheOnly e as fontes LLMNR/NetBIOS.
• Get-NetIPConfiguration — Microsoft Learn: -All, -Detailed e pipeline para Get-NetIPAddress.
• Get-NetAdapter — Microsoft Learn: -Physical, -IncludeHidden e vistas de driver.
• Get-NetTCPConnection — Microsoft Learn: -State, -LocalPort, -OwningProcess.
• Get-NetRoute / Get-NetNeighbor / Get-NetIPAddress — Microsoft Learn: tabela de routing e cache de vizinhos.
• Find-NetRoute — Microsoft Learn: -RemoteIPAddress, -ConstrainInterface e o par de objectos devolvido.
• Invoke-WebRequest — Microsoft Learn: -Proxy, códigos de estado e diferenças 5.1/7.
• Test-WSMan — Microsoft Learn: verificação do WS-Management.
• Set-DnsClientServerAddress / Clear-DnsClientCache — Microsoft Learn: alteração de resolvers e limpeza de cache.
• Restart-NetAdapter — Microsoft Learn: reinício do adaptador.
• pathping — Microsoft Learn: latência e perdas por hop.
• tracert — Microsoft Learn: path tracking ICMP.