pjhtech Tools
Network tools · Network tools

PowerShell Network Tests: DNS, TCP Ports and Connections

Windows includes enough network diagnostics to answer three useful questions without installing a port scanner: did the name resolve, can this client open the required TCP port, and is the local application listening? Keep those questions separate. A successful ping is not a test of HTTPS, RDP or another TCP service.

Scope: Windows PowerShell with Windows NetTCPIP and DnsClient modules; do not imply these Windows modules ship with PowerShell on Linux or macOS.

Resolve the service name #

Resolve the service name
Network tools · Windows PowerShell

Active test

Replace these example values: example.com.

Resolve-DnsName -Name example.com -Type A -DnsOnly
Active test

Replace these example values: example.com.

Resolve-DnsName -Name example.com -Type AAAA -DnsOnly
Active test

Replace these example values: example.com, 192.0.2.53.

Resolve-DnsName -Name example.com -Type A -Server 192.0.2.53 -DnsOnly

The server address is a placeholder. Specifying it makes the test reproducible; -DnsOnly avoids LLMNR and NetBIOS fallback. Compare the exact name and record type used by the application. An IPv4 answer does not prove that an IPv6 destination is working.

Test the required TCP service #

Test the required TCP service
Network tools · Windows PowerShell

Active test

Replace these example values: example.com.

Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel Detailed
Active test

Replace these example values: 192.0.2.20.

Test-NetConnection -ComputerName 192.0.2.20 -Port 3389 -InformationLevel Detailed
Active test

Replace these example values: 192.0.2.20.

Test-NetConnection -ComputerName 192.0.2.20 -DiagnoseRouting -InformationLevel Detailed

Read TcpTestSucceeded for the port test. PingSucceeded answers a different question. Detailed output also helps identify the selected remote address, source address and interface, which is valuable on a laptop with Ethernet, Wi-Fi and VPN routes.

-Port tests TCP, not UDP. Testing port 53 this way does not establish that UDP DNS queries work. Use an actual DNS query for DNS behavior. The route-diagnostic command is a separate test and does not prove that the remote service accepted a connection.

Inspect the server's local sockets #

Inspect the server's local sockets
Network tools · Windows PowerShell

Read-only
Get-NetTCPConnection -State Listen -LocalPort 443
Read-only
Get-NetTCPConnection -State Established -RemotePort 443 |
    Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess

On the server, inspect the listening address as well as the port. A service bound only to loopback is not equivalent to a listener on the server's network address. On a client, the remote port is normally the service port; its local port is often an ephemeral port. Reversing those filters can hide the connection being investigated.

What success proves #

A successful TCP probe shows that a TCP connection could be established from this machine at this moment. It does not validate TLS, credentials or the application's response. If the port works but the user still fails, preserve the resolved address and test the application layer next. These commands inspect state or send probes; they do not repair routes, reset adapters or restart services.

Sources

Documentation reviewed: 8 October 2026