Test-NetConnection no Windows 11 testando portas TCP 445, 3389 e 9100 para diagnóstico de problemas de rede — Test-NetConnection no Windows 11 permite testar portas TCP e ajudar no diagnóstico de falhas em servidores, RDP, impressoras e outros serviços de rede.

78 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Quando um computador apresenta um problema de rede, um dos primeiros comandos usados para diagnóstico costuma ser o Ping. Ele é simples, rápido e extremamente útil para descobrir se determinado equipamento responde pela rede. Porém, existe uma limitação importante: receber uma resposta ao Ping não significa necessariamente que o serviço que você pretende utilizar naquele equipamento esteja funcionando.

Uma impressora pode responder perfeitamente ao Ping e, mesmo assim, não imprimir. Um servidor pode responder ao Ping, mas não permitir acesso às pastas compartilhadas. Um computador pode estar visível na rede, mas a Área de Trabalho Remota pode não funcionar. Da mesma forma, um site ou servidor pode estar acessível pela rede, enquanto uma determinada porta TCP permanece bloqueada.

É justamente nesse tipo de diagnóstico que o comando Test-NetConnection, disponível no PowerShell do Windows, se torna extremamente útil.

Com ele, podemos ir além da pergunta:

“O equipamento responde?”

e começar a responder uma questão muito mais importante:

“O serviço que eu quero utilizar está realmente acessível pela rede?”

Neste guia da VMIA, vamos entender como funciona o Test-NetConnection no Windows 11, seus principais parâmetros, como testar portas TCP e, principalmente, como interpretar os resultados para localizar problemas envolvendo firewall, servidores, impressoras, compartilhamentos, acesso remoto e outros serviços de rede.

O que é o Test-NetConnection?

O Test-NetConnection é um cmdlet do PowerShell desenvolvido para executar diferentes testes relacionados à conectividade de rede.

Dependendo dos parâmetros utilizados, ele pode fornecer informações sobre resolução de nomes, endereço IP de destino, interface de rede utilizada, endereço IP de origem, resposta ICMP, rota e conectividade TCP.

Isso faz dele uma ferramenta bastante interessante para diagnóstico porque reúne informações que, em outras situações, exigiriam vários comandos separados.

A sintaxe mais simples é:

Test-NetConnection destino

Por exemplo:

Test-NetConnection google.com

Também existe o alias:

tnc

Portanto:

tnc google.com

pode ser utilizado como uma forma abreviada do comando.

Para diagnóstico técnico e documentação, porém, prefiro utilizar o nome completo Test-NetConnection. Dessa forma, fica muito mais fácil entender posteriormente qual comando foi executado.

Test-NetConnection não é apenas um Ping melhorado

Esse é um ponto importante.

Seria incorreto definir Test-NetConnection simplesmente como uma versão avançada do comando Ping.

O Ping e o Test-NetConnection podem ter algumas funções relacionadas, mas atendem a necessidades diferentes.

O comando:

ping 192.168.1.100

utiliza mensagens ICMP para verificar, entre outras coisas, se existe resposta do destino e medir o tempo aproximado dessa comunicação.

Já:

Test-NetConnection 192.168.1.100 -Port 9100

tenta verificar a conectividade TCP com a porta especificada.

São testes diferentes.

Essa diferença explica uma situação extremamente comum em suporte técnico:

Ping funciona
Impressão não funciona

Isso não representa necessariamente uma contradição.

O equipamento pode estar respondendo ao ICMP enquanto o serviço responsável pela impressão não está acessível.

Entendendo IP, porta e serviço

Antes de utilizar o Test-NetConnection, vale entender três conceitos fundamentais:

endereço IP, porta e serviço.

Imagine um computador com:

192.168.1.50

O endereço IP identifica aquele dispositivo dentro da rede.

Entretanto, vários serviços podem funcionar simultaneamente nesse mesmo endereço.

Por exemplo:

192.168.1.50:80
192.168.1.50:443
192.168.1.50:445
192.168.1.50:3389

O endereço continua sendo o mesmo.

O que muda é a porta.

De maneira simplificada, podemos imaginar o endereço IP como o endereço de um prédio e as portas como diferentes entradas utilizadas para chegar a determinados serviços.

Essa analogia não descreve todos os detalhes técnicos do TCP/IP, mas ajuda bastante a compreender por que simplesmente testar o IP não é suficiente.

Por que o Ping pode funcionar enquanto um programa não conecta?

Essa é uma das principais razões para aprender Test-NetConnection.

Considere um computador tentando acessar:

192.168.1.20

Executamos:

ping 192.168.1.20

e recebemos respostas normalmente.

Podemos concluir que existe comunicação IP básica entre os equipamentos e que o destino está respondendo às solicitações ICMP utilizadas naquele teste.

Porém, isso não prova que qualquer serviço TCP esteja disponível.

Imagine que queremos acessar uma pasta compartilhada.

Podemos testar:

Test-NetConnection 192.168.1.20 -Port 445

Se aparecer:

TcpTestSucceeded : True

o teste TCP para aquela porta foi bem-sucedido.

Se aparecer:

TcpTestSucceeded : False

temos uma informação completamente diferente.

O computador pode estar alcançando o equipamento, mas não conseguiu estabelecer a conexão TCP testada na porta 445.

Agora nosso diagnóstico fica muito mais direcionado.

O significado de TcpTestSucceeded

Quando utilizamos:

Test-NetConnection servidor -Port 443

uma das informações mais importantes apresentadas é:

TcpTestSucceeded

Existem dois resultados principais:

TcpTestSucceeded : True

ou:

TcpTestSucceeded : False

O primeiro indica que o teste conseguiu estabelecer a conexão TCP com a porta informada.

O segundo indica que isso não aconteceu.

Porém, existe uma regra extremamente importante:

TcpTestSucceeded False não informa sozinho a causa do problema

Esse resultado não deve ser interpretado automaticamente como:

“O firewall está bloqueando.”

Pode ser firewall?

Sim.

Mas existem várias outras possibilidades.

Entre elas:

serviço não iniciado;
programa não está escutando naquela porta;
endereço IP incorreto;
porta incorreta;
firewall do computador;
firewall de terceiros;
ACL ou regra intermediária;
roteamento incorreto;
equipamento desligado;
serviço configurado em outra porta;
problema de VLAN;
isolamento entre clientes Wi-Fi;
falha de comunicação entre redes;
equipamento mudou de endereço IP.

Por isso, o Test-NetConnection deve fazer parte de um processo de diagnóstico, e não ser utilizado como uma resposta automática para todos os problemas.

Como testar uma porta TCP no Windows 11

A sintaxe básica é:

Test-NetConnection ENDERECO -Port PORTA

Por exemplo:

Test-NetConnection 192.168.1.50 -Port 443

Ou utilizando um nome:

Test-NetConnection servidor -Port 443

Também podemos testar um domínio:

Test-NetConnection exemplo.com -Port 443

Quando utilizamos um nome em vez de um endereço IP, outro elemento entra no diagnóstico: a resolução de nomes.

Isso pode ser extremamente útil.

Se:

Test-NetConnection servidor -Port 445

falhar, mas:

Test-NetConnection 192.168.1.20 -Port 445

funcionar, temos uma pista importante de que o problema pode não estar na conectividade TCP propriamente dita.

A investigação deve considerar a resolução do nome utilizado.

Testando a porta 80

A porta TCP 80 é tradicionalmente associada ao HTTP.

Podemos testar:

Test-NetConnection exemplo.com -Port 80

Se o resultado mostrar:

TcpTestSucceeded : True

foi possível estabelecer a conexão TCP testada naquela porta.

Mas atenção:

isso não significa que uma página específica esteja funcionando corretamente.

O Test-NetConnection testa a conectividade TCP. Ele não substitui um navegador, curl ou ferramentas específicas para analisar uma aplicação HTTP.

Essa distinção é fundamental.

Temos diferentes camadas de diagnóstico.

Podemos descobrir que:

DNS funciona
IP está acessível
TCP 80 funciona
HTTP apresenta erro

Nesse cenário, o problema provavelmente está acima da conectividade TCP básica.

Testando a porta 443

A porta TCP 443 é normalmente utilizada por HTTPS.

O teste pode ser realizado assim:

Test-NetConnection exemplo.com -Port 443

Um resultado positivo indica que foi possível estabelecer a conexão TCP com a porta testada.

Novamente, isso não valida sozinho certificado TLS, autenticação, conteúdo do site ou funcionamento completo da aplicação.

Essa separação ajuda muito durante o diagnóstico.

Em vez de dizer simplesmente:

“O site não funciona.”

podemos dividir o problema.

Primeiro:

O nome resolve?

Depois:

Existe caminho de rede?

Depois:

A porta TCP responde?

Depois:

A negociação segura funciona?

E finalmente:

A aplicação responde corretamente?

Quanto mais dividimos o problema, mais fácil se torna descobrir onde a falha está ocorrendo.

Testando a porta 445 para compartilhamento de arquivos

A porta TCP 445 está fortemente associada ao SMB moderno no Windows.

Se um computador não consegue acessar um compartilhamento de rede, podemos executar:

Test-NetConnection 192.168.1.20 -Port 445

Se recebermos:

TcpTestSucceeded : True

sabemos que o teste TCP conseguiu estabelecer conexão com aquela porta.

Isso muda a direção da investigação.

Talvez o problema esteja relacionado a:

credenciais;
permissões;
compartilhamento;
políticas de segurança;
configuração SMB;
nome do compartilhamento;
conta utilizada.

Agora considere:

PingSucceeded    : True
TcpTestSucceeded : False

Esse resultado é particularmente interessante.

Existe resposta ICMP, mas o teste TCP na porta 445 falhou.

Nesse caso, devemos investigar se o serviço esperado está disponível e se alguma regra está impedindo a comunicação.

Essa é uma informação muito mais útil do que simplesmente repetir dezenas de testes de Ping.

Testando a porta 3389 do RDP

