$ Linux One Liners
Back to lessons

Web Server Rescue

Check What Is Actually Listening

A service appears started, but you need to confirm whether anything is listening on the expected port.

Command

ss -tulpn | grep ':80\|:443'

What changed

Nothing changes. The command lists listening sockets and the owning process when available.

Danger

safe

When to use it

Use this when debugging web server, API, SSH, or database connectivity.

When not to use it

Do not expose closed services just because a port is not listening; check config first.

Undo or recovery

No state is changed.

Expected output

Listening TCP or UDP sockets with local addresses, ports, and process names.

demo script

Disposable terminal steps

  1. ss -tulpn
  2. ss -tulpn | grep ':80\|:443'
  3. curl -I http://127.0.0.1:80
Terminal transcript Demo JSON

simulated output

What it looks like

disposable vessel 
::fixture-ready::
$ ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80        0.0.0.0:*     users:(("nginx",pid=17,fd=6))
tcp   LISTEN 0      128        127.0.0.1:8091      0.0.0.0:*     users:(("python3",pid=41,fd=3))
::exit-code::0
$ ss -tulpn | grep ':80\|:443'
tcp   LISTEN 0      511          0.0.0.0:80        0.0.0.0:*     users:(("nginx",pid=17,fd=6))
tcp   LISTEN 0      128        127.0.0.1:8091      0.0.0.0:*     users:(("python3",pid=41,fd=3))
::exit-code::0
$ curl -I http://127.0.0.1:80
HTTP/1.1 200 OK
server: fake-nginx
content-type: text/html

::exit-code::0

YouTube Short

Running is not the same as listening.

A service can look alive and still not answer on the port you expect. Check the socket before chasing the wrong layer.

LinkedIn hook

The app was running. The port was not listening.

Question: When a service is up but unreachable, do you check the port or the logs first?

experiments

A/B tests to run

Metric: short_click_through_rate

A: The app was running. The port was not listening.

B: Running is not the same as listening.