Short answer: define the failure precisely, find its scope, form a testable hypothesis, and collect evidence that can rule it out. Change one relevant thing with a rollback plan, then repeat the original failing operation. Connectivity tests only prove the protocol, destination, and conditions they actually exercised.
Useful foundations: route selection, neighbor resolution, and DNS resolution.
Think like a bicycle mechanic
A rider reports that a bicycle makes a clicking sound. A mechanic asks whether it happens while pedaling, braking, or coasting, then reproduces it and isolates a component. Replacing the wheel, chain, and pedals together might silence it without explaining why. A network report such as "the internet is down" needs the same refinement: which application, client, network, destination, and time? A DNS error is different from a TCP timeout or an HTTP 403.
A repeatable workflow
- Define: record the exact operation, error, timestamp/time zone, source interface, and destination name/IP/port. Note VPN and proxy use.
- Scope: compare one affected and one unaffected client, or the same client on two approved paths. Keep other conditions comparable.
- Hypothesize: "The client received the wrong DNS server" predicts a resolver mismatch. "The network is broken" predicts nothing specific.
- Test: inspect the configured resolver and query the intended one. Decide in advance what result would contradict your hypothesis.
- Change and verify: apply an authorized, reversible correction. Repeat the original test and check related services, not just a convenient ping.
Checking the bicycle's chain while coasting tells you little about a noise that happens only under pedal load. Likewise, a successful TCP connection from your admin laptop doesn't reproduce a user's Wi-Fi path, identity, proxy, or application request.
Inspect before changing
The following are read-only inspection commands. Linux examples assume iproute2; tools and output vary by distribution. Record only the relevant fields and protect internal names, addresses, and identifiers before sharing output.
| Question | Windows PowerShell | Linux shell |
|---|---|---|
| Address, gateway, DNS? | Get-NetIPConfiguration | ip address show; resolvectl status on systemd-resolved hosts |
| Installed IPv4 routes? | Get-NetRoute -AddressFamily IPv4 | ip -4 route show |
| Selected route to the target? | Find-NetRoute -RemoteIPAddress 192.0.2.20 | ip route get 192.0.2.20 |
| Neighbor state? | Get-NetNeighbor -AddressFamily IPv4 | ip neigh show |
| Local TCP listeners? | Get-NetTCPConnection -State Listen | ss -lnt |
192.0.2.20 is a documentation address, not a real test service. Substitute an approved target. An IPv4 169.254.x.x address on a DHCP-configured client may indicate that no usable DHCP lease was obtained; it doesn't by itself identify why. A missing ARP entry can simply mean the client hasn't tried that neighbor recently. For IPv6, inspect IPv6 routes and NDP instead of assuming the IPv4 result covers both families.
Active tests and their limits
| Test | Windows / Linux example | What it does not prove |
|---|---|---|
| Four ICMP echo requests | ping -n 4 192.0.2.20 / ping -c 4 192.0.2.20 | No reply doesn't prove the host is down; ICMP may be filtered or rate-limited |
| Observed hops | tracert -d 192.0.2.20 / traceroute -n 192.0.2.20 | Missing intermediate replies don't prove forwarding loss; probe protocols and return paths differ |
| DNS A record | Resolve-DnsName app.example -Type A / dig app.example A | A response doesn't prove it is the intended answer or the resolver path used by the application |
| TCP port | Test-NetConnection 192.0.2.20 -Port 443 / nc -vz -w 3 192.0.2.20 443 (OpenBSD-style netcat) | A completed handshake doesn't prove TLS, HTTP, authentication, or UDP/QUIC works |
| HTTPS request | curl.exe --connect-timeout 3 --max-time 10 -I https://app.example/ / use curl on Linux | HEAD may behave differently from GET; curl may use different proxy/trust settings than the browser |
app.example is reserved for documentation. Replace it with your approved service name. In Windows PowerShell, use curl.exe to avoid the older curl alias for Invoke-WebRequest. Do not use -k to hide a certificate failure. A trust error is evidence to investigate, not a successful health check with an inconvenient warning.
Worked case: name resolution fails, the service responds
In a synthetic lab, a client has 10.20.0.42/24, gateway 10.20.0.1, and a configured resolver at 10.20.0.53. An approved HTTPS endpoint is 192.0.2.20. The application name fails to resolve. Start by recording the failing query and resolver, then run these separate, bounded Windows checks after substituting real lab values:
Resolve-DnsName app.example -Server 10.20.0.53 -Type A
Test-NetConnection 192.0.2.20 -Port 443
curl.exe --connect-timeout 3 --max-time 10 --resolve app.example:443:192.0.2.20 -I https://app.example/--resolve supplies an address while retaining the URL hostname for TLS SNI, certificate verification, and HTTP host selection. Using https://192.0.2.20/ instead would change those conditions. The bypass comparison assumes a direct connection; an HTTPS proxy may resolve/connect to the origin itself. Inspect approved proxy settings rather than bypassing organizational controls.
| Synthetic observation | Supported conclusion | Next check |
|---|---|---|
| DNS query times out | No usable reply from that resolver during the test | Resolver health and the DNS path; timeout is not NXDOMAIN |
| TCP 443 succeeds | A TCP connection to that address/port completed | Keep testing the intended TLS name and HTTP operation |
| Named curl bypass validates TLS and receives HTTP 200 | That direct endpoint answered the test request without DNS lookup | Investigate the resolution path; this is not proof that every application dependency is healthy |
The mechanic now has a repeatable test under load, not a guess. Compare the configured DNS server with the intended DHCP option or managed configuration, then investigate that discrepancy. Don't replace corporate DNS with a public resolver as a blanket fix: private names and split DNS may require the original infrastructure.
Common misreadings
- "Traceroute hop 4 loses 80%, so hop 4 is broken": if later hops and the endpoint respond normally, that router may only be limiting control-plane replies. Compare end-to-end loss for the actual flow.
- "The gateway responds, so routing is fine": the next-hop interface can answer ICMP while its upstream route, policy, NAT state, or return path is wrong.
- "Only large transfers stall, but ping works": investigate path MTU discovery, filtering, retransmissions, and application behavior. A tiny echo request doesn't exercise the same packet sizes.
- "Restarting fixed it": it restored service, but may have removed the cache, counters, or logs needed to explain the cause. Record before/after evidence when operationally possible.
Record the symptom, scope, timestamp/time zone, tested source/destination/protocol, exact command, result, hypothesis, change, and verification. Keep captures and sensitive output in approved storage. Recovery and root-cause confirmation are separate outcomes.
Related topics
Go deeper with packet capture, ICMP, MTU and fragmentation, and the full request path.
Sources
- Microsoft: Test-NetConnection and Resolve-DnsName.
- iproute2: ip manual.
- curl manual: timeouts, HEAD, certificate verification, and --resolve.