Netstat is the simplest, fastest way to see what your Windows PC is doing on the network: active TCP and UDP sessions, which ports are listening, and which processes own those sockets — all from a single Command Prompt window. This guide explains exactly how to run Netstat on Windows, how to read its output, which switches matter most for troubleshooting ports and connections, and practical workflows you can use right now to diagnose blocked ports, runaway connections, and suspicious remote hosts.
Background
Netstat (network statistics) is a long‑standing command-line utility available on Windows that reports current TCP/IP connections, listening ports, routing tables, and protocol statistics. It’s built into Windows and still widely used by IT pros because it is fast, reliable, and available on virtually every Windows machine without installing anything extra. Microsoft documents Netstat’s syntax and options and confirms the key switches used in modern troubleshooting workflows. Community traces and forum outputs show the same practical usage: administrators commonly run netstat to list listening ports, match PIDs to process names, and spot suspicious remote addresses in the Foreign Address column. Real-world command outputs — including lists of LISTENING ports and PID mappings — are frequently shared by support threads when diagnosing connectivity or port conflicts.
Why Netstat Still Matters
Netstat matters because it gives immediate, local visibility into the socket layer. That visibility helps you:
- Confirm whether a service is actually listening on the expected port.
- Identify which process or PID has bound a port (so you can stop or reconfigure it).
- Track active remote peers connected to your machine.
- See protocol-level statistics (retransmits, resets, dropped packets) to guide deeper network troubleshooting.
- Monitor changes over time using Netstat’s interval refresh.
Those capabilities are often the only reliable way to determine if an app or the OS is holding a port open, or whether a remote host is continually reconnecting to your machine. Microsoft’s documentation outlines the synopsis and options that deliver these views.
Overview: Where to Run Netstat
- Open the Start menu, type cmd, right‑click Command Prompt and choose “Run as administrator” if you need process names (-b) or want to inspect system-owned ports. Many useful Netstat options require administrative elevation to show complete information.
- Use a standard Command Prompt (cmd.exe) or an elevated PowerShell prompt — the Netstat behavior and switches are the same when invoked from either shell.
Running Netstat without switches will show basic active TCP connections, but useful troubleshooting depends on key switches covered next.
How to Run Netstat: Essential Commands
Below are the commands every Windows admin should have in their toolbox. Each example shows what to run and why.
1. Basic active connections
- Command: netstat
- What it shows: active TCP connections (established sockets)
This quick view is helpful for a rapid sanity check but lacks listening ports and PIDs.
2. Show all connections and listening ports
- Command: netstat -a
- What it shows: all TCP and UDP sockets, including those in LISTENING state (ready to accept inbound connections). Use this to confirm a service is listening on the expected port.
3. Show PIDs to match sockets with processes
- Command: netstat -ano
- What it shows: same as -a but with the numeric Process ID (PID) in the last column. Combine this with Task Manager or tasklist to map PID → process name. Microsoft’s troubleshooting KB explicitly recommends -o to reveal owning process IDs for port matching.
4. Show executable names (requires admin)
- Command: netstat -b
- What it shows: the executable that created each connection or listening port (displayed beneath or near the socket entry). This option requires elevated privileges and can be slow on systems with many connections. SS64 and common community guidance note that -b will fail without admin rights and can take some time.
5. Avoid DNS/port name lookups
- Command: netstat -n
- What it shows: numerical IP addresses and port numbers, which is faster and avoids delays caused by reverse DNS. Use this in scripts or when timestamps matter.
6. Filter by protocol
- Command: netstat -p tcp or netstat -p udp
- What it shows: only sockets for the specified protocol. The -p option also extends the range of stat protocols for -s (see below).
7. Protocol statistics
- Command: netstat -s
- What it shows: per-protocol statistics (TCP, UDP, ICMP, IP, and IPv6 variants if installed). Useful to detect resets, retransmits, or other anomalies over time.
8. Repeated display (live monitoring)
- Command: netstat -an 5
- What it shows: refreshes numeric (-n) output every 5 seconds so you can watch new connections appear and disappear. Press CTRL+C to stop. This is a lightweight live view for spotting bursts or persistent connections.
Reading Netstat Output: Columns and States
A Netstat table is compact but full of meaning. Typical columns include:
- Proto — protocol in use (TCP/UDP).
- Local Address — local IP and port (IPort). 0.0.0.0:80 or [::]:80 typically mean “listening on all interfaces.”
- Foreign Address — remote IPort for the peer (or : for UDP listening entries).
- State — connection state (ESTABLISHED, LISTENING, TIME_WAIT, CLOSE_WAIT, SYN_SENT, etc. for TCP.
- PID — the numeric Process ID (only with -o or -ano).
Important state interpretations:
- LISTENING — the socket is accepting connections on the local machine.
- ESTABLISHED — two endpoints have a live connection.
- TIME_WAIT / CLOSE_WAIT / FIN_WAIT — TCP teardown stages; many TIME_WAIT entries are normal after lots of short connections.
Forum outputs show dozens of LISTENING lines and many TIME_WAIT connections in everyday diagnostics, reinforcing that those states are routine rather than always problematic. Use context — high numbers of TIME_WAIT are typical on busy clients; repeated SYN_SENT to the same remote host may signal connection issues.
Map PID to App: Quick Methods
Once you have a PID from netstat -ano, identify the owning process:
- Task Manager:
- Press Ctrl+Shift+Esc.
- View → Select Columns → enable PID.
- Sort or find the PID to see the process name.
- Command line:
- tasklist | find "1234" (replace 1234 with the PID).
- tasklist /FI "PID eq 1234" gives a formatted entry.
- PowerShell:
- Get-Process -Id 1234
Multiple how‑to guides and support docs use the netstat + PID → Task Manager pattern as the standard way to tie sockets to processes.
Practical Troubleshooting Workflows
Below are common, repeatable workflows you can use to solve the most frequent port and connection issues.
Workflow: Confirm a service is listening but not reachable
- On the server, run: netstat -an | findstr "ORT" (replace PORT).
- If output shows LISTENING on 0.0.0.0ORT or [::]ORT, the service is listening locally.
- Check which process owns the port: netstat -ano | findstr "ORT" and note the PID; then tasklist /FI "PID eq <PID>".
- If the process looks correct but remote clients cannot connect, verify Windows Firewall / inbound rules and any intermediate network ACLs or NAT. Community troubleshooting scripts often combine ipconfig, route print, and netsh outputs to create a full picture.
Workflow: Port conflict (another process using a port you need)
- netstat -ano | findstr ":80" to list processes bound to port 80.
- tasklist /FI "PID eq <PID>" to identify the process.
- If it’s an unexpected or system process, investigate before killing; if it’s a service you can stop (IIS, Apache, a test server), stop the service and rebind.
Workflow: Find suspicious remote hosts
- netstat -ano | findstr ESTABLISHED to see live remote peers.
- Note the foreign IP(s) and PID(s). Map PIDs to process names.
- If a process and remote IP look suspicious, capture the PID, capture the binary path (via tasklist /v or Get-Process), and investigate with your normal security tools. Remember netstat alone can’t determine if an app is malicious — it only shows the connection. Many threads advising on “suspicious remote connections” use netstat to find the PID and then escalate to security scans.
Useful Command-Line Tricks
- Filter for a single port:
- netstat -ano | findstr ":443"
- Count connections to a port:
- netstat -an | findstr ":443" | find /c "ESTABLISHED"
- Redirect to a file for later analysis:
- netstat -ano > C:\Temp\netstat-output.txt
- Live numeric refresh every 2 seconds:
- netstat -an 2
- Use -b to see executables (run as Admin):
- netstat -b -o
These patterns are common in support threads and admin documentation because they are quick, scriptable, and integrate with existing Windows utilities.
Advanced Tips and Alternatives
-b vs -o
- -o shows the PID quickly and with no extra permissions.
- -b shows the executable name but requires administrative elevation and can be slower and more verbose. Use -o first, then escalate to -b only when you need the executable path/name. SS64 and Microsoft note that -b may fail without elevation.
PowerShell alternatives
- Get-NetTCPConnection lists TCP connections along with OwningProcess and can be filtered and piped into other PowerShell cmdlets.
- Test-NetConnection can test port reachability to a remote host and port (handy for client-side checks).
These PowerShell tools are more flexible for scripting or when you need richer structured output for automation and logging.
GUI alternative: TCPView
- Sysinternals TCPView gives a graphical, dynamic view of sockets, similar to netstat -b/-o but with built-in process mapping and the ability to close connections from the UI. TCPView is often recommended for live exploration and is a good complement to netstat in incident response workflows.
Common Pitfalls and What Netstat Won’t Tell You
Netstat is powerful but limited. Be careful about the following:
- Netstat does not reveal the intent of a connection. It shows an endpoint and owning process, but not whether the traffic is benign or malicious. Use security tools to analyze behaviour beyond sockets. Several support threads that suspected “remote control” found normal services or user applications once PIDs were mapped.
- Killing processes to free ports can destabilize the system. If a PID belongs to svchost.exe or another system process, don’t terminate it blindly.
- -b can be slow and may not produce output on older or poorly configured systems; use -o as the first step.
- Netstat output can be noisy on busy systems; filter and redirect output to files for analysis.
- Netstat cannot show which Windows service (service name) owns a PID directly — you may need sc queryex, tasklist /svc, or the Services MMC to correlate service names and PIDs.
Interpreting Protocol Statistics (-s)
The -s switch prints per-protocol statistics (TCP, UDP, ICMP, IP, and IPv6 variants). Look for sudden spikes in:
- TCP Resets or Retransmits — might indicate network congestion or a problematic peer.
- UDP Receive errors — could suggest malformed packets or application issues.
Compare statistics over time. Netstat’s -s is a good early indicator that points you to the right layer for deeper packet captures or interface diagnostics. Microsoft documents how -s aggregates stats and how -p interacts with it.
Example: Unblocking a Port Used by an Unexpected Process
- You need port 8080 free for a new web service. Run:
- netstat -ano | findstr ":8080"
- Output shows LISTENING with PID 4320. Map PID:
- tasklist /FI "PID eq 4320"
- If tasklist shows an identifiable app you can stop, stop it gracefully (Service MMC, sc stop <service>, or use the app’s UI).
- If PID maps to a system process, investigate further — it may be a service host or child process. Check tasklist /svc or Get-Process -Id 4320 to locate service relationships.
Forum archives repeatedly use this exact sequence — netstat -ano to find PID, then tasklist or Task Manager to identify the process — as the first step to resolving port conflicts.
Security Considerations
- Netstat can expose suspicious remote IPs or unexpected listening ports, but it cannot prove malware. Use AV/EDR scans, process file checks (hashes), and centralized logging to confirm malicious activity.
- When investigating suspicious outgoing connections, capture evidence: netstat output, process path, timestamped logs, and — if available — packet captures. This data helps security teams or threat hunters correlate activity.
- Escalate to network defenders if you see persistent connections to known‑bad infrastructure, or unknown processes with remote peers that cannot be explained by legitimate apps.
Community guidance and incident-response threads consistently recommend using Netstat as an early discovery tool and then following with forensic or security tooling to establish intent.
Quick Reference: Most Useful Netstat Commands
- netstat -an — numeric, all sockets
- netstat -ano — numeric + PID (best first step)
- netstat -b -o — executable name + PID (requires Admin)
- netstat -s — protocol stats (TCP/UDP/ICMP/IP)
- netstat -an 5 — live numeric refresh every 5 seconds
- netstat -p tcp -ano — only TCP sockets with PIDs
- netstat -an | findstr ":22" — filter results for port 22
These are covered in Microsoft docs and recommended by Windows admin resources as standard diagnostic commands.
When to Use Netstat vs. Other Tools
- Use Netstat when you need a quick, local snapshot of sockets and PIDs without installing tools.
- Use Get-NetTCPConnection and other PowerShell cmdlets for scriptable, structured output or when building automation.
- Use TCPView for easier live exploration when you prefer GUI and want to close sockets interactively.
- Use packet capture (Wireshark) when you need payload-level visibility or to diagnose protocol-level errors indicated by -s.
Final Notes and Best Practices
- Always start with netstat -ano to get a fast, numeric picture and PIDs. Then map PIDs using Task Manager or tasklist.
- If you require executable names, run an elevated netstat -b -o but be prepared for longer runtime on busy systems.
- Save outputs to files for later comparison and to provide evidence when escalating incidents.
- Combine Netstat with firewall checks (netsh advfirewall show allprofiles) and Test-NetConnection for a complete connectivity triage.
- Remember Netstat shows what is connected — not necessarily why. Use it as the first step in a layered troubleshooting and security workflow.
Netstat remains a cornerstone of Windows networking diagnostics because of its accessibility, clarity, and the immediate value it provides in linking sockets to processes. Mastering the handful of switches in this guide — especially -a, -n, -o, -b, -s, and the interval parameter — will make it far easier to unstick port conflicts, diagnose performance issues, and spot suspicious connections on any Windows machine.
Source: Windows Report
How To Use Netstat Command To Check Ports And Connections