Web Server Rescue
Read-only, can be slowCheck 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'Before you run this
System impact: Read-only. Can create load on large logs, directories, filesystems, or process tables.
When not to use it: Do not expose closed services just because a port is not listening; check config first. Inside containers, remember you are seeing that container's network namespace, not the host.
Expected output
Listening TCP or UDP sockets with local address, port, state, and process names when permissions allow. LISTEN means the machine is accepting new connections on that address; ESTABLISHED is an existing session and is not proof that a server is bound for new clients.
System impact
Read-only, can be slow. Nothing changes. The command lists listening sockets and the owning process when available. The temporary shell lab uses an unprivileged local test service on port 8443 instead of binding 80 or 443.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use this when debugging web server, API, SSH, or database connectivity. On real web servers, the production command filters for ports 80 and 443.
When not to use it
Do not expose closed services just because a port is not listening; check config first. Inside containers, remember you are seeing that container's network namespace, not the host.
Common misread
A process name in ss output does not mean the port is reachable from the network. Check LISTEN vs ESTABLISHED, bind address, firewall, container mapping, and the expected service owner before killing or restarting anything.
LISTEN vs ESTABLISHED
LISTEN is the server socket waiting for new connections. ESTABLISHED is a current connection between two endpoints. For 'port already in use' or 'site unreachable', start with LISTEN rows.
ss -ltnpss -tan state established
PID and owner interpretation
Use the process column as a starting point, not permission to kill. If the process belongs to systemd, Docker, a process manager, or a login shell, inspect that owner before stopping anything.
ps -fp 4242systemctl status nginx --no-pager --lines=30docker ps --format 'table {{.Names}}\t{{.Ports}}'
Bad move to avoid
Do not kill before identifying the owner. A production proxy, database, container publish rule, or supervisor may immediately restart the process or break a dependent service.
next steps
Related commands
Find Listening Ports with ss
Before blaming the firewall, check whether anything is actually listening.
ss -ltnp
List Listening Ports on a VPS
Unexpected network listeners are first-response evidence.
ss -ltnp
List Listening TCP Sockets
Firewall rules matter after you know what is listening.
ss -ltnp
Show Published Container Ports
When a service is unreachable, confirm Docker is publishing the port you think it is.
docker port web
Your Site Is Not Down. DNS Might Be Lying.
The browser said the site was gone. The server was answering fine.
curl --resolve example.com:443:203.0.113.10 https://example.com/
next diagnostic step
Where to go from this command
- Port already in use problem hub Use this when the listener belongs to an unknown or conflicting service.
- Open ports troubleshooting guide Separate listener state, firewall, and bind address before changing services.
- systemd service failed problem hub Use when the port conflict is caused by a failed or restart-looping service.
Study mapping
Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.