Test the network in layers

“The network is down” usually means several independent systems failed at once, or one of them did and nobody checked which. Routing, DNS, TCP, TLS, and HTTP each have their own failure modes. Test them one at a time and stop at the first broken layer.

Start with routing and DNS

Before you touch the application, confirm this host knows how to reach the destination and can resolve the name:

ip route get 1.1.1.1

1.1.1.1 via 10.0.2.1 dev eth0 src 10.0.2.5 uid 1000

That shows the outbound interface, gateway, and source address. If routing is wrong here, nothing above it will work.

Then check name resolution:

dig +short app.example.com
# 203.0.113.40

An empty answer or a wrong address is a DNS problem, not an app problem. Fix or bypass DNS before you restart the service.

Walk up the stack

Each layer proves one thing. A working DNS answer does not prove TCP works. An open port does not prove TLS works. Run the checks in order and note where the first failure appears.

Use one command for each boundary:

ip route get 1.1.1.1
dig +short app.example.com
nc -vz app.example.com 443
curl -v https://app.example.com/health

Stop at the first failing layer. A correct DNS answer does not prove the port accepts connections, and an open port does not prove TLS or HTTP works. Save timestamps and exact errors before changing firewall, DNS, certificates, or application configuration.

Read what each result means

nc -vz app.example.com 443 succeeding means TCP reached something listening on 443. It says nothing about certificate validity or HTTP status codes.

curl -v https://app.example.com/health adds TLS and the application response. If nc passes but curl fails with a certificate error, you know the problem sits above TCP.

Trace one HTTPS request from the server where users report trouble. Write a single sentence naming the first failure, or confirming every tested boundary passed. That sentence becomes your scope for the rest of the investigation.