To check whether a TCP port is open on a remote server from Windows, run Test-NetConnection -ComputerName server -Port 443 in PowerShell and read the TcpTestSucceeded line: True means a TCP connection was made, False means it was not. For one port on one host that is enough. When you need to sweep several servers, VMs or Docker hosts across a range of ports, Port Detective Pro scans remote hosts with port presets or your own ranges, and on the server itself Port Detective shows which process owns the port.
This guide covers both built-in commands, what a False result can mean, and when a scanner saves time.
Scan remote hosts by preset or range, then see which process owns each port.
Get it from Microsoft
What does “open” actually mean?
A port is open from your point of view when three things are true at once:
- Something is listening on that port on the server.
- Nothing blocks the path: the server’s firewall, a network firewall, a cloud security group or a router.
- You are reaching the right address, so name resolution and routing work.
A local check on the server, such as netstat -ano, only proves the first point. A test from your own PC proves all three together, which is why “it is listening on the server but I cannot connect” is such a common ticket. Our guide on finding the process using a port covers the server-side half.
How do I test a remote port with Test-NetConnection?
Test-NetConnection is a PowerShell cmdlet in the NetTCPIP module. Microsoft’s Test-NetConnection reference documents the parameters used here.
Test-NetConnection -ComputerName db01.example.local -Port 5432The output lists the computer name, remote address, remote port, the local interface and source address used, and TcpTestSucceeded. That last line is your answer.
Useful variations:
| Goal | Command |
|---|---|
| Just True or False, for a script | Test-NetConnection db01 -Port 5432 -InformationLevel Quiet |
| More detail, including name resolution results | Test-NetConnection db01 -Port 5432 -InformationLevel Detailed |
| A well-known service without a port number | Test-NetConnection db01 -CommonTCPPort RDP |
The reference lists HTTP, RDP, SMB and WINRM as the accepted values for -CommonTCPPort. With -InformationLevel Quiet, the cmdlet returns a Boolean, which makes it easy to loop over a short list of hosts:
'web01','web02','db01' | ForEach-Object {
[pscustomobject]@{ Host = $_; Open = (Test-NetConnection $_ -Port 443 -InformationLevel Quiet) }
}Can I still use telnet?
Yes, if it is installed. telnet server 25 either opens a blank session, which means the TCP connection worked, or fails with a connection error. Microsoft’s telnet command reference notes that you must install the telnet client before you can run the command. On most Windows PCs Test-NetConnection is already there and gives a clearer answer, so it is the better default.
What does TcpTestSucceeded False mean?
False tells you the connection was not made. It does not tell you why. Work through the likely causes in order:
| Cause | How to tell | Fix |
|---|---|---|
| Wrong name or address | The RemoteAddress shown is not the server you expect | Test the IP directly; fix DNS or hosts entries |
| Nothing listening | On the server, the port is not in netstat -ano output | Start the service, or check its configured port |
| Listening on localhost only | The server shows 127.0.0.1:port, not 0.0.0.0:port | Change the service’s bind address |
| Server firewall | Works from the server itself, fails from your PC | Add or fix the inbound rule |
| Network or cloud firewall | Fails from every outside machine, even with the server firewall off | Check security groups, ACLs and routers |
| Wrong protocol | The service uses UDP | A TCP test cannot confirm a UDP service |
The localhost case catches a lot of developers: a database or dev server started on 127.0.0.1 accepts local connections and refuses everything else. Our post on the gap between a firewall rule and a listening port goes further into rules versus listeners.
A note on UDP: Test-NetConnection tests TCP. UDP has no handshake, so a quiet UDP port looks the same whether it is open or filtered. Confirm UDP services on the server, or with the application’s own client.
On the server, see the process, PID and bind address behind every port.
Get it from Microsoft
When is a command not enough?
One port on one host is a one-line job. It gets slow when:
- you are checking a lab of VMs after a firewall change,
- a Docker host publishes ports you did not expect,
- you need to know which of twenty common ports respond on a new server.
Port Detective Pro scans remote VMs, Docker bridges and servers across your network using port presets or your own ranges, so you get one table instead of a loop of commands. When Docker is running locally, it maps host ports back to the container and image that published them. On the server, Port Detective (Free or Pro) shows live TCP and UDP connections with the owning process name, PID, executable path and state, so a result on the scan becomes a named process. The free edition focuses on the local machine; remote scanning is a Pro feature.
Scan only networks and hosts you own or are authorised to test. Many organisations treat unexpected port scans as a security event.
Does it matter where I test from?
Yes. A result is only true for the network you tested from. A port can be open from the office LAN and closed from home, because a VPN, a cloud security group or an edge firewall treats the two paths differently. If users connect from the internet, test from outside the corporate network as well. If only a jump box or another server needs the port, run the test from that machine, since that is the path that matters. Record the source address from the output so you know which path each result describes.
A quick routine for “I cannot connect to the server”
- From your PC:
Test-NetConnection server -Port N. If True, the problem is in the application, not the network. - On the server: confirm a process is listening on N, and on which address. Port Detective or
netstat -anowill show it. - From the server itself: test
localhostand the server’s own IP. If localhost works and the IP does not, check the bind address. - Check the server firewall, then the network path.
- After a change, test again from your PC, not from the server.
If the port is owned by an unexpected process, our guide to finding a process on a port on a remote Windows server walks through it.
Frequently asked questions
Does Test-NetConnection need admin rights?
Microsoft’s own Detailed example shows IsAdmin as False alongside TcpTestSucceeded as True, so a basic port test runs from a normal PowerShell window.
Is ping the same as a port check?
No. Ping uses ICMP, which many firewalls block. A host can fail ping and still accept connections on 443, or answer ping with the port closed.
Can I test a port from the server to itself?
Yes, and it is a useful step, but it bypasses the network path. Always confirm from the client side too.
Does Port Detective change firewall rules?
No. It shows connections and processes and can end a process you choose. Firewall changes stay in your own tools.
Try Port Detective
Port Detective Free is in the Microsoft Store for local port and process lookup. Port Detective Pro, a one-time purchase with a free trial in the Microsoft Store, adds remote scanning with presets and ranges. More detail is on the Port Detective product page.
Check remote hosts and local owners in one Windows app.
Get it from Microsoft
Last updated 22 October 2026. Published by Automata Labs, a software company in Canada.