Network Troubleshooting 101: DNS, Redirects, and Caching

Diagnosing the Invisible Infrastructure

When a user reports a site is unreachable, the problem could be anywhere from their local ISP to your edge servers. Having the right diagnostic tools is essential. Network troubleshooting requires a systematic approach: start at the client side and work your way up the stack to the server. The most common failure points fall into four categories: DNS resolution failures, routing and redirect issues, SSL/TLS certificate errors, and caching problems across multiple layers. Each category requires different diagnostic tools and techniques, and learning to quickly identify which category a problem falls into is the skill that separates novice administrators from experienced engineers. A structured troubleshooting methodology reduces downtime from hours to minutes.

DNS Troubleshooting

DNS Propagation Delays

Just updated your nameservers? DNS changes take time to propagate globally. Verify exactly where your domain resolves using a DNS Propagation Checker. When you change DNS records, the update does not reach every DNS resolver instantaneously. Each resolver caches the previous record according to its Time to Live (TTL) value. During propagation, some users will see the old record and some the new one. To minimise propagation issues, always lower the TTL on records you plan to change to 300 seconds (5 minutes) at least 24 hours before making the change. After the change propagates, raise the TTL back to a standard value (3600 seconds for most records, or higher for stable records). Use a DNS Propagation Checker to query multiple global locations simultaneously and see exactly which resolvers have picked up the change. If some locations still show the old record after 24 hours, flush your authoritative DNS cache and verify the record at the registrar level.

Common DNS Misconfigurations

Beyond propagation delays, several DNS misconfigurations cause chronic issues. Missing or incorrect AAAA records prevent IPv6-only users from reaching your site. Stale NS records pointing to decommissioned name servers cause resolution failures. Mismatched SOA records between primary and secondary name servers create inconsistency. CNAME records at the zone apex (the bare domain without www) break the DNS specification — use an ALIAS or ANAME record instead, or redirect the apex to the www subdomain via your DNS provider. TXT record errors — particularly with SPF, DKIM, and DMARC — cause email delivery failures that are difficult to trace back to DNS. Use a DNS Propagation Checker combined with a DNS record audit to catch these issues before they affect users. For email authentication specifically, verify that your SPF record includes all authorised sending sources and does not exceed the 10-lookup limit, and that your DKIM key is correctly published as a TXT record matching the selector in your email headers.

Redirect and Routing Analysis

Tracing Redirect Chains

Redirect loops and excessive 301 chains hurt SEO and degrade performance. Uncover exactly how traffic flows to your final URL using a Redirect Tracer. Every redirect adds an additional HTTP round trip, increasing page load time by 200-500ms per hop. A chain of five redirects can add over a second to load time before the page even starts rendering. Beyond performance, redirect chains dilute PageRank — each hop passes only a portion of the original link equity to the destination. Use a Redirect Tracer to map the full path from the initial URL to the final destination. Ideal configurations have zero or one redirect. Common problems include HTTP to HTTPS redirects followed by www to non-www redirects (or vice versa) — consolidate these into a single redirect using the web server configuration. Check for mixed-content issues where HTTPS pages load HTTP resources, which modern browsers block. Use a URL Parser to inspect and normalise URLs before testing redirect paths, especially when dealing with complex query parameters and fragments that can cause unexpected behaviour.

SSL/TLS Certificate Verification

SSL/TLS errors are among the most disruptive issues for users because browsers display prominent warning screens that stop them from proceeding. Common SSL errors include expired certificates, hostname mismatches, self-signed certificates in production, and incomplete certificate chains where the server does not send intermediate certificates. Use an SSL Checker to verify your certificate configuration from an external perspective. The tool checks certificate validity dates, chain completeness, protocol support (TLS 1.2 and 1.3 only — TLS 1.0 and 1.1 should be disabled), cipher strength, and HSTS headers. For Let's Encrypt certificates, which have a 90-day validity period, automate renewal checks to prevent unexpected expirations. Monitor certificate status in your server monitoring dashboard and set alerts for certificates expiring within 30 days. When diagnosing user-reported SSL errors, verify that your SSL configuration is correct from multiple geographic locations — some CDNs and load balancers can serve different certificates depending on the edge node.

Caching Layers and How to Troubleshoot Them

Caching exists at every level of the web stack: browser cache, CDN cache, reverse proxy cache (Varnish, Nginx), application cache (Redis, Memcached), and database query cache. While caching is essential for performance, stale caches cause some of the most frustrating and hard-to-diagnose bugs. When a user reports seeing old content after you have published updates, start by checking whether the issue is local to their browser. Instruct them to perform a hard refresh (Ctrl+F5 or Cmd+Shift+R) and clear their browser cache. If the problem persists, check your CDN cache — most CDNs support cache purging by URL pattern. For application-level caches, flush the relevant Redis keys or Memcached namespaces. Set appropriate Cache-Control headers: short max-age (5-10 minutes) for HTML pages, longer max-age (one year with immutable directive) for versioned static assets like CSS and JavaScript, and no-cache for API responses that must always be fresh. Use a Redirect Tracer in combination with cache header inspection to verify that cached resources are served with correct caching directives and that redirect chains do not interfere with cache policies. For CDN-specific issues, check the CDN's cache hit ratio dashboard and investigate URLs with an abnormally high miss rate — they may have unique query parameters that bypass caching, requiring a URL Parser to normalise and debug the parameter structure.