1. Define what failed
Record who is affected, which service fails and when it began. Write down the exact error. Compare an affected client with one that works.
- Is the failure limited to one device, one VLAN or one site?
- Did a deployment, policy or DNS change precede it?
- Does an IP connection work while a hostname fails?
- Avoid restarting everything before collecting useful evidence.
2. Verify the local path
Check physical link state, address, prefix, default route and DNS configuration. Test a nearby endpoint before moving outward.
- Linux — ip address; ip route; resolvectl status (where available).
- Windows PowerShell — Get-NetIPConfiguration; Get-NetRoute; Get-DnsClientServerAddress.
- Check for duplicate addresses or an unexpected DHCP lease.
- Record interface errors and link speed.
3. Separate name, transport and service
Test each dependency independently. A host that does not answer ping may still serve HTTPS; an ICMP response does not prove the application is healthy.
- DNS — dig example.com or Resolve-DnsName example.com.
- Transport — Test-NetConnection example.com -Port 443 on Windows.
- HTTP — curl -I https://example.com on Linux; curl.exe on Windows.
- TLS — inspect certificate validity, hostname and trust chain.
4. Verify the fix and leave a record
Change one thing, repeat the original test and check related services. Document the cause, evidence, change and rollback.
- Use packet captures only where authorised, and protect captured data.
- Check client and server clocks when correlating logs.
- Avoid treating traceroute timeouts as proof of a broken forwarding path.
- Keep the successful test as a future baseline.