Where am I and what is here?
pwdPrint the current working directory.ls -lahList files, including hidden entries, with readable sizes.find . -name '*.log' -type fFind matching files below the current directory.← Back to The BuildbookFREE COMMAND CHEAT SHEET · V1.0
Find the fault.
Follow the packets.
A practical command guide for the moment an application cannot connect, a name will not resolve, or a service is not listening. Start with the question you need to answer, then run the smallest useful check.
Trace one request, layer by layer
When a URL fails, check the path from the client toward the service. Each step answers a different question. A success at one layer does not prove the next layer works.
01 · NAMEDoes DNS return an address?
02 · ROUTECan packets leave this host?
03 · PORTIs a TCP listener reachable?
04 · HTTPWhat does the server return?
05 · APPDoes the service behave correctly?
A useful sequence:
dig → ip route → ss/nc → curl → application logs.Linux: inspect the host
These commands are read-only inspection tools. Some process details may require elevated privileges to show every user’s process.
Which process owns the work?
ps auxShow running processes and their resource usage.topWatch CPU and memory use update live; press q to quit.systemctl status my-serviceCheck a systemd service’s state and recent status text.Is the system under pressure?
df -hCheck free space on mounted filesystems.free -hSee memory totals and available memory.journalctl -u my-service -n 100Read the last 100 service log entries; avoid sharing secrets from logs.Where is the configuration?
grep -R "pattern" ./configSearch text recursively in a known directory.less /var/log/app.logRead a large log interactively; press q to quit.tail -n 50 -f app.logFollow new log lines; stop with Ctrl+C.Networking: ask one question at a time
Start with local configuration, then test name resolution, reachability, the listening socket, and finally the application response.
1. What addresses and routes exist?
ip addrList network interfaces and assigned addresses.ip routeShow routing table and default gateway.ip route get 1.1.1.1Ask the kernel which route it would use for a destination.2. Does the name resolve?
dig example.comQuery DNS and inspect the answer and resolver.dig +short example.comPrint just returned address records.getent hosts example.comCheck name resolution through the host’s configured lookup path.3. Is a service listening?
ss -lntpList listening TCP sockets; process details may need sudo.ss -sSummarize socket counts and connection states.nc -vz host.example 443Check whether a TCP connection to a host and port can be made.4. What does the endpoint say?
curl -I https://example.comInspect response headers without downloading the body.curl -v --max-time 5 https://example.comShow connection and TLS detail with a bounded timeout.curl -sS -o /dev/null -w '%{http_code}\n' URLPrint the HTTP status code. Replace URL with a trusted endpoint.Read the symptom. Pick the next check.
“Could not resolve host”
Run dig and getent hosts. Compare the answer with the expected record and check which resolver is configured.
“Connection refused”
The host replied, but the port is not accepting the connection. Check ss -lntp, the service state, bind address, and firewall rules.
“Operation timed out”
No timely response arrived. Check ip route, security groups/firewall, network ACLs, destination health, and whether the service is reachable from that network.
“401 / 403 / 404 / 5xx”
DNS and TCP likely worked. Inspect curl -i, request path, credentials, proxy/gateway response, and application logs.
“Works on my machine”
Compare DNS, environment variables, proxy settings, route, container port mapping, and service bind address between environments.
“It works sometimes”
Repeat a bounded check and compare timestamps. Look for DNS rotation, load balancer health, connection pool saturation, packet loss, and deploy changes.