Test TCP ports on Windows with Test-NetConnection

A server answers ping, but SSH or its web interface still fails. Testing the TCP port used by that service helps narrow down the next step. Windows PowerShell includes Test-NetConnection for this purpose.

Specify the destination and port

Test-NetConnection -ComputerName server.example.com -Port 22

The first result shows True for TCP port 18189; the second shows False for port 18190. The TCP connect ... failed warning means that TCP connection did not succeed. In the second result, PingSucceeded is still True, demonstrating why ping and TCP need separate checks.

Replace the example hostname with your destination. Port 22 is commonly used for SSH; if the server uses a different port, test that port. Run the check against the endpoint you use or administer.

Read RemoteAddress, RemotePort, and TcpTestSucceeded. First confirm that the resolved destination and port are the ones you intended to test.

If TcpTestSucceeded is True

A true result means a TCP connection to that address and port succeeded at the time of the test. Continue with the normal SSH client or browser and investigate the application’s actual error.

TCP connectivity does not establish that authentication will work or that a web certificate is valid. For an SSH authentication error, check the username and key settings. For a certificate error, check the hostname and the certificate information shown by the browser.

If TcpTestSucceeded is False

A false result says that the tested TCP connection did not succeed. It does not identify the responsible component on its own. Check the address and port, then whether the destination service is running and whether the network path permits the connection.

A failed ping is a separate result. A network may block ICMP while allowing the service’s TCP port. Likewise, a successful ping does not prove that the service’s port is open.

Test HTTPS

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

Use the hostname of the service you are investigating. Detailed output gives more connection context, including the source interface and address. The command tests connectivity; it does not fetch a web page or validate its TLS certificate.

Keep the connection path in view

The result describes the path from the PC running the command. If an application connects through a VPN, proxy, jump host, or local port forward, that path can differ. For a local forward, distinguish the local listening port from the destination reached by the forwarding server.

When the hostname itself cannot be resolved, check DNS first with Resolve-DnsName. Once the expected address is returned, a TCP test provides a useful next stage without treating name resolution, transport, and authentication as the same problem.

Reference

Microsoft Learn: Test-NetConnection documents the parameters and output fields.