Test one layer at a time

Start close to the failing program and move outward. If you control the server, first confirm that the process is running and listening on the expected address, protocol, and port — no network test means anything if the service itself is down.

Then work through the layers with one tool per question:

dig example.com
nc -vz example.com 443
curl -v https://example.com/

What each test proves

Resolve the name with dig and check two things in the answer:

dig +short example.com
# 93.184.215.14

Did an address come back at all, and is it the address you expected? A stale DNS record pointing at a decommissioned server passes every other test on the wrong machine.

Test the exact TCP port with nc -vz host port:

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

succeeded! means the TCP handshake completed: route works, port reachable, something is listening. Connection refused means you reached the host but nothing listens there. A hang means packets are vanishing — routing or a silent firewall.

For HTTP, use curl -v so DNS, connection, TLS, and HTTP events are visible separately:

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

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

Each * line is a layer succeeding in real time. Wherever the output stops is your failing layer — after Connected but before the TLS line means a certificate or TLS problem, not a network problem.

Inspect the selected route with ip route get <address> if the connection test hangs; it tells you which interface and gateway your machine actually chose.

One test, one question

A test should answer one question. Ping is not a port test, and a TCP connection is not an HTTP health check. When a test bundles several layers — like opening the URL in a browser — a failure tells you almost nothing about where the problem lives.

Stop when you find the first failed boundary. Everything past it is guaranteed broken for the same reason, so testing further just accumulates noise. The classic mistake runs the sequence backwards: the browser fails, so you clear caches, restart the router, and edit configuration — before ever learning whether DNS, TCP, TLS, or HTTP was the failing step. Three commands, run in order, replace an hour of guessing.