A Área de Trabalho Remota do Windows utiliza normalmente a porta TCP 3389 em sua configuração padrão, embora ela possa ser alterada.

Podemos testar:

Test-NetConnection 192.168.1.30 -Port 3389

Se o computador responde ao Ping, mas:

TcpTestSucceeded : False

aparece para a porta 3389, temos uma pista de que o problema está relacionado ao acesso ao serviço ou ao caminho TCP até ele.

Podemos então verificar:

Área de Trabalho Remota habilitada;
serviço correspondente;
Firewall do Windows;
perfil de rede;
porta configurada;
regras do roteador quando existe acesso entre redes;
VPN;
políticas de segurança.

Novamente, o Test-NetConnection não diz automaticamente qual desses itens está errado.

Ele ajuda a descobrir em qual direção continuar investigando.

Test-NetConnection e impressoras de rede

Aqui temos uma aplicação especialmente interessante para assistência técnica.

Imagine uma impressora instalada em:

192.168.1.150

Executamos:

ping 192.168.1.150

e recebemos:

Resposta de 192.168.1.150

Mesmo assim, ao enviar um documento:

Erro de impressão

ou o trabalho fica parado na fila.

O Ping mostrou apenas uma parte da situação.

Dependendo da configuração da impressora, podemos investigar o protocolo e a porta realmente utilizados para impressão.

Em uma instalação que utiliza RAW na porta TCP 9100, por exemplo:

Test-NetConnection 192.168.1.150 -Port 9100

Se aparecer:

TcpTestSucceeded : True

sabemos que a conexão TCP testada com a porta 9100 foi estabelecida.

Se aparecer:

TcpTestSucceeded : False

a investigação muda completamente.

Esse teste é particularmente útil em situações nas quais:

Ping funciona
Interface web funciona
Impressão não funciona

Cada serviço pode utilizar uma comunicação diferente.

É exatamente por isso que dizer apenas “a impressora está na rede porque responde ao Ping” pode ser uma conclusão incompleta.

A porta 9100 e a impressão RAW

Muitas impressoras de rede utilizam impressão RAW pela porta TCP 9100.

No Windows, isso aparece com frequência em impressoras configuradas através de uma Standard TCP/IP Port.

Podemos encontrar uma configuração semelhante a:

IP da impressora: 192.168.1.150
Protocolo: RAW
Porta: 9100

Nesse cenário:

Test-NetConnection 192.168.1.150 -Port 9100

torna-se um teste extremamente interessante.

Compare:

ping 192.168.1.150

com:

Test-NetConnection 192.168.1.150 -Port 9100

Os comandos estão respondendo perguntas diferentes.

O primeiro verifica a resposta ICMP.

O segundo tenta estabelecer uma conexão TCP com a porta utilizada no teste.

Essa diferença pode economizar muito tempo durante o diagnóstico.

Nem toda impressora utiliza a porta 9100

Outro erro seria assumir que todas as impressoras de rede imprimem através da porta TCP 9100.

Isso não é verdade.

Dependendo do equipamento e da instalação, podemos encontrar tecnologias como:

RAW;
LPR/LPD;
IPP;
IPPS;
WSD;
soluções próprias do fabricante.

Por isso, antes de testar uma porta aleatória, descubra como aquela impressora está instalada no Windows.

Um teste pode funcionar perfeitamente e não ter qualquer relação com o problema real.

Por exemplo:

Test-NetConnection 192.168.1.150 -Port 80

pode retornar True.

Isso pode apenas indicar que o servidor web da impressora está acessível.

Não significa que o canal utilizado para enviar trabalhos de impressão esteja funcionando.

Essa diferença parece pequena, mas é fundamental para um diagnóstico correto.

Test-NetConnection ajuda a separar rede de aplicação

Uma das maiores vantagens desse comando é permitir a criação de uma sequência lógica de diagnóstico.

Imagine o seguinte cenário:

Programa não conecta ao servidor

Em vez de reinstalar imediatamente o programa, podemos começar investigando a infraestrutura.

1. Descobrir o destino

Qual servidor o programa utiliza?

Por exemplo:

192.168.1.200

2. Descobrir a porta

Imagine que o programa dependa da porta:

3. Testar a conectividade TCP

Test-NetConnection 192.168.1.200 -Port 8443

4. Interpretar

Se:

TcpTestSucceeded : False

não faz sentido começar reinstalando o programa sem investigar por que a comunicação necessária não está sendo estabelecida.

Se:

TcpTestSucceeded : True

podemos continuar subindo o nível do diagnóstico e verificar autenticação, certificados, aplicação, configuração do cliente e logs.

Essa abordagem reduz bastante a tentativa e erro.

O endereço SourceAddress também é importante

Uma informação frequentemente ignorada na saída do Test-NetConnection é o endereço de origem.

Em computadores com apenas uma interface ativa isso pode parecer pouco relevante.

Mas imagine um computador com:

Ethernet;
Wi-Fi;
VPN;
adaptador virtual;
Hyper-V;
software de virtualização.

Agora temos várias interfaces e potencialmente várias rotas.

Nesse cenário, saber qual endereço o Windows está utilizando para alcançar o destino pode ser fundamental.

Um problema aparentemente misterioso pode ocorrer simplesmente porque o tráfego está saindo pela interface errada.

Esse tipo de situação merece uma investigação mais profunda e será importante quando chegarmos aos testes de rota.

O endereço RemoteAddress pode revelar problemas de DNS

Ao executar:

Test-NetConnection servidor.exemplo -Port 443

observe também:

RemoteAddress

Ele mostra o endereço IP utilizado para o destino resolvido naquele teste.

Isso é muito útil quando suspeitamos de DNS.

Imagine que o servidor deveria ser:

192.168.1.20

mas o nome está sendo resolvido para:

192.168.1.30

Nesse caso, podemos testar portas durante horas e continuar investigando o equipamento errado.

Por isso, sempre leia a saída inteira.

Não olhe somente:

True

ou:

False

Os outros campos podem fornecer pistas importantes.

Test-NetConnection substitui o Ping?

Não.

As duas ferramentas podem trabalhar juntas.

O Ping continua excelente para vários diagnósticos.

Por exemplo:

ping 192.168.1.1

pode ajudar a avaliar:

resposta ICMP;
latência;
perda de pacotes;
resolução de nome em determinados testes;
conectividade básica.

Já o Test-NetConnection pode aprofundar a investigação quando precisamos saber se determinado serviço TCP está acessível.

Uma sequência bastante útil pode ser:

ipconfig
↓
ping
↓
Test-NetConnection
↓
tracert / Test-NetConnection -TraceRoute
↓
pktmon
↓
logs da aplicação

Nem sempre precisaremos utilizar todas essas ferramentas.

A ideia é começar com o teste mais simples capaz de responder à pergunta atual e avançar conforme as evidências.

O erro mais comum: testar uma porta sem saber o que ela representa

Imagine alguém executando:

Test-NetConnection 192.168.1.100 -Port 443

e recebendo:

TcpTestSucceeded : False

A pessoa conclui:

“A rede está com problema.”

Essa conclusão pode estar completamente errada.

Talvez aquele equipamento simplesmente não ofereça nenhum serviço na porta TCP 443.

Nesse caso, a falha é exatamente o comportamento esperado.

O teste de uma porta só faz sentido quando existe uma razão técnica para esperar que determinado serviço esteja disponível nela.

Portanto, antes de executar o comando, pergunte:

Qual serviço estou tentando testar?

Qual protocolo ele utiliza?

Qual porta está configurada?

Esse serviço deveria estar escutando nesse endereço?

Só depois execute o teste.

Essa pequena mudança transforma Test-NetConnection de um comando executado aleatoriamente em uma verdadeira ferramenta de diagnóstico.

O princípio mais importante deste guia

Se você lembrar de apenas uma coisa deste artigo, lembre-se desta:

Ping funcionando não significa que o serviço esteja funcionando.

Podemos ter:

Ping = OK
TCP 9100 = FALHA

ou:

Ping = OK
TCP 445 = FALHA

ou ainda:

Ping = BLOQUEADO
TCP 443 = OK

Sim, esse último cenário também pode acontecer.

Um equipamento ou firewall pode bloquear ICMP enquanto permite determinada conexão TCP.

Por isso, nem mesmo a ausência de resposta ao Ping prova, isoladamente, que o equipamento esteja inacessível para todos os serviços.

O diagnóstico correto depende da pergunta que estamos tentando responder.

E é exatamente aí que o Test-NetConnection se torna uma das ferramentas mais úteis do PowerShell para diagnosticar problemas de rede no Windows 11.

Test-NetConnection na prática: como interpretar os resultados e localizar a falha

Na primeira parte deste guia, vimos que o Test-NetConnection pode responder a uma pergunta que o Ping, sozinho, não consegue responder: determinada porta TCP está acessível a partir deste computador?

Agora vamos aprofundar essa análise.

Executar o comando é fácil. O verdadeiro valor está em saber interpretar o resultado.

Um técnico pode executar:

Test-NetConnection 192.168.1.150 -Port 9100

e simplesmente observar:

TcpTestSucceeded : False

Mas um diagnóstico profissional não deveria terminar nesse ponto.

Precisamos descobrir:

qual destino foi realmente utilizado;
qual endereço IP foi resolvido;
qual interface de rede o Windows escolheu;
qual endereço de origem foi utilizado;
qual porta foi testada;
se existe resposta ICMP;
se a conexão TCP foi estabelecida;
se o serviço deveria realmente estar disponível naquela porta.

Cada informação ajuda a eliminar hipóteses.

Entendendo a saída do Test-NetConnection

Vamos considerar um exemplo:

Test-NetConnection 192.168.1.150 -Port 9100

Dependendo da configuração do computador e da versão do PowerShell/Windows, a saída pode apresentar informações semelhantes a:

ComputerName     : 192.168.1.150
RemoteAddress    : 192.168.1.150
RemotePort       : 9100
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.25
TcpTestSucceeded : True

Cada campo possui uma função.

Não devemos olhar apenas para a última linha.

