How to Check for Open Ports on Windows Server

To check for open ports on a Windows Server, list its local listeners, then test from another computer to see whether clients can reach them. A listening port is not automatically reachable across the network: the service binding, Windows Firewall, network firewalls, routing, and NAT can all affect access. Scan only systems you own or are authorized to assess.

List local TCP listeners with PowerShell

On the server, open PowerShell and run Get-NetTCPConnection with the Listen state. Sorting by port makes the list easier to review, while the selected columns show the address, port, and process ID.

Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress,LocalPort,OwningProcess

Each row is a TCP endpoint in the listening state. An address of 0.0.0.0 or :: means the listener is bound to all IPv4 or IPv6 interfaces, respectively. An address such as 127.0.0.1 or ::1 is loopback-only, so remote computers cannot connect to that listener through a network interface.

To inspect one port, add its number to the query:

Get-NetTCPConnection -State Listen -LocalPort 443 | Select-Object LocalAddress,LocalPort,OwningProcess

Use the returned process ID to identify the owner, for example with Get-Process -Id 1234 (replace 1234 with the PID in your output). Microsoft documents the cmdlet's connection-state, local-port, and owning-process fields in its Get-NetTCPConnection reference.

Use netstat to see listeners and process IDs

netstat is a built-in alternative that works from Command Prompt or PowerShell. This command filters the output to listening TCP ports:

netstat -ano -p tcp | findstr LISTENING

The switches mean: -a includes listeners, -n keeps addresses numeric, -o adds the PID, and -p tcp limits the view to TCP. Match a PID in Task Manager or use Get-Process -Id 1234. For UDP endpoints, run netstat -ano -p udp; UDP has no TCP-style LISTENING state. See Microsoft's netstat reference.

Check ports with Microsoft PortQry

PortQry version 2 is Microsoft's separate utility for checking TCP and UDP ports. Download and extract it to a folder such as C:\Tools\PortQryV2, then open PowerShell there. To list active mappings on that computer, run:

.\PortQry.exe -local

Local mode lists active TCP and UDP mappings and can include process IDs; use it for inventory, not remote reachability. To query another server, specify its name or IP, protocol, and port:

.\PortQry.exe -n server01.example.com -p tcp -e 443

For a remote query, LISTENING means PortQry received a response; NOT LISTENING means it received a response indicating no listener. FILTERED means no response, so a firewall may be dropping traffic and a process may or may not be listening. UDP can be less conclusive because services may ignore unformatted probes. See Microsoft's PortQry guide.

Test reachability from another computer

A check run on the server cannot prove that a client on another network can connect. From a Windows client on the path you want to verify, run:

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

Replace the hostname and port with your values. TcpTestSucceeded : True confirms a TCP connection from that client at that moment. False reports failure but does not identify whether the cause is a missing listener, firewall, routing, DNS, or upstream filter. See Microsoft's Test-NetConnection reference.

For a visual scan, install Nmap from its official download page; the Windows installer includes Zenmap. To check selected ports, run:

nmap -p 80,443 server01.example.com

In Zenmap, enter an authorized target, choose a profile, run the scan, and review Ports / Hosts. Nmap's basic target scan checks the 1,000 most common TCP ports; use -p to narrow it. The states describe what Nmap sees from that client: open means an application is accepting connections, closed means no application is listening, and filtered means an obstacle prevents Nmap from determining the state. See the Zenmap guide.

What to do with the results

If PowerShell shows a listener but the client test fails, check the service's bound address, the matching inbound rule and its network profile, and any upstream firewall, security group, router, or NAT. An allow rule does not create a listener; a service must bind to the port.

For an unfamiliar listener, use its PID to identify the application and confirm whether it is needed before changing it. Restrict or remove unused services or inbound rules through your normal change process, then retest from the client path that matters. One scan shows reachability from that vantage point only.