Testing connectivity

Key takeaways When something “won’t connect,” don’t guess — test. ping checks whether a host is reachable and how fast; traceroute shows the path your packets take and where it breaks; dig (or nslookup) confirms DNS is answering with the right address. Put them together as a layered diagnosis: work up from the bottom of the stack — does the name resolve, can I reach the IP, is the port open, does the app respond — and each layer’s result points at the next thing to check. That turns a vague failure into a specific answer.

“It won’t connect” is not a diagnosis — it’s a symptom with a dozen possible causes. The skill isn’t knowing every cause; it’s having a repeatable order of checks that eliminates them one at a time until the real one is left standing.

ping — is it reachable?

ping sends small ICMP echo request messages to a host and listens for the replies that come back. If replies arrive, the host is up and the path between you and it works; the round-trip time printed with each reply is your latency to that host.

$ ping example.com
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=11.4 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=11.2 ms

Steady, low times mean a healthy connection. Rising times or dropped replies point at congestion or a flaky link. One caveat: some hosts and firewalls block ping deliberately, so no reply is not proof the host is down — it may simply be ignoring ICMP while its real services answer fine. Treat a silent ping as “can’t confirm,” not “confirmed dead.”

traceroute — the path

When a host is slow or unreachable, traceroute (tracert on Windows) shows you where. It lists the hops — each router your packets pass through — between you and the destination, with a time for each.

$ traceroute example.com
 1  router.home  1.2 ms
 2  isp-gateway  9.8 ms
 3  * * *
 4  core1.isp    12.1 ms

Read it top to bottom: the hops climb steadily until they either reach the destination or stop advancing. A line of * * * that never recovers is where the path breaks; a hop where times suddenly jump is where it slows. That tells you whether the problem is near you, out in the middle, or at the far end.

dig / nslookup — is DNS working?

If a name won’t connect, the very first thing worth ruling out is name resolution. dig and nslookup ask a resolver directly and print what a name resolves to — so you can confirm DNS is answering and handing back the right address.

$ dig +short example.com
93.184.216.34

If that returns nothing, or returns an address that doesn’t match where the service actually lives, DNS is your culprit — no amount of pinging the name will help until the lookup is fixed. A successful lookup, by contrast, hands you the raw IP address to test the layers below with.

Is the port open?

A host being up doesn’t mean the service you want is running. Reaching the machine and reaching a specific port on it are two different questions. A quick way to check the second is to try opening a connection to that port:

$ nc -vz example.com 443
Connection to example.com 443 port [tcp/https] succeeded!

nc (netcat) or telnet host port will either connect — a service is listening there — or fail with “refused” or a timeout, meaning nothing is listening or a firewall is in the way. A machine can happily answer ping while the exact port you need stays closed, so this check catches problems the earlier ones miss.

A layered method

Each tool above answers one layer. Run them in the order the layers stack, and the first failure tells you where the problem lives. This mirrors how a web request works — the same steps, now used as a checklist:

  1. Does the name resolve? dig name — if not, it’s DNS.
  2. Can I reach the IP? ping the address or trace the route — if not, it’s the network path.
  3. Is the port open? nc -vz host port — if not, the service is down or a firewall is blocking it.
  4. Does the app respond? curl the URL — if the port is open but the app errors, the fault is in the service, not the network. (More on this in making requests with curl.)

The power is in reading the combination of results:

  • Works by IP but not by name → DNS. The path and service are fine; the name just isn’t resolving.
  • No ping but the port works → ICMP is blocked, not the host. The machine is up and serving; it’s simply ignoring pings.

Two facts together say more than either alone, which is why working the layers in order — and noting what passes as well as what fails — beats poking at random.

Quick check: a site loads when you use its IP address but not its domain name. The most likely culprit?

Recap

  • ping tests reachability and latency with ICMP echoes — but a blocked ping is “can’t confirm,” not “host down.”
  • traceroute shows the hops to the destination, so you can see where the path breaks or slows.
  • dig / nslookup confirm DNS is answering with the right address — rule this out first for name failures.
  • A port check (nc/telnet) confirms the service is listening, which is separate from the host being up.
  • Diagnose in layers — name, route, port, app — and read results together: “IP works, name doesn’t” → DNS; “no ping, port works” → ICMP blocked.

Next up: making requests with curl