Vamos entender o que cada uma dessas informações representa.

ComputerName

O campo:

ComputerName

representa o destino informado para o teste.

Se executarmos:

Test-NetConnection 192.168.1.150 -Port 9100

o destino é o próprio endereço IP.

Mas também podemos utilizar:

Test-NetConnection impressora-escritorio -Port 9100

ou um nome DNS:

Test-NetConnection servidor.exemplo.local -Port 443

Quando utilizamos nomes, surge uma etapa adicional no diagnóstico: a resolução desse nome para um endereço IP.

Essa diferença é importante.

RemoteAddress

O campo:

RemoteAddress

mostra o endereço IP associado ao destino utilizado pelo teste.

Imagine:

Test-NetConnection servidor -Port 445

e a saída mostrar:

ComputerName  : servidor
RemoteAddress : 192.168.1.50

Agora sabemos que o nome servidor foi associado ao endereço 192.168.1.50 naquele contexto.

Essa informação pode revelar problemas que inicialmente parecem ser de rede.

Imagine que o endereço correto do servidor seja:

192.168.1.60

mas o Windows esteja tentando acessar:

192.168.1.50

O problema pode estar relacionado à resolução de nomes, a registros desatualizados ou a alguma configuração local.

Antes de culpar firewall, roteador ou cabo, confira sempre o destino real.

Testar nome e IP separadamente

Esse é um método simples e extremamente útil.

Primeiro:

Test-NetConnection servidor -Port 445

Depois:

Test-NetConnection 192.168.1.60 -Port 445

Agora compare.

Se o teste pelo nome falha e pelo endereço IP correto funciona, temos uma pista importante.

Podemos então investigar:

Resolve-DnsName servidor

e também, dependendo do ambiente:

nslookup servidor

Outra verificação importante é o arquivo hosts do Windows, porque uma entrada manual incorreta também pode direcionar determinado nome para um endereço inesperado.

O objetivo é simples:

separar problema de resolução de nomes de problema de conectividade.

RemotePort

Quando utilizamos:

-Port

a saída identifica a porta TCP que está sendo testada.

Por exemplo:

RemotePort : 9100

Esse campo parece óbvio, mas vale conferi-lo.

Durante diagnósticos longos é fácil testar uma porta diferente daquela realmente utilizada pelo serviço.

Um resultado:

TcpTestSucceeded : False

não tem utilidade se testamos a porta errada.

InterfaceAlias

Outro campo extremamente interessante é:

InterfaceAlias

Ele pode apresentar algo como:

InterfaceAlias : Wi-Fi

ou:

InterfaceAlias : Ethernet

Essa informação mostra qual interface está associada ao caminho escolhido para aquele destino.

Em um computador simples, isso pode parecer irrelevante.

Mas considere um notebook conectado simultaneamente por:

Wi-Fi;
Ethernet;
VPN;
adaptador virtual.

Agora a informação passa a ser importante.

Você pode acreditar que determinado tráfego está saindo pela Ethernet enquanto o Windows escolheu outro caminho.

SourceAddress

O campo:

SourceAddress

também merece atenção.

Imagine:

SourceAddress : 192.168.1.25

Esse é o endereço local associado à comunicação testada.

Agora considere um computador com várias interfaces:

Ethernet
192.168.1.25

Wi-Fi
192.168.50.20

VPN
10.20.0.15

Dependendo da tabela de rotas, métricas e destino, o Windows pode selecionar uma interface diferente daquela que o usuário imaginava.

O Test-NetConnection ajuda a revelar essa escolha.

Quando o Windows escolhe a interface errada

Imagine um servidor:

192.168.1.100

e um computador conectado simultaneamente a duas redes.

A comunicação deveria ocorrer pela Ethernet, mas uma rota adicionada por VPN ou software de virtualização altera o caminho.

O usuário vê:

Programa não conecta.

Ele pode suspeitar de:

servidor;
firewall;
antivírus;
programa;
senha.

Mas o problema pode estar na rota escolhida pelo Windows.

Nesse tipo de situação, além do Test-NetConnection, podemos utilizar:

route print

ou:

Get-NetRoute

Essas ferramentas permitem aprofundar a análise da tabela de roteamento.

Isso mostra por que diagnóstico de rede deve ser feito em etapas.

Um comando fornece a pista para o próximo.

PingSucceeded

Dependendo do teste executado, podemos encontrar informações relacionadas ao Ping, incluindo:

PingSucceeded

Quando disponível e verdadeiro, indica sucesso na verificação ICMP realizada pelo comando.

Mas não confunda:

PingSucceeded : True

com:

TcpTestSucceeded : True

São resultados diferentes.

Podemos encontrar situações como:

PingSucceeded    : True
TcpTestSucceeded : False

Essa combinação é extremamente útil para diagnóstico.

Cenário 1 — Ping funciona e TCP funciona

Imagine:

PingSucceeded    : True
TcpTestSucceeded : True

Isso indica que os testes realizados tiveram sucesso tanto na resposta ICMP quanto na tentativa de estabelecer a conexão TCP com a porta especificada.

Se o programa ainda não funciona, podemos começar a investigar níveis superiores.

Por exemplo:

autenticação;
credenciais;
certificado;
protocolo da aplicação;
configuração do software;
permissões;
driver;
serviço interno;
logs da aplicação.

Isso não significa que “a rede inteira está perfeita”.

Significa apenas que os testes realizados tiveram sucesso.

Essa forma de interpretar resultados evita conclusões excessivas.

Cenário 2 — Ping funciona e TCP falha

Agora temos:

PingSucceeded    : True
TcpTestSucceeded : False

Esse é um dos cenários mais interessantes.

Sabemos que o destino respondeu ao teste ICMP, mas a tentativa de conexão TCP com a porta especificada não foi bem-sucedida.

Podemos investigar:

porta correta;
serviço iniciado;
serviço escutando;
firewall;
regras de segurança;
configuração do equipamento;
ACL;
isolamento;
roteamento;
software de segurança.

Observe que a lista contém possibilidades.

Ainda não sabemos qual é a causa.

Cenário 3 — Ping falha e TCP funciona

Esse resultado costuma confundir usuários:

PingSucceeded    : False
TcpTestSucceeded : True

Dependendo da política de segurança da rede ou do equipamento, ICMP pode não responder enquanto determinado serviço TCP continua disponível.

Por isso, concluir:

“Não responde ao Ping, então está offline.”

pode ser incorreto.

Se o objetivo é acessar um servidor HTTPS e:

Test-NetConnection servidor -Port 443

indica sucesso TCP, temos uma informação muito mais relevante para aquele serviço específico do que simplesmente a ausência de resposta ICMP.

Cenário 4 — Ping falha e TCP falha

Agora temos uma situação mais ampla:

PingSucceeded    : False
TcpTestSucceeded : False

Ainda assim, não devemos imediatamente concluir:

“O equipamento está desligado.”

Podem existir várias causas.

Entre elas:

endereço incorreto;
equipamento desligado;
problema de rota;
VLAN;
firewall;
Wi-Fi isolado;
cabo desconectado;
gateway incorreto;
serviço indisponível;
política bloqueando ICMP e a porta testada;
dispositivo mudou de IP.

Precisamos continuar o diagnóstico.

TcpTestSucceeded False: o que verificar primeiro?

Quando encontramos:

TcpTestSucceeded : False

uma sequência lógica evita perda de tempo.

1. Confirme o endereço

Execute:

Test-NetConnection 192.168.1.150 -Port 9100

Confira se realmente está testando o equipamento correto.

Se estiver usando um nome, compare com o IP.

2. Confirme a porta

Pergunte:

esse serviço realmente utiliza essa porta?

Não presuma.

Uma impressora pode usar RAW 9100, IPP, IPPS, LPR ou outro mecanismo.

Um servidor web pode utilizar:

ou uma porta personalizada.

Um programa empresarial pode utilizar uma porta definida pelo fabricante ou pelo administrador.

Sem saber a porta correta, o teste perde valor.

3. Confirme se o serviço está funcionando

Se você possui acesso ao computador de destino, pode investigar se existe realmente um processo escutando naquela porta.

No PowerShell:

Get-NetTCPConnection -State Listen

Também podemos procurar uma porta específica:

Get-NetTCPConnection -LocalPort 445

quando isso for aplicável ao serviço e ao sistema analisado.

Outra ferramenta tradicional é:

netstat -ano

Por exemplo:

netstat -ano | findstr :443

A ideia é verificar se existe realmente um serviço esperando conexões naquela porta.

Porta fechada e firewall não são a mesma coisa

Essa distinção é fundamental.

Quando:

TcpTestSucceeded : False

não podemos dizer automaticamente:

“A porta está bloqueada pelo firewall.”

Pode simplesmente não existir nenhum serviço escutando naquela porta.

Considere:

Test-NetConnection 192.168.1.20 -Port 50000

Se nenhum serviço deveria utilizar a porta 50000, uma falha não representa necessariamente um defeito.

É apenas um teste sem um serviço correspondente.

Por isso, um diagnóstico sério sempre relaciona:

Aplicação → protocolo → porta → destino

Como saber se o servidor está escutando a porta?

Se o servidor também utiliza Windows e você possui acesso administrativo adequado, podemos verificar localmente.

Por exemplo:

Get-NetTCPConnection -State Listen

Isso lista conexões TCP em estado de escuta.

Para uma porta específica:

Get-NetTCPConnection -LocalPort 9100

Quando aplicável.

Também podemos usar:

netstat -ano

Uma saída pode apresentar algo semelhante a:

TCP    0.0.0.0:8080    0.0.0.0:0    LISTENING

Isso indica que existe um endpoint TCP em estado de escuta naquela porta.

O PID apresentado pelo netstat -ano também pode ser relacionado a um processo.

Por exemplo:

tasklist /fi "PID eq 1234"

Assim começamos a relacionar:

porta
↓
PID
↓
processo
↓
serviço/aplicação

Esse método é muito mais preciso do que desativar firewall, reinstalar programas ou reiniciar equipamentos aleatoriamente.

