NETSTAT command in Windows

When a port is unreachable, a service is not responding, or something is holding a connection open, netstat is the first command to run. It shows exactly what is listening on which port, which connections are established, which processes own those connections, and what the local routing table looks like — all without installing anything extra. It ships with every version of Windows and has not changed meaningfully in decades.

The output looks simple until you need to interpret it under pressure. This article covers the flags that actually matter, how to read the state column correctly, how to map connections back to specific processes, and a few behaviors that regularly trip up even experienced admins.

---

Quick answer

Show all active TCP connections and listening ports with owning process IDs:

netstat -ano

Map a PID from the output above to a process name:

tasklist /FI "PID eq 1234"

---

What it does

Netstat (network statistics) displays the current state of network connections on the local machine. It reads from the Windows TCP/IP stack and shows TCP connections, UDP listeners, and the network routing table depending on which flags you pass.

Basic syntax:

netstat [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [-x] [-y] [interval]

The flags you will actually use:

---

Practical examples

1. Find what is listening on a specific port

The problem: A service fails to start because the port it needs is already in use. You need to identify what is holding that port before you can do anything about it.

The solution: Run netstat -ano and pipe the output through findstr to filter by port number. The PID column tells you which process owns the connection.

rem Find what is using port 8080
rem -a  — show all connections including LISTENING
rem -n  — show port numbers as numbers, skip DNS lookups (faster)
rem -o  — include the owning PID in output

netstat -ano | findstr :8080

Example output:

TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       4532
TCP    192.168.1.10:8080      192.168.1.25:51234     ESTABLISHED     4532

Now resolve PID 4532 to a process name:

rem Look up the process name for PID 4532
tasklist /FI "PID eq 4532"

2. List all listening ports with process names

The problem: You are auditing a server after deployment to confirm only expected services are listening, or you are investigating an unfamiliar machine and need a fast overview of what is exposed.

The solution: Use -b with elevation to get the executable name directly in the output. Filter to LISTENING state only to reduce noise.

rem List all LISTENING ports with owning executable names
rem Requires administrator privileges for -b flag
rem -a — all connections and listening ports
rem -n — numeric output, no DNS resolution
rem -b — show executable responsible for each connection

netstat -anb | findstr LISTENING

3. Monitor connections to a specific remote host

The problem: You suspect a machine is maintaining persistent connections to an unexpected remote address — potentially a hung session, a misconfigured service, or outbound traffic that should not be there.

The solution: Filter netstat output by the remote IP address. Add an interval argument to refresh automatically and watch connection state changes over time.

rem Watch connections to a specific remote IP, refresh every 3 seconds
rem Replace 10.0.0.45 with the address you want to monitor
rem -o — show PIDs so you can identify the owning process

netstat -ano 3 | findstr 10.0.0.45

4. Check for connections stuck in TIME_WAIT or CLOSE_WAIT

The problem: An application is throwing connection errors or running out of available ports. The root cause is often a large number of connections stuck in TIME_WAIT or CLOSE_WAIT state — connections that should have been released but have not been.

The solution: Filter by connection state to count and inspect the stuck connections. Understanding the difference between the two states points to different root causes.

rem Count connections in TIME_WAIT state
rem TIME_WAIT is normal — OS holds the socket briefly after close to catch late packets
rem A very large count (thousands) may indicate port exhaustion

netstat -ano | findstr TIME_WAIT

rem Count connections in CLOSE_WAIT state
rem CLOSE_WAIT means the remote side closed the connection but local app has not
rem A large count usually points to an application-level bug — not OS configuration

netstat -ano | findstr CLOSE_WAIT

5. Show the local routing table

The problem: Traffic from a server is going out the wrong interface, or a machine has multiple NICs and you are not sure which route is being used for a given destination. You need to see the active routing table without switching to a different tool.

The solution: netstat -r displays the IPv4 and IPv6 routing tables — the same data as route print, just accessed through netstat.

rem Display the local routing table
rem Shows active routes, persistent routes, and interface list
rem Equivalent to: route print

netstat -r

---

Hidden gems

-n makes everything faster

Without -n, netstat performs a reverse DNS lookup for every remote address in the output. On a machine with many established connections, this can make the command take 30–60 seconds or more. Adding -n skips all DNS resolution and returns results almost instantly. Make -n a default habit — add DNS resolution only when you specifically need hostnames with -f.

Combining netstat with find for counting

You can count the number of connections in a given state by piping to find /c. Useful for quickly quantifying how many established connections exist or how severe a TIME_WAIT accumulation is.

rem Count total ESTABLISHED connections on the machine
netstat -ano | find /c "ESTABLISHED"

rem Count LISTENING ports
netstat -ano | find /c "LISTENING"

PID 4 is always System

If a port shows PID 4 as the owner, it belongs to the Windows System process — not a user application. This is typical for ports managed directly by the kernel: SMB (445), RPC (135), and sometimes IIS if the HTTP stack is kernel-mode. You cannot stop these by killing a process — they are controlled by services or kernel drivers.

UDP listeners do not show connection state

UDP is connectionless, so UDP entries in netstat output show no state column — they just appear as open listeners. This catches people out when they filter by state looking for UDP services. To see UDP listeners, use netstat -anp UDP and do not expect a state value.

---

PowerShell equivalent

PowerShell’s Get-NetTCPConnection covers most of what netstat -ano does, with proper object output that can be filtered, sorted, and piped without parsing text:

# Show all LISTENING TCP connections with owning PID
Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Format-Table LocalAddress, LocalPort, OwningProcess

# Find what is using port 8080
Get-NetTCPConnection -LocalPort 8080

# Map PID to process name — combine with Get-Process
Get-NetTCPConnection -State Listen |
    Select-Object LocalPort, OwningProcess,
        @{Name="ProcessName"; Expression={(Get-Process -Id $_.OwningProcess).Name}} |
    Sort-Object LocalPort

---

Where this matters

Port conflict diagnosis — a service fails to start because its port is already taken; netstat identifies the owning process in under 10 seconds.

Security audits — reviewing listening ports on a freshly deployed server to confirm only expected services are exposed before it goes into production.

Application troubleshooting — an app reports connection errors; netstat reveals whether the remote service is reachable and in what state the connection is sitting.

Port exhaustion investigation — high-throughput applications running out of ephemeral ports; netstat shows the accumulation of TIME_WAIT connections that is consuming the available range.

Multi-NIC routing verification — confirming which network interface a server uses for outbound traffic to a specific destination before changing routing configuration.

---

Tips and limitations

• Always use -n unless you need hostnames. DNS resolution in netstat is synchronous and blocks the output. On machines with many connections or slow DNS, omitting -n can make the command hang for minutes.
• netstat is a snapshot, not a stream. It captures the state at the moment it runs. A connection that opens and closes in under a second will not appear. Use the interval argument (netstat -ano 2) or loop in a batch script for transient connection tracking.
• -b requires administrator privileges. Without elevation it silently produces incomplete output. If process names are missing from output, check whether the terminal is running elevated.
• netstat does not show socket buffers or packet loss. For deeper network diagnostics — latency, retransmit rates, TCP window scaling — use netstat -s for protocol statistics or reach for netsh interface tcp show global.
• Windows Firewall blocks do not appear in netstat. A port may show as LISTENING but still be blocked by the Windows Firewall. Netstat shows the socket state from the OS perspective, not what is reachable from the network. Combine with the Port Checker tool to verify external reachability.

---

Official documentation

• netstat — Microsoft Learn — full flag reference and output format documentation

Related tools

• Port Checker — verify whether a port is reachable from outside, not just locally open
• Reverse DNS Lookup — resolve remote IP addresses from netstat output to hostnames

Related guides

• NSLOOKUP command — DNS diagnostics to pair with netstat when investigating connection issues by hostname
• NLTEST command — domain connectivity checks that complement netstat when troubleshooting AD-related network issues
• ATTRIB command — file attribute management in the same Windows CMD cluster
• Windows Command Line (CMD) Cheat Sheet — quick reference for CMD commands used alongside netstat in diagnostic workflows