Diagnose one complete connection

For a final exercise, choose a web service you control. Write down its hostname, expected addresses, transport protocol, port, and URL before testing.

We’ll walk through https://flaviocopes.com/ as an example. Expected: name resolves to Cloudflare addresses, TCP port 443, TLS, HTTP/2.

Step through each layer

Resolve the hostname first:

dig +short flaviocopes.com
# 104.21.4.157
# 172.67.132.90

Inspect the route the kernel would use for one of those addresses:

ip route get 104.21.4.157
# 104.21.4.157 via 192.168.1.1 dev wlan0 src 192.168.1.20

On the local link, check the neighbor entry for your default router:

ip neighbor show 192.168.1.1
# 192.168.1.1 dev wlan0 lladdr 9c:53:22:aa:04:1e REACHABLE

Test the TCP port, then inspect TLS and HTTP together:

curl -v https://flaviocopes.com/ -o /dev/null

* Connected to flaviocopes.com (104.21.4.157) port 443
* SSL connection using TLSv1.3
> GET / HTTP/2
< HTTP/2 200

If needed, capture the flow and match packets to each stage: DNS exchange, local frame delivery, routed IP packets, TCP handshake, TLS handshake, HTTP request, and response.

Write one precise sentence

Your result should be one precise sentence, such as: “DNS and routing work, but the server sends a TCP reset because no process listens on port 443.” That sentence is more actionable than “the Internet is down.”

Try the same sequence on a service you control. When something fails, stop at the first step that breaks and write that sentence before you change anything.

If DNS fails, fix name resolution before you touch routing. If TCP times out, check routes and firewalls before you blame the HTTP application. If TLS fails, read the certificate error before you restart the web server. Each layer has its own tools and its own fixes.

That habit is what turns this course from vocabulary into a workflow you can use every week. Save your notes from each run. The next time a similar symptom appears, you’ll know exactly which step to repeat first.