Testando localmente e remotamente

Existe uma técnica muito útil.

Imagine um servidor em:

192.168.1.100

que deveria oferecer um serviço na porta:

No próprio servidor, verificamos que existe um serviço escutando.

Depois, no computador cliente:

Test-NetConnection 192.168.1.100 -Port 8080

e encontramos:

TcpTestSucceeded : False

Agora temos uma situação mais específica.

Sabemos que existe um serviço localmente associado à porta, mas o cliente não consegue estabelecer a conexão testada.

A investigação pode então se concentrar no caminho entre cliente e servidor e nas políticas que controlam a comunicação.

Firewall do Windows: quando investigar

Se o serviço está ativo, a porta está correta e a conexão remota falha, o Firewall do Windows passa a ser uma hipótese importante.

Podemos consultar regras com:

Get-NetFirewallRule

Entretanto, existe um cuidado importante.

Não desative o firewall inteiro como primeiro teste

É comum encontrar tutoriais sugerindo:

“Desative o firewall para testar.”

Essa prática pode criar riscos e ainda produzir um diagnóstico ruim.

É melhor identificar:

qual aplicação;
qual protocolo;
qual porta;
qual perfil de rede;
qual regra deveria permitir o tráfego.

Depois verificar especificamente essa configuração.

Um diagnóstico deve reduzir variáveis, não remover toda a proteção do computador sem necessidade.

Perfil de rede também pode influenciar

O Windows classifica conexões em perfis, como:

Public
Private
DomainAuthenticated

Podemos verificar com:

Get-NetConnectionProfile

Em uma rede doméstica confiável, uma configuração incorreta como rede Pública pode fazer com que determinadas regras de firewall se comportem de maneira diferente da esperada.

Isso aparece bastante em problemas envolvendo:

descoberta de rede;
compartilhamento;
impressoras;
SMB;
serviços locais.

Mas novamente:

não altere o perfil apenas para “ver se funciona”.

Primeiro descubra o que está realmente impedindo a comunicação.

InformationLevel

O Test-NetConnection possui o parâmetro:

-InformationLevel

Ele pode ser útil para controlar o nível das informações apresentadas.

Por exemplo:

Test-NetConnection 192.168.1.150 -Port 9100 -InformationLevel Detailed

O modo detalhado ajuda durante investigações porque apresenta informações adicionais relacionadas ao teste.

Em determinadas situações também podemos querer apenas um resultado resumido.

Por exemplo:

Test-NetConnection 192.168.1.150 -Port 9100 -InformationLevel Quiet

Esse formato pode retornar simplesmente:

True

ou:

False

Isso é particularmente interessante em scripts.

Usando Test-NetConnection em scripts

Imagine que precisamos verificar periodicamente se determinado serviço TCP está acessível.

Podemos armazenar o resultado:

$resultado = Test-NetConnection 192.168.1.150 -Port 9100 -InformationLevel Quiet

Depois:

if ($resultado) {
    Write-Host "Porta acessível"
} else {
    Write-Host "Não foi possível estabelecer a conexão TCP"
}

Esse exemplo é simples, mas mostra uma característica importante.

Test-NetConnection não serve apenas para diagnóstico manual.

Ele também pode fazer parte de:

scripts;
verificações automatizadas;
rotinas de suporte;
validações antes da execução de outros processos.

É importante, entretanto, não transformar False automaticamente em mensagens como “firewall bloqueando”.

O script deve relatar aquilo que realmente sabe.

Testando várias portas

Durante um diagnóstico podemos precisar verificar vários serviços.

Por exemplo:

Test-NetConnection 192.168.1.20 -Port 80
Test-NetConnection 192.168.1.20 -Port 443
Test-NetConnection 192.168.1.20 -Port 445

Ou utilizar PowerShell para automatizar:

80,443,445 | ForEach-Object {
    Test-NetConnection 192.168.1.20 -Port $_ -InformationLevel Quiet
}

Para um diagnóstico mais útil, podemos mostrar a porta junto ao resultado:

80,443,445 | ForEach-Object {
    [PSCustomObject]@{
        Porta = $_
        Acessivel = Test-NetConnection 192.168.1.20 -Port $_ -InformationLevel Quiet
    }
}

Assim obtemos uma pequena tabela.

Mas existe uma regra importante:

não faça varreduras indiscriminadas em redes ou sistemas que você não administra ou não possui autorização para testar.

Em assistência técnica, concentre os testes nos serviços relacionados ao problema que está sendo investigado.

Test-NetConnection e TraceRoute

O comando também pode ajudar na análise do caminho até determinado destino.

Podemos utilizar:

Test-NetConnection exemplo.com -TraceRoute

O conceito se aproxima do que fazemos tradicionalmente com:

tracert exemplo.com

A análise de rota pode ajudar quando o destino está além da rede local.

Por exemplo:

Computador
↓
Roteador
↓
Operadora
↓
Rede intermediária
↓
Destino

Mas existe uma limitação importante:

um salto que não responde durante o rastreamento não significa necessariamente que aquele roteador esteja com defeito.

Equipamentos intermediários podem limitar, priorizar ou simplesmente não responder a determinadas mensagens utilizadas nesse tipo de diagnóstico.

Portanto, TraceRoute também exige interpretação.

Quando o TraceRoute é útil

Imagine:

Test-NetConnection servidor-remoto.exemplo -Port 443

retornando falha.

Primeiro verificamos DNS.

Depois conectividade.

Em seguida podemos analisar o caminho:

Test-NetConnection servidor-remoto.exemplo -TraceRoute

ou:

tracert servidor-remoto.exemplo

Isso pode fornecer pistas sobre o caminho utilizado.

Porém, não use o rastreamento como uma prova absoluta de onde ocorre uma falha TCP.

Para investigações mais profundas, outras ferramentas podem ser necessárias.

Test-NetConnection, Tracert e Pktmon

Aqui podemos conectar este artigo a outras ferramentas de diagnóstico do Windows.

Cada uma responde a perguntas diferentes.

Ping

ping destino

Pergunta principal:

o destino responde às solicitações ICMP utilizadas no teste?

Test-NetConnection

Test-NetConnection destino -Port 443

Pergunta principal:

é possível estabelecer a conexão TCP testada com essa porta?

Tracert

tracert destino

Ajuda a observar o caminho de rede até o destino.

Pktmon

Permite avançar para uma análise de pacotes e eventos de rede no próprio Windows.

Assim podemos criar uma escalada de diagnóstico:

Ping
↓
Test-NetConnection
↓
Tracert
↓
Pktmon

Não significa que essa sequência precisa ser seguida em todos os casos.

O técnico deve escolher a ferramenta de acordo com a pergunta que precisa responder.

Diagnóstico prático: impressora responde ao Ping, mas não imprime

Vamos juntar os conceitos.

Impressora:

192.168.1.150

Primeiro:

ping 192.168.1.150

Resultado:

Resposta recebida normalmente

Agora precisamos descobrir como a impressora está instalada.

Suponha que o Windows esteja utilizando uma Standard TCP/IP Port configurada como:

RAW
9100

Testamos:

Test-NetConnection 192.168.1.150 -Port 9100

Resultado A

TcpTestSucceeded : True

Agora sabemos que a conexão TCP testada na porta 9100 foi estabelecida.

O diagnóstico pode avançar para:

fila de impressão;
spooler;
driver;
configuração da porta;
linguagem de impressão;
status da impressora;
trabalho travado;
aplicação que está imprimindo.

Resultado B

TcpTestSucceeded : False

Agora a investigação muda.

Precisamos verificar:

a impressora realmente utiliza RAW 9100?
a porta configurada no Windows está correta?
o IP ainda pertence à impressora?
existe algum isolamento na rede?
o equipamento aceita conexões naquela porta?
alguma política está bloqueando a comunicação?

Essa divisão evita reinstalar o driver sem antes verificar a conectividade utilizada pelo próprio serviço.

Diagnóstico prático: compartilhamento não abre

Servidor:

192.168.1.20

Ping:

ping 192.168.1.20

Funciona.

Teste:

Test-NetConnection 192.168.1.20 -Port 445

Se:

TcpTestSucceeded : False

investigamos primeiro a disponibilidade da comunicação SMB.

Se:

TcpTestSucceeded : True

mas:

\\192.168.1.20\Dados

não abre, precisamos avançar para questões relacionadas ao compartilhamento e à aplicação do protocolo, como:

credenciais;
permissões NTFS;
permissões de compartilhamento;
política SMB;
usuário;
nome do compartilhamento.

O teste TCP ajudou a eliminar uma parte do problema.

Diagnóstico prático: Área de Trabalho Remota

Computador remoto:

192.168.1.30

Teste:

Test-NetConnection 192.168.1.30 -Port 3389

Se:

TcpTestSucceeded : False

investigamos a disponibilidade do serviço e o caminho até a porta.

Se:

TcpTestSucceeded : True

mas o RDP continua apresentando erro, o problema pode estar em outra etapa.

Por exemplo:

autenticação;
credenciais;
permissões do usuário;
configuração do RDP;
políticas;
NLA;
sessão;
certificado.

Novamente:

TCP funcionando não significa que toda a aplicação esteja funcionando.

Significa que uma etapa importante do diagnóstico foi vencida.

O método VMIA para interpretar Test-NetConnection

Podemos resumir o processo da seguinte maneira:

1. Qual é o problema?
        ↓
2. Qual serviço está envolvido?
        ↓
3. Qual destino ele utiliza?
        ↓
4. Qual porta TCP ele utiliza?
        ↓
5. O nome resolve para o IP correto?
        ↓
6. O Test-NetConnection consegue estabelecer a conexão?
        ↓
7. Qual interface e endereço de origem estão sendo usados?
        ↓
8. O serviço está realmente escutando no destino?
        ↓
9. Existe alguma regra ou dispositivo impedindo o tráfego?
        ↓
10. Se TCP funciona, investigar a aplicação.

Essa sequência é muito mais eficiente do que:

