Linux & servers
How do I find which process is listening on a port?
Short answer
On Linux, run ss with listening, TCP and process options, for example ss -ltnp, and look for the port. You may need elevated privileges to see processes owned by other users.
What changes the answer
- Which address it listens on, such as 127.0.0.1 or all interfaces
- Permission to view other users' processes
- A listening port can still be blocked by a firewall
Use ss
The ss utility reports socket statistics on Linux. To list listening TCP sockets with numeric ports and the owning process, run:
sudo ss -ltnp
The options mean listening sockets, TCP, numeric addresses, and process information. To narrow the result to one port, you can add a filter such as sport = :443, or pipe the output through grep. Without sudo, the process column can be empty for processes you do not own.
Read the local address column
The address tells you who can connect. A service bound to 127.0.0.1 accepts only connections from the same machine. One bound to 0.0.0.0 or [::] is listening on all addresses, so remote clients can reach it if nothing else blocks them. If you expected a public service but see only 127.0.0.1, check the application's bind address setting.
Common reasons for a surprise
- A previous instance of the service is still running and holds the port.
- Another application uses the port, so a new service fails with "address already in use".
- The service is listening on IPv6 only or IPv4 only.
A listening port is not proof of reachability
Seeing a process on a port shows it is accepting connections locally. A host firewall or a provider network rule can still block traffic from outside, and the troubleshooting checklist treats those as separate checks.
Be careful with the next step
If the wrong process owns the port, change its configuration or stop that specific service on purpose. On a shared server, do not stop processes you do not recognise, because other sites may depend on them.
Related checks
To see whether the service actually answers, request it locally with a tool such as curl, then from another machine. A local success with a remote failure often points to a bind-address or firewall difference rather than a broken application. Record the results, so you can tell support exactly which step behaves differently.