Debugging Network Issues: DNS, SSL, and Headers

"The site is down" is usually a lie - the site is fine, and something between you and it is not. Before you blame the application, check the three layers underneath: DNS resolution, the TLS certificate, and the response headers. Each has its own failure signature, and each can be checked in seconds without leaving the browser. If you just need the headline answer first, the Website Status Checker reports whether the site is reachable at all before you dig into layers.

Layer 1: DNS - does the name resolve to what you expect?

DNS problems look like "it works on my machine" - because your resolver or hosts file differs from the user's. When a domain behaves differently for different people, start by querying the actual records with the DNS Lookup tool. Check the A and AAAA records against the IP your provider says the site should be on, and look at MX and TXT records when email or verification is the complaint. The record types and their semantics are defined in RFC 1035, the DNS specification, when you need the ground truth.

Common findings: a stale A record pointing at an old server after a migration, missing CNAME for www, or a TXT record that never got added - which is why a domain's email keeps failing SPF checks. DNS changes also propagate slowly, so when a record looks wrong, note whether it is simply old rather than broken.

Layer 2: SSL - is the certificate valid, and for the right names?

Certificate errors usually mean one of three things: the certificate expired, it does not cover the hostname being requested, or something in the middle is intercepting traffic. The SSL Checker pulls the certificate from public Certificate Transparency logs and shows the issuer, validity window, and the subject alternative names it actually covers. The protocol itself is specified in RFC 8446, the TLS 1.3 specification, if you need the details behind the certificate.

The classic gotcha: a certificate valid for example.com but not www.example.com, or vice versa. The SAN list is the ground truth - if the hostname is not in it, browsers will show a warning no matter how valid the dates are. And if the checker finds no certificate at all for a domain that should have one, that is usually a proxy or load-balancer misconfiguration rather than a missing purchase. If the domain registration itself is close to expiring - a different failure that looks identical from the outside - the WHOIS Lookup shows registration and expiry dates.

Layer 3: Headers - what is the server actually saying?

When the connection works but the behaviour is wrong, read the response headers. The HTTP Header Checker fetches a URL and shows exactly what the server sent, which answers a surprising number of "why is this broken" questions - and when the status code itself is the only clue, the HTTP Status Codes reference explains what each one means:

Is a redirect chain bouncing the request somewhere unexpected? Check location and how many hops happened.
Is caching serving stale content? Look at cache-control and etag.
Is a CDN or WAF blocking the request? Missing expected headers, or odd server values, are the tell.
Are security headers missing? That is a compliance issue for production, not a bug - but worth knowing about.

Layer 4: CORS - the one that only appears in the browser

CORS failures are the strangest to debug because curl cannot reproduce them - the browser enforces the policy, not the server. The CORS Tester sends a request with a chosen Origin header and reports which access-control-* headers actually came back. If access-control-allow-origin does not match your origin, the fix belongs in the API configuration, not in the frontend.

Putting it together

Next time something "does not work", walk the layers in order: resolve the name, check the certificate, read the headers, test the CORS policy. Nine times out of ten the answer is in one of those four places - and you will have the evidence ready when the report needs to go upstream.