Não funciona
↓
Reinicia
↓
Reinstala
↓
Desativa firewall
↓
Troca driver
↓
Formata

Diagnóstico técnico deve ser baseado em evidências.

Cada comando deve responder a uma pergunta.

Test-NetConnection não resolve o problema sozinho

Essa talvez seja a conclusão mais importante desta parte.

O Test-NetConnection não é uma ferramenta que informa:

"Seu roteador está com defeito."

Ele também não informa automaticamente:

"O firewall está bloqueando."

ou:

"O driver da impressora está corrompido."

O comando produz evidências.

Cabe ao técnico relacionar essas evidências ao funcionamento esperado da rede.

Um:

TcpTestSucceeded : False

é o começo de uma investigação.

Não é o diagnóstico completo.

Da mesma forma:

TcpTestSucceeded : True

não prova que a aplicação inteira esteja funcionando.

Ele demonstra o sucesso do teste TCP realizado naquele destino e naquela porta.

Essa precisão é importante porque evita conclusões erradas e torna o diagnóstico muito mais confiável.

Nas partes anteriores, vimos que o Test-NetConnection é especialmente útil quando precisamos descobrir se determinada porta TCP está acessível a partir de um computador com Windows.

Agora vamos avançar para uma etapa mais completa.

O objetivo não é apenas executar:

Test-NetConnection 192.168.1.100 -Port 443

e olhar para:

TcpTestSucceeded : True

ou:

TcpTestSucceeded : False

O objetivo é saber o que fazer depois.

Em um diagnóstico real, raramente existe apenas uma ferramenta. O Test-NetConnection funciona melhor quando combinado com comandos que ajudam a descobrir:

qual processo utiliza determinada porta;
se o serviço está escutando;
qual rota está sendo usada;
se uma VPN está alterando o caminho;
qual interface o Windows selecionou;
se o problema está na rede ou na aplicação;
se o equipamento realmente utiliza a porta que você decidiu testar.

Test-NetConnection versus Telnet

Durante muitos anos, o Telnet foi utilizado para testar conectividade com portas TCP.

Um exemplo clássico seria:

telnet 192.168.1.100 443

O problema é que o cliente Telnet normalmente não vem habilitado por padrão no Windows moderno.

Além disso, sua saída não é tão amigável para diagnóstico quanto a do Test-NetConnection.

Com PowerShell:

Test-NetConnection 192.168.1.100 -Port 443

podemos receber informações adicionais sobre:

endereço remoto;
porta;
interface;
endereço local;
resultado TCP.

Por isso, para testes básicos de conectividade TCP no Windows 11, Test-NetConnection costuma ser uma opção mais conveniente.

Test-NetConnection versus curl

O Windows moderno também inclui o curl, que pode ser extremamente útil.

Mas Test-NetConnection e curl não respondem exatamente à mesma pergunta.

Considere:

Test-NetConnection exemplo.com -Port 443

Esse comando verifica se a conexão TCP testada pode ser estabelecida com a porta 443.

Agora:

curl https://exemplo.com

vai muito além.

O curl pode participar da comunicação HTTP ou HTTPS, negociar TLS e receber uma resposta da aplicação.

Portanto, imagine:

Test-NetConnection 443 = True
curl = erro

Esse resultado pode indicar que a porta TCP está acessível, mas existe problema em uma etapa posterior.

Por exemplo:

TLS;
certificado;
proxy;
autenticação;
aplicação web;
cabeçalhos;
servidor HTTP.

Essa é uma excelente demonstração do conceito de diagnóstico por camadas.

Test-NetConnection versus PortQry

Outra ferramenta conhecida em ambientes Windows é o PortQry.

Ela pode fornecer informações adicionais em diagnósticos específicos, incluindo análise de portas TCP e UDP.

O Test-NetConnection, entretanto, possui a vantagem de já estar integrado ao PowerShell em muitas instalações do Windows.

Para uma verificação rápida:

Test-NetConnection servidor -Port 445

é simples e direto.

Para análises mais específicas, outras ferramentas podem ser utilizadas conforme a necessidade.

O importante é não tentar fazer uma única ferramenta responder todas as perguntas.

TCP e UDP não são a mesma coisa

Esse ponto merece destaque.

O Test-NetConnection é especialmente útil para testes de conectividade TCP utilizando o parâmetro:

-Port

Isso não significa que ele seja uma ferramenta genérica para validar qualquer serviço de rede.

Muitos protocolos utilizam UDP.

Nesses casos, um teste TCP não representa o funcionamento real do protocolo.

Antes de executar qualquer diagnóstico, descubra:

Aplicação
↓
Protocolo
↓
TCP ou UDP
↓
Porta

Sem essa informação, podemos testar algo que não corresponde ao serviço real.

Como descobrir qual porta um programa usa?

Essa é uma das perguntas mais importantes em suporte técnico.

Imagine que um programa não conecta ao servidor.

Antes de executar:

Test-NetConnection servidor -Port XXXXX

precisamos descobrir qual porta deveria ser usada.

Existem várias maneiras.

A primeira é consultar a documentação oficial do software.

Essa costuma ser a melhor fonte.

Também podemos investigar as conexões abertas pelo próprio programa.

Get-NetTCPConnection

O PowerShell possui:

Get-NetTCPConnection

Esse comando permite visualizar conexões TCP presentes no sistema.

Uma saída pode incluir estados como:

Listen
Established
TimeWait
CloseWait

Para suporte técnico, dois estados são especialmente interessantes:

Listen
Established

O que significa Listen?

Quando uma porta aparece em estado:

Listen

significa que existe um endpoint esperando conexões naquele endereço e porta.

Por exemplo:

Get-NetTCPConnection -State Listen

Pode aparecer algo semelhante a:

LocalAddress LocalPort State
------------ --------- -----
0.0.0.0      445       Listen

Isso indica que existe um listener TCP relacionado àquela porta.

Mas ainda precisamos descobrir qual processo está associado a ele.

O que significa Established?

Uma conexão em:

Established

indica uma sessão TCP estabelecida naquele momento.

Podemos consultar:

Get-NetTCPConnection -State Established

Imagine encontrar:

LocalAddress  LocalPort  RemoteAddress  RemotePort
192.168.1.25  52110      192.168.1.100  443

Agora sabemos que existe uma conexão entre o computador local e:

192.168.1.100:443

Isso pode ajudar a descobrir quais destinos e portas um programa está utilizando.

Relacionando conexão e processo

Get-NetTCPConnection possui informações que permitem relacionar a conexão ao processo responsável.

Por exemplo:

Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess

Podemos encontrar:

OwningProcess : 5420

Esse número corresponde ao PID.

Depois:

Get-Process -Id 5420

Assim obtemos o processo correspondente.

Criamos então uma cadeia muito útil:

Programa
↓
PID
↓
Conexão TCP
↓
Destino
↓
Porta

Agora sabemos exatamente o que testar.

Usando netstat para descobrir portas

O tradicional:

netstat -ano

continua muito útil.

A opção:

-a

exibe conexões e portas em escuta.

A opção:

-n

exibe endereços e portas numericamente.

A opção:

-o

mostra o PID do processo.

Podemos filtrar:

netstat -ano | findstr ESTABLISHED

ou:

netstat -ano | findstr LISTENING

Também podemos procurar determinada porta:

netstat -ano | findstr :9100

ou:

netstat -ano | findstr :443

Depois identificamos o PID:

tasklist /fi "PID eq 5420"

Esse método continua excelente para diagnóstico.

Como descobrir se a aplicação está tentando conectar

Existe um cenário muito interessante.

O usuário diz:

“O programa tenta conectar ao servidor e dá erro.”

Podemos abrir:

netstat -ano

ou utilizar:

Get-NetTCPConnection

enquanto tentamos reproduzir o problema.

Se aparecer uma conexão para:

203.0.113.50:443

agora temos um destino concreto.

Podemos testar:

Test-NetConnection 203.0.113.50 -Port 443

Se o teste TCP funciona, mas o aplicativo falha, precisamos investigar níveis superiores.

Se o teste também falha, o problema pode estar na conectividade necessária para aquela aplicação.

Quando uma VPN altera tudo

VPNs podem tornar diagnósticos de rede bastante confusos.

Imagine um notebook conectado:

Wi-Fi
192.168.1.25

e também a uma VPN:

VPN
10.10.20.15

Dependendo da configuração, a VPN pode adicionar rotas ao Windows.

Agora o tráfego para determinado servidor pode sair pelo túnel VPN.

Um Test-NetConnection pode revelar:

InterfaceAlias : VPN Corporativa
SourceAddress  : 10.10.20.15

Mesmo que o usuário esteja conectado ao Wi-Fi normalmente.

Isso ajuda a explicar situações como:

Sem VPN funciona.
Com VPN não funciona.

ou:

Com VPN funciona.
Sem VPN não funciona.

Split tunnel e full tunnel

Em uma VPN com configuração semelhante a full tunnel, grande parte do tráfego pode ser enviada pelo túnel.

Em ambientes com split tunnel, apenas determinadas redes são direcionadas pela VPN.

Essa diferença pode alterar:

rota;
DNS;
acesso local;
impressoras;
servidores;
Internet.

Por isso, quando um problema aparece somente com VPN conectada, compare:

Test-NetConnection destino -Port porta

com a VPN ligada e desligada.

Observe especialmente:

InterfaceAlias
SourceAddress
RemoteAddress

As diferenças podem revelar a causa.

VPN pode impedir acesso à impressora local?

Sim, dependendo da configuração.

Imagine uma impressora doméstica:

192.168.1.150

Sem VPN:

Test-NetConnection 192.168.1.150 -Port 9100

resultado:

True

Com VPN:

False

Isso pode indicar que a VPN está interferindo no caminho até a rede local.

Algumas VPNs possuem opções de segurança que restringem acesso à LAN enquanto o túnel está ativo.

Nesse cenário, reinstalar a impressora não resolve a causa.

Duas interfaces de rede simultâneas

Outra situação comum ocorre quando o computador está conectado por Ethernet e Wi-Fi ao mesmo tempo.

