Guides

Step-by-step tutorials and practical fixes for servers, systems, email, and daily technical work.
Linux Guides

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

You need shell access to the Linux server.
A listening port confirms local binding, not automatic external accessibility.
Always confirm both the port number and the bind address before concluding that a service is reachable.

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.

Command 
ss -tuln
How to read it

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.

Command 
ss -tuln | grep 3306
Real use case

If 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.

Command 
lsof -i :3306
Why this matters

This 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.

Command 
netstat -tuln
Practical note

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.

Example follow-up 
ss -tuln | grep ':80\|:443'
Important distinction

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 -tuln as the default first check on modern Linux systems.
  • Use lsof -i :PORT when 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.