Isolating "Is It the Network or the App?"

Symptom

A request to a service is slow, times out, or returns an error, and it isn't immediately clear which layer is responsible: the network path itself, a load balancer or reverse proxy in front of the application, or the application process handling the request.

Likely causes

Roughly in order of how often each turns out to be the actual cause:

1. The application itself is slow (a slow database query, an external API call, resource exhaustion) or has crashed.
2. A proxy or load balancer in front of the application is misconfigured, has an unhealthy backend marked as up, or has its own timeout set shorter than the application needs.
3. DNS is resolving to the wrong address, or an old/cached address after a change.
4. Actual network connectivity is broken between the client and server — genuinely rare in a well-run internal network, but the first thing people guess and the least likely cause in practice.
5. TLS/certificate issues blocking the connection before any application logic runs at all.

Diagnostic steps

Work from the outside in — confirm each layer before assuming the next one is the problem:

1. Confirm DNS resolves correctly.

   nslookup the-hostname
   

   If this returns an unexpected or stale IP, stop here — see How DNS Resolution Actually Works.

2. Confirm basic network reachability to the resolved IP, not just the hostname.

   ping the-ip-address
   tracert the-ip-address
   

   tracert shows every hop the request takes — useful for spotting exactly where a path stops responding, though many hops legitimately don't reply to it and that alone isn't proof of a problem.

3. Test the actual HTTP layer directly, bypassing anything higher-level like a browser.

   curl -v https://the-hostname/
   

   The -v flag shows you the full request/response including TLS handshake detail and headers — read the status code returned (see HTTP Status Codes You'll Actually See in Production) as your next signal.

4. Check whether the proxy/load balancer or the application is answering. A 502/504 from a proxy in front of the app strongly suggests the application itself (crashed or too slow), not the network — see IIS Application Pools if IIS is in the chain. A connection that never completes at all, with no HTTP response whatsoever, points further back toward network or firewall issues.

5. Check the application's own health directly, if you can reach it without going through the proxy (a direct port, a health-check endpoint). If the app responds fine directly but not through the proxy, the proxy configuration itself is the suspect — check its timeout settings and backend health checks.

When to escalate

Escalate to network/infrastructure teams specifically when: tracert shows the request consistently failing at a hop under your organization's control (not just the public internet, where many hops routinely don't respond), or when the application responds correctly on a direct, un-proxied connection but fails specifically when routed through a shared load balancer or firewall that other teams manage. Escalate to the application/development team when the app is reachable and clearly the source (slow queries, exceptions in logs, crashing) — bringing them the specific evidence from steps 3-5 above, rather than "the site is slow," makes their investigation immediately faster.

What's next

Once you've isolated which layer is responsible, Root Cause Analysis: A Simple Framework covers how to go from "found the layer" to "found the actual fix." If the isolation above points at the application, Monitoring 101 covers which observability tool to reach for next.

Part of: Support Engineers, System Administrators

Continue learning

Mark this article as read

← Back to Troubleshooting Walkthroughs