Por exemplo:

Ethernet
192.168.1.20

Wi-Fi
192.168.1.30

Em teoria, o Windows seleciona a rota mais adequada com base na tabela de roteamento e métricas.

Na prática, problemas de configuração podem causar caminhos inesperados.

Podemos observar:

Test-NetConnection 192.168.1.150 -Port 9100

e conferir:

InterfaceAlias
SourceAddress

Se o tráfego utiliza uma interface inesperada, devemos investigar métricas e rotas.

Consultando as rotas

No Prompt de Comando:

route print

No PowerShell:

Get-NetRoute

Esses comandos mostram as rotas conhecidas pelo Windows.

Uma rota possui elementos como:

rede de destino;
prefixo;
gateway;
interface;
métrica.

O Windows utiliza essas informações para decidir para onde enviar cada pacote.

A rota padrão

Em redes domésticas, normalmente existe uma rota padrão representada por:

0.0.0.0/0

Ela indica o caminho utilizado quando não existe uma rota mais específica para determinado destino.

Normalmente, essa rota aponta para o gateway da rede.

Por exemplo:

Gateway:
192.168.1.1

Mas uma VPN pode instalar outra rota padrão ou rotas mais específicas.

Por isso, problemas de conectividade podem surgir apenas após determinado software ser instalado.

Rota mais específica vence

O Windows tende a preferir rotas mais específicas para determinado destino.

Imagine:

0.0.0.0/0

e outra rota:

192.168.1.0/24

Para alcançar:

192.168.1.150

a rota /24 é mais específica.

Se essa rota estiver apontando para uma interface incorreta, o tráfego pode seguir por um caminho inesperado.

Essa situação é especialmente relevante em:

VPN;
Hyper-V;
máquinas virtuais;
Docker;
softwares de virtualização;
redes corporativas complexas.

Test-NetConnection e redes Mesh

Em redes Wi-Fi Mesh, é comum o usuário imaginar que todos os dispositivos conectados estão necessariamente na mesma rede lógica.

Nem sempre.

Dependendo da configuração, podem existir:

rede principal;
rede de convidados;
isolamento de clientes;
VLAN;
modo roteador;
modo Access Point;
múltiplos NATs.

Imagine:

Computador:
192.168.1.20

Impressora:
192.168.50.30

Agora já temos uma pista de que os equipamentos podem estar em redes diferentes.

O Ping pode falhar.

O Test-NetConnection também pode falhar.

O problema pode não estar na impressora.

Pode estar na arquitetura da rede.

Rede de convidados e isolamento

Muitos roteadores possuem uma rede Guest.

Ela pode fornecer Internet normalmente, mas impedir comunicação entre dispositivos locais.

Nesse cenário:

Internet = funciona
Google = funciona
Streaming = funciona
Impressora local = não funciona

Um usuário pode pensar:

“O Wi-Fi está funcionando, então a impressora deveria funcionar.”

Não necessariamente.

A rede pode permitir acesso à Internet e bloquear comunicação lateral entre clientes.

Testando dois computadores da mesma rede

Imagine:

PC A
192.168.1.20

PC B
192.168.1.30

No PC A:

Test-NetConnection 192.168.1.30 -Port 445

Agora fazemos o inverso no PC B:

Test-NetConnection 192.168.1.20 -Port 445

Os resultados podem ser diferentes.

Isso é importante.

Firewall e serviços podem estar configurados de maneira diferente em cada máquina.

Por isso, conectividade em um sentido não garante necessariamente comportamento idêntico no sentido oposto.

Teste local versus teste remoto

Esse é um método excelente para descobrir onde a falha pode estar.

Imagine que um servidor deveria utilizar:

TCP 8080

No próprio servidor verificamos que existe listener.

Localmente, podemos testar o serviço.

Depois, em outro computador:

Test-NetConnection servidor -Port 8080

Se localmente funciona e remotamente não, a investigação passa a se concentrar em:

firewall;
ACL;
rede;
roteamento;
interface de escuta;
dispositivo intermediário.

Serviço escutando apenas em localhost

Esse detalhe pode causar problemas interessantes.

Um programa pode estar escutando em:

127.0.0.1:8080

Nesse caso, ele está disponível localmente.

Mas pode não estar acessível através do endereço de rede:

192.168.1.100:8080

Isso explica situações em que:

No servidor funciona.
De outro PC não funciona.

O problema pode estar na interface à qual o serviço foi associado.

0.0.0.0 e escuta em várias interfaces

Quando uma aplicação aparece escutando em:

0.0.0.0:8080

isso normalmente indica uma escuta associada a todas as interfaces IPv4 relevantes.

Já:

127.0.0.1:8080

fica restrita ao loopback.

Também podemos encontrar uma aplicação associada diretamente a:

192.168.1.100:8080

Essas diferenças são importantes quando o servidor possui várias interfaces.

IPv4 versus IPv6

Outro fator que pode confundir testes é a coexistência de IPv4 e IPv6.

Imagine que um nome resolva para mais de um endereço.

Podemos ter:

IPv4
192.168.1.100

IPv6
2001:db8::100

Dependendo da configuração e do destino, o Windows pode tentar utilizar IPv6.

Isso pode gerar uma situação em que:

Teste pelo nome = falha
Teste pelo IPv4 = funciona

Nesse caso, a investigação deve considerar resolução DNS e conectividade IPv6.

Não é recomendável simplesmente desativar IPv6 como primeira tentativa.

Primeiro descubra qual protocolo está sendo utilizado e por que ele falha.

DNS correto é parte do diagnóstico

Imagine:

Test-NetConnection servidor.exemplo -Port 443

RemoteAddress : endereço inesperado

Antes de testar firewall, verifique:

Resolve-DnsName servidor.exemplo

Podemos também comparar com:

nslookup servidor.exemplo

Em redes corporativas, diferentes servidores DNS podem fornecer respostas distintas.

VPNs também podem alterar servidores DNS.

O arquivo hosts

Outro elemento que merece atenção é:

C:\Windows\System32\drivers\etc\hosts

Uma entrada manual pode sobrescrever a resolução normal de determinado nome.

Por exemplo:

192.168.1.50 servidor

Se o servidor mudou para:

192.168.1.60

o computador pode continuar tentando acessar o endereço antigo.

Isso pode gerar:

Nome não funciona.
IP funciona.

Firewall local versus firewall remoto

Quando uma conexão TCP falha, precisamos lembrar que o bloqueio pode existir em diferentes pontos.

Podemos ter:

Cliente
↓
Firewall local
↓
Roteador
↓
Firewall intermediário
↓
Servidor
↓
Firewall remoto
↓
Aplicação

Por isso:

TcpTestSucceeded : False

não identifica automaticamente qual componente interrompeu a comunicação.

Precisamos comparar evidências.

Windows Defender Firewall

No Windows podemos utilizar:

Get-NetFirewallRule

e comandos relacionados para consultar regras.

Também podemos observar regras habilitadas:

Get-NetFirewallRule -Enabled True

Entretanto, a quantidade de regras pode ser grande.

O ideal é relacionar a investigação ao serviço específico.

Pergunte:

qual programa?
qual porta?
TCP ou UDP?
entrada ou saída?
qual perfil?
qual interface?

Firewall de saída também pode bloquear

Muitos usuários associam firewall apenas a conexões de entrada.

Mas regras de saída também podem impedir comunicação.

Imagine:

Cliente → servidor:443

O servidor pode estar perfeitamente configurado.

Mas uma regra local pode impedir o cliente de iniciar a conexão.

Por isso, o diagnóstico deve considerar os dois lados.

Antivírus e soluções de segurança

Alguns produtos de segurança adicionam filtros de rede.

Isso significa que uma falha pode não estar diretamente no Windows Defender Firewall.

Pode existir:

firewall de terceiros;
inspeção HTTPS;
filtro web;
controle de aplicações;
EDR;
VPN corporativa.

A melhor estratégia não é sair desativando todos os produtos.

Primeiro identifique o padrão da falha.

Proxy também pode confundir o diagnóstico

Imagine que:

Test-NetConnection site.exemplo -Port 443

funcione.

Mas o navegador não abre o site.

Nesse caso, talvez o navegador esteja utilizando um proxy.

O teste TCP direto e a comunicação da aplicação podem seguir caminhos diferentes.

Isso reforça a regra:

Test-NetConnection valida um aspecto específico da conectividade.

Ele não valida toda a configuração de uma aplicação.

Tabela prática de portas comuns

A tabela abaixo serve como referência inicial.

Porta	Protocolo/uso comum	Exemplo de teste
21	FTP controle	`Test-NetConnection servidor -Port 21`
22	SSH	`Test-NetConnection servidor -Port 22`
25	SMTP	`Test-NetConnection servidor -Port 25`
53	DNS TCP em situações específicas	`Test-NetConnection dns -Port 53`
80	HTTP	`Test-NetConnection site -Port 80`
110	POP3	`Test-NetConnection servidor -Port 110`
143	IMAP	`Test-NetConnection servidor -Port 143`
443	HTTPS	`Test-NetConnection site -Port 443`
445	SMB	`Test-NetConnection servidor -Port 445`
587	SMTP Submission	`Test-NetConnection servidor -Port 587`
993	IMAPS	`Test-NetConnection servidor -Port 993`
995	POP3S	`Test-NetConnection servidor -Port 995`
3389	RDP em configuração padrão	`Test-NetConnection PC -Port 3389`
9100	Impressão RAW comum	`Test-NetConnection impressora -Port 9100`

Essa tabela não significa que todos os equipamentos utilizem essas portas obrigatoriamente.

Serviços podem ser configurados em portas diferentes.

O que True realmente significa

Considere:

TcpTestSucceeded : True

O que podemos concluir?

Podemos dizer:

A tentativa de estabelecer a conexão TCP testada com aquele destino e porta foi bem-sucedida.

Isso é preciso.

O que não podemos dizer automaticamente:

