Inspecting Connections

In one line

ss, lsof, and curl let you answer three of the most common networking questions on a Linux machine: what's listening on this port, what process owns this connection, and does this endpoint actually respond correctly.

0/4 · 0%

Think of it like this

Real-life example: ss (socket statistics) is like checking which phone lines in a building are currently active and which extension each one belongs to — a direct inventory of every network connection and listening port on the machine right now.

Key ideas

01
ss -tulpn is the single most useful incantation to memorize: -t (TCP), -u (UDP), -l (listening sockets only — i.e. things WAITING for incoming connections, like a running web server), -p (show the owning process), -n (show numeric ports instead of resolved service names, usually clearer). This answers 'what's actually listening on this machine, and what process owns it' in one command.
02
You will still see netstat -tulpn in older guides and on older servers: it is the predecessor of ss from the net-tools package (often not installed on modern distributions), with nearly identical flags and output. Learn ss, but recognise netstat when you meet it.
03
lsof -i :8080 (list open files — sockets count as 'files' on Unix-like systems) shows exactly which process has port 8080 open — genuinely essential for the extremely common 'why is this port already in use' problem when trying to start a second service on the same port.
04
curl makes an actual HTTP request from the command line — curl http://localhost:8080/health hits an endpoint directly and shows the response body, while curl -I shows just the response HEADERS (status code, content type) without the full body — often exactly what you need for a quick health check.
05
curl -v (verbose) shows the ENTIRE exchange — the request being sent, every response header, timing information — genuinely invaluable when debugging why a request isn't behaving as expected, since it shows precisely what went over the wire in both directions.
06
nc (netcat, sometimes called 'the network Swiss army knife') can test raw TCP connectivity to any host and port: nc -zv <host> <port> checks whether a port is open and reachable without sending any real application data — useful for testing connectivity to something that isn't HTTP at all (like a raw database port).

Code & diagrams

inspect-connections.shmarkdown

Read-only investigation commands — safe on any machine.

# What's listening, and which process owns it?
ss -tulpn

# What's using a SPECIFIC port?
lsof -i :8080

# Make a real HTTP request and see the response
curl http://localhost:8080/health

# See just the response headers (status code, content-type, etc.)
curl -I http://localhost:8080/health

# See the FULL request/response exchange, for debugging
curl -v http://localhost:8080/health

# Test raw TCP connectivity to a non-HTTP port (e.g. Postgres)
nc -zv localhost 5432

Explain it without notes

You try to start a service and get 'address already in use' on port 8080. What's the exact sequence of commands to diagnose and fix this?

Why would you use curl -I instead of a plain curl when checking if a service is healthy?

Practice

Start any simple local server (even python3 -m http.server 8000 works as a zero-dependency test target) and use lsof to confirm exactly which process owns port 8000.

Use curl -v against any real website and identify the HTTP status code and at least two response headers in the output.

Trade-offs

↔
curl is fast and scriptable but doesn't render anything visually — for genuinely exploring an API's behavior interactively, a dedicated tool (Postman, or even a browser's dev tools Network tab) may be more convenient; curl's real strength is being scriptable and available on literally every Linux server with zero setup, which matters most in a production debugging context.

Done when you can

I can find what's listening on a port and which process owns it using ss or lsof.
I can make a request with curl and inspect just the headers with -I.
I know how to diagnose and fix a 'port already in use' error.