"It's probably a network issue" is the phrase that ends more productive debugging sessions than it should, usually because nobody has a systematic way to actually confirm or rule that out, so it becomes a shrug instead of a diagnosis. Here's the checklist I actually run through, roughly in order, when something's acting weird and the network is a suspect.
Confirm it's actually the network before you go further. Before diving into network-specific tools, rule out the obvious alternative: is the thing on the other end actually up and healthy. A "connection refused" or timeout can look identical whether the network is broken or the destination service just isn't running. Check the target service's own health and logs first. This sounds obvious and gets skipped constantly, people start troubleshooting DNS and routing for twenty minutes before checking whether the destination process is even alive.
DNS first, because it's the most common "not actually networking" networking problem. A huge share of connectivity issues that look like deep network problems are actually DNS not resolving correctly, or resolving to something unexpected. Test resolution directly, does the hostname resolve to the IP you expect, from the machine that's actually having the problem, not from your laptop which might have a completely different DNS setup. Mismatched or stale DNS is a disproportionately common root cause for something that presents as "can't connect."
Basic reachability, the layer people skip because it feels too simple. Can you actually reach the destination at all, at a basic network level, independent of whatever application protocol is failing. Simple reachability tests tell you whether you've got a network-layer problem versus an application-layer one, and skipping this step means you might spend an hour debugging application logic for a problem that's actually "the two machines can't talk to each other at all," which a two-second check would have shown immediately.
Ports and firewalls, the classic "it's not you, it's the wall between you." If basic reachability works but the specific service still won't connect, suspect something blocking the specific port, a firewall rule, a security group, a network policy. This is an extremely common cause of "works from this machine, not from that one," because it usually means different firewall rules apply, not that anything about the application itself changed. Check what's actually allowed through, on both ends, not just what you assume is configured.
Latency and packet loss, when it's not fully broken but it's acting broken. Sometimes nothing is fully down, it's just degraded enough to cause timeouts, retries, and flaky behavior that looks like a bug in your application but is actually the network being slow or lossy. Check actual latency and packet loss between the relevant points, because intermittent, flaky failures are a classic signature of a degraded link rather than a fully broken one, and treating it as an application bug will send you looking in the wrong place entirely.
Check both directions, because asymmetric routing is a real and confusing thing. It's possible for traffic to flow fine in one direction and be blocked or broken in the other, especially in complex network setups with asymmetric routing or one-directional firewall rules. If something seems to partially work, requests appear to go out but responses never come back, checking connectivity in only one direction will miss this entirely. Verify both ways when the symptoms are asymmetric or confusing.
Actually look at the traffic, don't just infer it. When the above steps haven't found the culprit,
This article was originally published by DEV Community and written by Mr Recruiter.
Read original article on DEV Community