How to Check Listening Ports on Your System
Confirm whether a service is really waiting for incoming connections before you keep troubleshooting the wrong layer.
Before you start
When this guide is useful
Before blaming the network, verify that the local system is actually listening on the expected port.
The service may have failed to bind the port, started on a different port, or crashed after launch.
Another process may already be using the port, which prevents the intended service from listening there.
A local listening check tells you whether the problem starts inside the host itself or outside it.
Step-by-step instructions
1. Check listening ports on Linux with ss
On modern Linux systems, ss is often the fastest and clearest built-in tool for checking listening sockets.
ss -tulnpIt lists listening TCP and UDP sockets along with local address, port, and often the owning process information.
2. Filter Linux listening ports for one target port
If you already know the port you care about, filter the output so the result is easier to read.
ss -tulnp | grep :8080Change 8080 to the actual port your service is supposed to be using.
3. Use netstat on Linux if ss is not available
On some systems or older environments, netstat may still be available and useful.
netstat -tulnpMany real servers and older guides still use netstat, so it remains useful to recognize and read.
4. Check listening ports on Windows
On Windows, use netstat from Command Prompt to check whether the expected port is listening.
netstat -anoLook for lines showing the target port in a LISTENING state and note the PID shown at the end.
5. Filter Windows output for a specific port
When the output is too long, filter it to one port so you can confirm the listening state faster.
netstat -ano | findstr :8080If the service is really listening there, you should see the port appear with the expected state and PID.
6. Match the port to the owning process
Once you have the PID, match it to the real process so you know whether the correct service owns the port.
tasklist | findstr 1234ps -fp 1234If the wrong process owns the port, your intended service may have failed because the port was already taken.
7. Use the result to choose the next troubleshooting step
If the port is listening correctly, continue with firewall, routing, or external connectivity checks. If the port is not listening, fix the service or bind configuration first.
A missing listening socket means the problem starts inside the host, not out in the network path.
Common mistakes
If nothing is listening locally, firewall changes do not address the real cause.
Always confirm the expected service port from the actual application or service configuration first.
A port can be listening but owned by the wrong process, which still means your intended service failed.
The listening check is much more useful when you verify exactly which process is responsible for that port.
About this guide
This guide shows how to check listening ports on your own system when a service should be running but remote connections still fail. It focuses on practical checks for Linux and Windows so you can confirm whether the service is actually bound to the expected port, which process owns it, and whether the issue is really inside the application or elsewhere in the network path.
How to follow this guide
- Confirm which port your application or service is supposed to use.
- Check listening ports locally with ss, netstat, or the Windows equivalent.
- Verify which process or PID owns the port.
- Compare the listening result with your service configuration.
- If the port is not listening, troubleshoot the service first before blaming firewall or routing.
Why use this method?
Many connection problems are misdiagnosed as firewall or DNS issues when the real problem is simply that the service never opened the port at all. Checking listening ports is one of the fastest ways to separate service-level failure from network-level failure.
Frequently Asked Questions
What does a listening port mean?
It means a service or application is actively waiting for incoming connections on that port.
Why should I check listening ports before changing firewall settings?
If the service is not listening locally, opening the firewall will not fix the problem because there is nothing accepting the connection yet.
What is the difference between listening and established?
Listening means the service is waiting for new connections, while established means an active connection is already open.
Why does the wrong process sometimes own the port?
Another service may already be bound to that port, which can block your intended application from starting correctly.