A aplicação está perfeita.
O servidor está saudável.
A Internet está perfeita.
O firewall não possui nenhum problema.
O programa está funcionando.

True valida apenas aquela etapa.

O que False realmente significa

Agora:

TcpTestSucceeded : False

Podemos dizer:

Não foi possível estabelecer a conexão TCP testada com aquele destino e porta.

Não devemos concluir automaticamente:

Firewall bloqueou.
Roteador está com defeito.
Servidor caiu.
Porta está quebrada.

Precisamos continuar investigando.

Erro de interpretação 1 — Ping funciona, então a rede está boa

Esse é provavelmente o erro mais comum.

Ping funcionando significa apenas que o teste ICMP recebeu resposta.

Não prova que:

SMB funciona
RDP funciona
HTTPS funciona
RAW 9100 funciona
Aplicação funciona

Erro de interpretação 2 — Ping falhou, então o servidor caiu

Também incorreto.

ICMP pode estar bloqueado.

Teste o serviço real.

Por exemplo:

Test-NetConnection servidor -Port 443

Se retornar:

True

o servidor pode estar acessível para HTTPS mesmo sem responder ao Ping.

Erro de interpretação 3 — False significa firewall

Não necessariamente.

Pode ser:

serviço parado;
porta incorreta;
IP errado;
rota;
VLAN;
VPN;
isolamento;
listener apenas local;
equipamento desligado;
firewall.

Erro de interpretação 4 — True significa aplicação funcionando

Também não.

Uma conexão TCP pode ser estabelecida e a aplicação ainda falhar.

Exemplos:

senha errada;
certificado inválido;
autenticação;
erro HTTP;
driver;
protocolo incompatível;
configuração interna.

Erro de interpretação 5 — testar portas aleatórias

Executar:

Test-NetConnection IP -Port 12345

sem saber se algum serviço utiliza a porta 12345 quase não oferece informação útil.

O teste deve sempre responder uma pergunta específica.

Procedimento completo para diagnóstico

Podemos montar um método prático.

Etapa 1 — Identifique o problema

Evite descrições vagas como:

"A rede não funciona."

Prefira:

"Este computador não consegue imprimir na impressora 192.168.1.150 usando RAW 9100."

Agora o problema está definido.

Etapa 2 — Identifique o destino

Descubra:

IP
nome
servidor
impressora
serviço

Confirme se o endereço está correto.

Etapa 3 — Descubra o protocolo

Pergunte:

TCP ou UDP?

Test-NetConnection com -Port é útil para TCP.

Etapa 4 — Descubra a porta

Consulte:

documentação;
configuração do programa;
configuração da impressora;
Get-NetTCPConnection;
netstat.

Etapa 5 — Teste resolução de nomes

Se utiliza nome:

Resolve-DnsName servidor

Compare com o IP esperado.

Etapa 6 — Teste a conectividade TCP

Test-NetConnection servidor -Port 443

Observe:

RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Etapa 7 — Compare por IP

Se o teste pelo nome falha:

Test-NetConnection 192.168.1.100 -Port 443

Se o IP funciona e o nome não, investigue DNS.

Etapa 8 — Verifique o servidor

No destino:

Get-NetTCPConnection -State Listen

ou:

netstat -ano

Confirme se existe listener.

Etapa 9 — Relacione ao processo

Use o PID para descobrir qual aplicação está usando a porta.

Etapa 10 — Verifique firewall e regras

Somente depois de confirmar:

destino correto
porta correta
serviço correto

faz sentido investigar regras de segurança.

Etapa 11 — Verifique rota e interface

Observe:

InterfaceAlias
SourceAddress

Depois:

route print

ou:

Get-NetRoute

Etapa 12 — Considere VPN e virtualização

Se houver:

VPN;
Hyper-V;
VirtualBox;
VMware;
Docker;
adaptadores virtuais;

verifique se alguma rota foi modificada.

Etapa 13 — Se TCP funciona, suba para a aplicação

Se:

TcpTestSucceeded : True

mas o problema continua, investigue:

autenticação;
protocolo;
certificados;
aplicação;
driver;
logs;
permissões.

Exemplo completo: impressora

Problema:

Impressora responde ao Ping, mas não imprime.

Descobrimos:

IP: 192.168.1.150
Porta Windows: Standard TCP/IP Port
Protocolo: RAW
Porta: 9100

Primeiro:

ping 192.168.1.150

Funciona.

Depois:

Test-NetConnection 192.168.1.150 -Port 9100

Se False

Investigamos:

IP correto?
RAW realmente habilitado?
9100 correta?
Rede Guest?
VPN?
Firewall?
Roteamento?
Equipamento aceita RAW?

Se True

Investigamos:

Spooler
Fila
Driver
Porta configurada
Status da impressora
Documento
Aplicação

O diagnóstico agora possui lógica.

Exemplo completo: servidor SMB

Problema:

\\servidor\arquivos não abre

Primeiro:

Resolve-DnsName servidor

Depois:

Test-NetConnection servidor -Port 445

Se False:

investigar conectividade SMB

Se True:

investigar credenciais, permissões e compartilhamento

Exemplo completo: site HTTPS

Problema:

Sistema web não abre.

Primeiro:

Resolve-DnsName sistema.exemplo.com

Depois:

Test-NetConnection sistema.exemplo.com -Port 443

Se True:

curl https://sistema.exemplo.com

Agora podemos diferenciar:

DNS
TCP
TLS
HTTP
Aplicação

Essa divisão é muito mais poderosa do que simplesmente dizer:

"O site caiu."

Exemplo completo: RDP

Problema:

Não consigo acessar o computador remoto.

Teste:

Test-NetConnection 192.168.1.50 -Port 3389

Se False:

verificar serviço, firewall, rota, porta e configuração do RDP

Se True:

verificar autenticação, usuário, política, NLA e sessão

Quando usar Pktmon depois do Test-NetConnection

Se os testes simples não forem suficientes, podemos avançar.

Por exemplo:

Test-NetConnection falha
Rota parece correta
Serviço está ativo
Firewall aparentemente permite

Nesse ponto, uma análise de pacotes pode ajudar.

O Windows inclui o Pktmon, que pode fornecer informações adicionais sobre o tráfego.

Assim criamos uma sequência racional:

Ping
↓
Test-NetConnection
↓
Get-NetTCPConnection
↓
Route Print
↓
Pktmon
↓
Logs

Cada ferramenta aumenta o nível de detalhe.

Test-NetConnection é simples, mas poderoso

O comando parece pequeno:

Test-NetConnection servidor -Port 443

Mas sua utilidade aumenta muito quando entendemos exatamente qual pergunta ele responde.

Ele permite separar:

destino acessível

de:

serviço TCP acessível

E também ajuda a separar:

problema de rede

de:

problema de aplicação

Essa diferença economiza tempo em suporte técnico.

Diagnóstico não é tentativa e erro

Quando uma conexão falha, é comum encontrar procedimentos como:

reiniciar
reinstalar
formatar
trocar driver
desativar firewall
trocar roteador

Algumas dessas ações podem até resolver determinados problemas.

Mas, sem diagnóstico, não sabemos por quê.

O objetivo de ferramentas como Test-NetConnection é transformar o processo em algo baseado em evidências.

Começamos perguntando:

Qual serviço falhou?

Depois:

Qual porta ele utiliza?

Depois:

A porta está acessível?

Depois:

O serviço está escutando?

Depois:

Qual rota está sendo utilizada?

Depois:

A aplicação está respondendo corretamente?

Essa sequência é mais eficiente, mais segura e mais fácil de documentar.

Conclusão

O Test-NetConnection é uma das ferramentas mais úteis disponíveis no PowerShell para diagnóstico de conectividade no Windows 11.

Seu maior valor aparece quando entendemos que rede não é simplesmente:

Ping funciona

ou:

Ping não funciona

Uma aplicação depende de diferentes componentes.

Podemos ter:

DNS
↓
Roteamento
↓
TCP
↓
TLS
↓
Aplicação

Cada etapa pode funcionar ou falhar independentemente.

O Test-NetConnection ajuda principalmente a investigar a etapa de conectividade TCP.

Com:

Test-NetConnection destino -Port porta

podemos descobrir se o computador conseguiu estabelecer a conexão TCP testada.

A partir desse resultado, podemos decidir qual deve ser o próximo passo.

Se o teste falha, investigamos destino, porta, serviço, firewall, rota, VPN e infraestrutura.

Se o teste funciona, podemos avançar para autenticação, protocolo, aplicação, driver e demais componentes.

O segredo não está em decorar comandos.

Está em saber qual pergunta cada comando consegue responder.

É essa lógica que transforma ferramentas simples do Windows em um verdadeiro método de diagnóstico.

FAQ — Perguntas frequentes sobre Test-NetConnection no Windows 11

O que é o Test-NetConnection no Windows 11?

O Test-NetConnection é um cmdlet do PowerShell usado para testar diferentes aspectos da conectividade de rede.

Ele pode ajudar a verificar resolução de nomes, endereço remoto, interface utilizada, endereço local de origem, resposta ICMP e, principalmente, conectividade TCP com uma porta específica.

Um dos usos mais comuns é:

Test-NetConnection 192.168.1.100 -Port 443

Nesse exemplo, o Windows tenta estabelecer uma conexão TCP com a porta 443 do endereço informado.

Qual é a diferença entre Ping e Test-NetConnection?

O Ping utiliza ICMP para testar comunicação com o destino.

Já o Test-NetConnection pode testar uma porta TCP específica.

Por exemplo:

ping 192.168.1.150

pode funcionar enquanto:

Test-NetConnection 192.168.1.150 -Port 9100

retorna:

TcpTestSucceeded : False

Isso significa que o equipamento respondeu ao teste ICMP, mas a conexão TCP testada na porta 9100 não foi estabelecida.

Portanto, Ping e Test-NetConnection respondem a perguntas diferentes.

Test-NetConnection substitui o Ping?

Não.

O Ping continua sendo uma ferramenta importante para diagnóstico de rede.

