"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."
