How to Check Open Ports on Linux
Check listening ports, confirm service bindings, and identify which process owns a port on Linux.
Before you start
Step-by-step instructions
1. List listening TCP and UDP ports with ss
Start with ss. This is the most practical first command on most modern Linux systems. It shows which ports are actually listening and includes local addresses, which helps you see whether the service is bound to localhost only or to all interfaces.
ss -tuln
Look at the local address and port columns. If you see 0.0.0.0:80 or *:80, the service is usually listening on all interfaces. If you see 127.0.0.1:80, it is typically local-only.
2. Filter for a specific port when troubleshooting one service
When you already know the target port, filter the result. This avoids noise and makes it much easier to confirm whether a service is listening where you expect it to.
ss -tuln | grep 3306If MySQL or MariaDB should be listening on port 3306 but nothing appears, the service may not be running, may have failed to bind, or may be configured for a different socket or address.
3. Check which process owns the port
If the port exists but you need to know which application is using it, switch to a process-level command. This is especially useful when diagnosing unexpected port conflicts or confirming that the correct service is bound.
lsof -i :3306This tells you which process name and PID are actually attached to the port. If the wrong application owns the port, your intended service may fail to start or bind properly.
4. Use netstat only when needed or on older environments
On some older systems, administrators still use netstat. It is not always installed by default on modern distributions, but it can still be useful in legacy environments or when existing operational notes already rely on it.
netstat -tuln
If netstat is missing, that is normal on many newer servers. Prefer ss unless you specifically need legacy output or tooling compatibility.
5. Separate local listening checks from firewall or external access checks
If a service is listening but still not reachable from outside, the problem may not be the service itself. At that point you should move to firewall, cloud security group, reverse proxy, or routing checks instead of assuming the port is not open locally.
ss -tuln | grep ':80\|:443'A listening local port means the service is bound locally. It does not guarantee that clients outside the machine can reach it. That depends on network policy and surrounding infrastructure.
Real example
An administrator expects a web service to be reachable from outside, but the site is down. Running ss -tuln | grep 8080 shows that the application is listening only on 127.0.0.1:8080, not on all interfaces. The service is running, but the binding configuration makes it local-only. The issue is not that the process is dead, but that its network exposure is different from what was expected.
This is why port checking is not just about whether a number appears. You must also inspect the address the service is bound to and match it against the intended access pattern.
Possible causes
- The service is not running at all
- The service failed to bind because of configuration or startup errors
- The port is owned by a different process than expected
- The application is listening only on localhost
- The service is using a different port than the one being checked
- External access is blocked by firewall or upstream network policy even though the service is listening locally
Common mistakes
- Assuming that a running service automatically means a listening port exists
- Checking only the port number and ignoring the bind address
- Confusing local listening state with external accessibility
- Using broad scans without filtering when troubleshooting a single service
- Ignoring port conflicts where another process already owns the expected port
Environment tips
- Use
ss -tulnas the default first check on modern Linux systems. - Use
lsof -i :PORTwhen you need process ownership details. - Check both port number and address binding when validating application exposure.
- Once local listening is confirmed, move separately to firewall, reverse proxy, or cloud security checks if remote access still fails.
About this guide
This guide shows how to check open and listening ports on Linux using practical commands such as ss, netstat, and lsof. It is written for real server troubleshooting, where you need to confirm whether a service is actually listening, which process owns the port, and whether the expected network binding is correct.
How to follow this guide
- Use ss first to list listening ports and confirm whether the expected service is actually bound.
- Filter the output when you need to check a specific port such as 80, 443, 3306, or 8080.
- Use lsof or process-level checks to see which application owns the port.
- Confirm the bind address because a service listening only on 127.0.0.1 behaves differently from one listening on 0.0.0.0.
- Check firewall or external access separately after confirming that the service is really listening.
Why use this method?
Checking open ports is one of the fastest ways to diagnose whether a service is running correctly, whether it is listening on the expected address, and whether a network or application problem is local or external. It is a basic but essential part of Linux server troubleshooting.
Frequently Asked Questions
What is the best command to check open ports on Linux?
On modern Linux systems, ss is usually the best first choice because it is fast and widely available. netstat can still be useful on older systems, and lsof is helpful when you want to see which process owns a port.
What is the difference between listening and open?
In everyday server troubleshooting, people often say open port when they really mean a local service is listening on that port. A listening port means the service is bound locally. External reachability still depends on firewall rules, routing, and network policy.
Why is my service running but the port does not appear?
The service may have failed to bind, may be listening only on a different interface, may have crashed after startup, or may be using a socket or internal mechanism instead of the port you expected.
Does seeing 127.0.0.1 mean the service is available externally?
No. If a service listens only on 127.0.0.1, it is usually available only from the local machine unless you add a proxy or change the bind configuration.