# Demonstration: Three Failures That Sound Similar But Aren't

## OBSERVE

All three of these LOOK like "it didn't work" — but each one rules out and rules in completely
different layers.

```
$ curl http://this-name-does-not-resolve.invalid/
curl: (6) Could not resolve host: this-name-does-not-resolve.invalid
```

## HYPOTHESIS

Which layer does THIS failure point at — DNS, routing, the port, or the application itself?

## INSPECT

"Could not resolve host" happens BEFORE any network connection is even attempted — it's purely a
DNS failure. No IP was ever found to connect to.

## CHANGE

Now a different failure, against a name that DOES resolve:

```
$ curl http://localhost:9999/
curl: (7) Failed to connect to localhost port 9999: Connection refused
```

DNS/name resolution already succeeded here (`localhost` always resolves). "Connection refused"
means a TCP packet reached the destination and was ACTIVELY rejected — almost always because
nothing is listening on that port.

## VERIFY

A third signature, distinct from both:

```
$ curl http://10.255.255.1:80/
curl: (28) Failed to connect to 10.255.255.1 port 80: Connection timed out
```

No response at all, not even a rejection — usually means the destination is unreachable
(no route, or blocked silently), not that something is running but declining you.

## Instructor Notes

**Demo goal:** Get students to viscerally distinguish these three error MESSAGES as three
different diagnostic starting points, not interchangeable "it's broken" signals.

**Approximate timing:** 10 minutes live.

**Common mistake to watch for:** treating every connection failure as "the network is down" —
each of these three messages should immediately narrow which layer to investigate next, per
Module 5's troubleshooting exercise.