Test a TCP Port from PowerShell with Test-NetConnection

When an application cannot reach a server, first check whether your computer can establish a TCP connection to the destination port. In PowerShell, Test-NetConnection does that without installing a separate utility.

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

The key result is TcpTestSucceeded. A value of True means the TCP connection succeeded from the machine and network where you ran the command. It does not prove that the application behind the port is working correctly.

Run a targeted port check

Use -ComputerName for a hostname or IP address and -Port for the TCP port you want to test:

Test-NetConnection -ComputerName 203.0.113.25 -Port 22

The short alias tnc runs the same cmdlet:

tnc server.example.com -Port 443

This is a PowerShell command, not a Command Prompt command. If you see “not recognized” in cmd.exe, open PowerShell and try again. The cmdlet is provided by the NetTCPIP module. To check whether it is available in your current session, run:

Get-Command Test-NetConnection

The test runs from your computer, so run it from the same machine and network path as the failing application. A test from a different network may get a different result because of firewalls, routing, VPNs, or access rules.

Read the result without overinterpreting it

For a script or a quick Boolean result, use -InformationLevel Quiet:

Test-NetConnection -ComputerName server.example.com -Port 443 -InformationLevel Quiet

For diagnostic details, request Detailed output:

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

Useful fields include:

• RemoteAddress: the IP address selected after resolving the target name. Check that it is the address you expected.
• SourceAddress: the local address used for the connection attempt.
• PingSucceeded: whether an ICMP ping received a reply.
• TcpTestSucceeded: whether the TCP connection to the specified port succeeded.

Keep the ping and TCP results separate. A host can block ICMP ping while still accepting TCP connections, or respond to ping while a particular TCP port is unreachable. PingSucceeded is not a substitute for a port test.

Likewise, TcpTestSucceeded: True confirms a TCP connection was established at the time of the test—not that authentication, TLS, or an application request will succeed. For example, a reachable SSH port does not confirm that your key or account is accepted. If SSH specifically reports that the server refused the connection, use a separate troubleshooting path for SSH connection refused errors.

Common checks

The same command works for common web ports:

Test-NetConnection -ComputerName www.example.com -Port 80
Test-NetConnection -ComputerName www.example.com -Port 443

These test TCP connectivity only. They do not request a web page, check its HTTP response, or validate its certificate.

For a database, test the port configured for that service. For example, MySQL or MariaDB commonly uses TCP 3306, while PostgreSQL commonly uses TCP 5432:

Test-NetConnection -ComputerName db.example.com -Port 3306
Test-NetConnection -ComputerName db.example.com -Port 5432

A reachable database port still does not verify credentials, permissions, or whether a query works. Test from the application host or another approved network location, since databases are often restricted to private networks or specific client addresses.

For supported common services, you can use -CommonTCPPort instead of a number. For example:

Test-NetConnection -ComputerName fileserver.example.com -CommonTCPPort SMB

Use -Port for an arbitrary or nonstandard port. -CommonTCPPort only accepts the service names supported by the cmdlet.

If the TCP test fails

TcpTestSucceeded: False tells you that the connection attempt did not succeed; it does not identify why. Check the problem in layers:

1. Confirm the destination. Verify the hostname, port, and whether the server should accept connections from your network.
2. Check the resolved address. Look at RemoteAddress. If it is unexpected, investigate the hostname or test the intended IP directly.
3. Check the server-side listener. The test from your PC cannot tell you whether a process is running on the server or listening on the right interface and port. On Linux, ss can help inspect listening sockets.
4. Review the path. Firewalls, routing, VPNs, cloud security groups, and network ACLs can all affect connectivity.
5. Repeat from the relevant client. Rules may allow one host or subnet and deny another.

Test-NetConnection diagnoses connectivity; it does not open a port or change firewall rules. A failed result is a reason to investigate the path and listener, not to assume that one particular firewall is responsible.

You can also ask the cmdlet to trace the route:

Test-NetConnection -ComputerName server.example.com -TraceRoute

Route tracing is a separate diagnostic, not a TCP port test. Intermediate devices may not respond to its probes, so a missing hop alone does not prove that the destination port is blocked.

Know what the cmdlet does not test

The -Port check is for TCP, not UDP. UDP has no TCP-style connection handshake, so this command cannot establish whether a UDP service is reachable. Use a diagnostic suited to the protocol or test the service with an application-level request.

Also distinguish Test-NetConnection from Test-Connection: a basic Test-Connection check is for ping/ICMP, while Test-NetConnection -Port checks a TCP port. Use the result that matches the question you are trying to answer: can this host respond to ping, or can this client establish a TCP connection to this service?

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.