Quiz
Warm-up, the whole course in one question: put these in the order they happen for one page load: (A) TLS handshake, (B) DNS lookup, (C) HTTP request, (D) TCP handshake.
"It does not connect"
Every connectivity problem, from "the site is down" to "my API call hangs", yields to the same method: test each layer in the order it happens, bottom up. The first layer that fails is your culprit, and everything after it is noise.
| Step | Question | Tool | Failure looks like |
|---|---|---|---|
| 1. DNS | Does the name resolve? | dig +short host | no output, or curl: (6) Could not resolve host |
| 2. Reachability | Does the machine answer at all? | ping host | 100% packet loss |
| 3. TCP | Is the port open? | curl -v, or nc -z host port | Connection refused or a hang then timeout |
| 4. TLS | Does the handshake complete? | curl -vI https://host | certificate has expired, (60) SSL... |
| 5. HTTP | What status code? | curl -s -o /dev/null -w '%{http_code}\n' | 4xx (your request) or 5xx (their server) |
Two refinements from experience. Connection refused is actually a fast, useful failure: the machine is up and actively said "nothing listens on that port", so check the port number and whether the service is running. A silent timeout instead suggests a firewall is eating your packets. And if DNS fails, test a known-good name like example.com next, to learn whether it is that one domain or your whole resolver.
A real debugging session. A teammate reports "api.shop.test is down!". Walk the checklist and find the true failing layer.
Step 1/4: Step 1, DNS. It resolves fine, so the name is not the problem.
Quiz
curl to your API hangs for 30 seconds, then reports a timeout. ping to the same host works. dig resolves it fine. Most likely culprit?