Test-NetConnection complementa o diagnóstico quando precisamos verificar uma porta TCP específica.

Uma sequência possível é:

Ping
↓
Test-NetConnection
↓
Tracert
↓
Get-NetTCPConnection
↓
Pktmon

Não é obrigatório utilizar todos os comandos.

Cada ferramenta deve ser escolhida conforme o problema analisado.

Como testar uma porta no Windows 11?

Abra o PowerShell ou Windows Terminal e execute:

Test-NetConnection ENDERECO -Port PORTA

Exemplo:

Test-NetConnection 192.168.1.100 -Port 445

A linha mais conhecida do resultado é:

TcpTestSucceeded

Se aparecer:

TcpTestSucceeded : True

a conexão TCP testada foi estabelecida.

Se aparecer:

TcpTestSucceeded : False

ela não foi estabelecida.

O que significa TcpTestSucceeded True?

Significa que o computador conseguiu estabelecer a conexão TCP testada com aquele endereço e porta.

Por exemplo:

Test-NetConnection 192.168.1.100 -Port 443

retornando:

TcpTestSucceeded : True

indica sucesso naquele teste TCP.

Isso não significa necessariamente que toda a aplicação esteja funcionando.

Um servidor HTTPS, por exemplo, ainda pode apresentar problemas relacionados a:

TLS;
certificado;
autenticação;
aplicação web;
proxy;
permissões.

O que significa TcpTestSucceeded False?

Significa que não foi possível estabelecer a conexão TCP testada com aquele destino e porta.

O resultado, sozinho, não identifica a causa.

Entre as possibilidades estão:

porta incorreta;
serviço parado;
serviço não escutando;
endereço IP incorreto;
firewall;
rota incorreta;
VPN;
VLAN;
isolamento de clientes;
equipamento desligado;
aplicação configurada em outra porta.

Por isso, não é correto afirmar automaticamente que um resultado False significa bloqueio de firewall.

Como testar a porta 443 no Windows 11?

Execute:

Test-NetConnection exemplo.com -Port 443

Esse teste verifica se é possível estabelecer uma conexão TCP com a porta 443.

Para verificar o funcionamento real do HTTPS, outras ferramentas também podem ser necessárias.

Por exemplo:

curl https://exemplo.com

O curl consegue avançar para camadas superiores da comunicação.

Como testar a porta 445 para compartilhamento de arquivos?

Execute:

Test-NetConnection 192.168.1.20 -Port 445

A porta TCP 445 é utilizada pelo SMB moderno em ambientes Windows.

Se retornar:

TcpTestSucceeded : True

e o compartilhamento ainda não abrir, investigue:

credenciais;
permissões NTFS;
permissões do compartilhamento;
usuário;
política SMB;
nome do compartilhamento.

Como testar a porta 3389 do RDP?

Execute:

Test-NetConnection 192.168.1.30 -Port 3389

Esse teste é útil quando o computador utiliza a porta padrão do Remote Desktop Protocol.

Se retornar False, verifique:

RDP habilitado;
serviço correspondente;
Firewall do Windows;
porta configurada;
rota;
VPN;
regras de acesso.

Se retornar True e o RDP continuar falhando, o problema pode estar em autenticação, política, NLA ou permissões.

Como testar a porta 9100 de uma impressora?

Se a impressora utiliza RAW na porta TCP 9100, execute:

Test-NetConnection 192.168.1.150 -Port 9100

Esse é um excelente teste quando a impressora responde ao Ping, mas não imprime.

Porém, antes confirme se a instalação realmente utiliza RAW 9100.

Nem todas as impressoras utilizam essa configuração.

Elas também podem trabalhar com:

IPP;
IPPS;
LPR;
WSD;
protocolos específicos do fabricante.

Minha impressora responde ao Ping, mas Test-NetConnection na porta 9100 retorna False. O que significa?

Significa que houve resposta ICMP ao Ping, mas a tentativa de conexão TCP com a porta 9100 não foi estabelecida.

Agora precisamos investigar:

a impressora utiliza realmente RAW 9100?
o IP está correto?
a porta configurada no Windows é a correta?
existe isolamento na rede?
a VPN interfere na LAN?
a impressora aceita conexões nessa porta?
alguma política está bloqueando o tráfego?

O resultado é uma pista, não o diagnóstico final.

Test-NetConnection consegue testar UDP?

O uso de Test-NetConnection -Port está voltado para conectividade TCP.

Não devemos usar um resultado TCP para concluir que um serviço UDP está funcionando.

Antes de qualquer teste, descubra se a aplicação utiliza TCP ou UDP.

Como descobrir qual porta um programa está usando?

Podemos utilizar:

Get-NetTCPConnection

ou:

netstat -ano

Essas ferramentas ajudam a identificar:

porta local;
porta remota;
endereço remoto;
estado da conexão;
PID.

Depois, podemos relacionar o PID ao processo.

No PowerShell:

Get-Process -Id 5420

Ou no Prompt:

tasklist /fi "PID eq 5420"

Como saber se uma porta está escutando no Windows?

Execute:

Get-NetTCPConnection -State Listen

ou:

netstat -ano

Uma conexão em estado:

LISTENING

ou:

Listen

indica que existe um endpoint TCP aguardando conexões naquela porta.

Test-NetConnection pode descobrir problema de DNS?

Ele pode ajudar a identificar pistas relacionadas à resolução de nomes.

Ao executar:

Test-NetConnection servidor -Port 443

observe:

RemoteAddress

Se o endereço resolvido não for o esperado, investigue DNS.

Você também pode utilizar:

Resolve-DnsName servidor

Por que o teste pelo IP funciona, mas pelo nome não?

Esse comportamento aponta para um possível problema de resolução de nomes.

Pode existir:

DNS incorreto;
cache desatualizado;
registro DNS antigo;
arquivo hosts;
DNS da VPN;
DNS corporativo diferente.

Compare:

Test-NetConnection servidor -Port 443

com:

Test-NetConnection 192.168.1.100 -Port 443

Se somente o segundo funcionar, investigue o nome.

A VPN pode fazer Test-NetConnection falhar?

Sim.

Uma VPN pode alterar:

tabela de rotas;
endereço de origem;
DNS;
acesso à LAN;
gateway utilizado.

Compare o teste com a VPN ligada e desligada.

Observe principalmente:

InterfaceAlias
SourceAddress
RemoteAddress

Como descobrir qual interface o Test-NetConnection está usando?

Observe:

InterfaceAlias

A saída pode mostrar:

Wi-Fi

ou:

Ethernet

ou ainda uma interface de VPN.

O campo:

SourceAddress

também ajuda a identificar qual endereço local foi escolhido.

O Test-NetConnection funciona no Windows Terminal?

Sim.

O Windows Terminal pode executar PowerShell normalmente.

Abra uma guia PowerShell e utilize:

Test-NetConnection destino -Port porta

Posso usar apenas TNC em vez de Test-NetConnection?

Sim.

tnc funciona como alias em ambientes PowerShell compatíveis.

Exemplo:

tnc 192.168.1.150 -Port 9100

Entretanto, para documentação, tutoriais e scripts que precisam ser facilmente compreendidos, o nome completo é mais claro:

Test-NetConnection

Test-NetConnection precisa ser executado como administrador?

Muitos testes básicos podem ser executados sem abrir o PowerShell como administrador.

Algumas etapas complementares do diagnóstico podem exigir permissões maiores, dependendo da configuração e do comando utilizado.

Não utilize privilégios administrativos sem necessidade.

Test-NetConnection pode dizer exatamente onde a rede está bloqueando?

Não.

Ele pode indicar que a conexão TCP não foi estabelecida, mas não identifica sozinho exatamente qual equipamento ou política causou a falha.

Para aprofundar a investigação, podemos combinar:

Test-NetConnection
Get-NetRoute
route print
Get-NetTCPConnection
netstat
tracert
Pktmon
logs do sistema

Conclusão final

O Test-NetConnection parece um comando simples, mas ele representa uma mudança importante na forma de diagnosticar problemas de rede no Windows 11.

Em vez de limitar toda a análise à pergunta:

“O equipamento responde ao Ping?”

podemos fazer uma pergunta mais específica:

“A porta TCP utilizada pelo serviço que eu preciso acessar está realmente disponível a partir deste computador?”

Essa diferença é fundamental.

Uma impressora pode responder ao Ping e não aceitar uma conexão na porta utilizada para impressão.

Um servidor pode responder ao Ping e não disponibilizar SMB.

Um computador pode não responder ao Ping e, ainda assim, aceitar conexões HTTPS.

Por isso, diagnóstico de rede não deve depender de um único comando.

O Test-NetConnection funciona melhor como parte de um método.

Primeiro identificamos o problema.

Depois descobrimos o serviço.

Em seguida identificamos protocolo, porta e destino.

Somente então executamos o teste.

Se:

TcpTestSucceeded : False

investigamos porta, serviço, endereço, firewall, rota, VPN e infraestrutura.

Se:

TcpTestSucceeded : True

podemos avançar para protocolo da aplicação, autenticação, certificados, permissões, driver ou software.

Esse processo elimina muitas tentativas aleatórias e ajuda a encontrar a verdadeira causa do problema com muito mais precisão.

No Windows 11, ferramentas como Ping, Test-NetConnection, Get-NetTCPConnection, Route Print, Tracert e Pktmon formam um conjunto poderoso para diagnóstico.

O mais importante não é decorar todos os comandos.

É saber exatamente qual pergunta cada um deles consegue responder.

Precisa de ajuda para diagnosticar sua rede?

Problemas de rede podem parecer simples inicialmente, mas muitas vezes envolvem diferentes componentes ao mesmo tempo: Windows, roteador, Wi-Fi, impressora, firewall, DNS, VPN, driver e configuração do próprio equipamento.

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

O atendimento pode ser realizado por acesso remoto ou visita técnica, conforme o tipo de problema.

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

Antes de trocar equipamentos, reinstalar o Windows ou modificar várias configurações ao mesmo tempo, vale identificar exatamente onde a comunicação está falhando.