Network Diagnostics: The Systematic Workflow From Ping to Port Scan

When the internet "breaks," a systematic diagnostic workflow finds the problem in minutes rather than hours

A website is unreachable. Is it the DNS? The server? The network path? The client machine? A systematic approach works through the diagnostic layers in order, eliminating possibilities at each step. Without a structured approach, troubleshooting turns into guesswork that jumps between theories.

The workflow uses four tools in sequence: ping → DNS lookup → traceroute → port scan. Each answers a specific question and eliminates a layer of uncertainty.

The four-layer diagnostic workflow

Step 1: Ping — is the host reachable?

ping example.com
ping 93.184.216.34  # Ping the IP directly

What the result tells you:

Successful ping (replies received): the host is reachable via ICMP and has low enough latency for basic connectivity. The network path is functional.

Request timeout (no replies): either the host blocks ICMP (very common — many servers drop ping requests for security), the host is down, or the network path has a problem. This is ambiguous — can't conclude the host is unreachable just from a failed ping.

DNS resolution failure ("could not find host" or "Name or service not known"): the domain name couldn't be resolved to an IP address. This eliminates the network problem and points to DNS.

Key insight from ping:

• If ping example.com fails with DNS error but ping 93.184.216.34 succeeds → DNS problem
• If both fail → network connectivity problem
• If both succeed but the website is still unreachable → the specific service (HTTP/HTTPS) is unavailable, but the host is up

Step 2: DNS lookup — is the DNS resolving correctly?

nslookup example.com
dig example.com A

What to check:

Is the A record returning the expected IP address? If you know what the IP should be, compare.

Is there a result at all? No answer or NXDOMAIN means the domain doesn't exist or the DNS record is missing.

Is the answer coming from the authoritative nameserver or a cache? Add @8.8.8.8 to query Google's resolver directly:

dig @8.8.8.8 example.com A

If DNS is returning the wrong IP: a cached stale record, a DNS hijacking, or a misconfigured DNS record. Use the NS Lookup tool to identify the authoritative nameservers and query them directly.

If DNS resolves correctly but the site is unreachable: the problem is at the network or application layer, not DNS.

Step 3: Traceroute — where does the path break?

traceroute example.com          # Linux/Mac
tracert example.com             # Windows
mtr --report example.com        # Better: MTR gives statistics

What to look for:

Hops that complete successfully, then * * * (no response) from that point onward → traffic is being blocked or the route fails at that hop. The last successful hop is where the path breaks.

A single * * * hop followed by successful subsequent hops → the middle hop blocks ICMP probes but forwards traffic normally (not a real problem).

Latency jumping dramatically at a specific hop and staying elevated → the problem is introduced at that hop (geographic distance, congested link, or a network issue).

Step 4: Port scan — is the specific service running?

If ping and traceroute succeed (the host is reachable) but the website is down:

nmap -p 80,443 example.com      # Check HTTP and HTTPS ports
telnet example.com 443          # Simple connection test
openssl s_client -connect example.com:443  # Test HTTPS specifically

Or use the Port Scanner tool at sadiqbd.com.

Open port → service is running but returning errors: problem is at the application layer (web server configured incorrectly, certificate error, application error)

Closed port → server responds with RST (connection refused): the service is not running on that port, or a firewall is blocking the specific port

Filtered port → no response (timeout): a firewall is dropping the probe silently

The client-side vs. remote-side distinction

Before starting the diagnostic workflow, check if the problem is local:

Try from another network: use your phone's mobile data, a different office location, or a VPN to a different region. If the site works from another network but not yours → the problem is somewhere in your network or ISP.

Try from multiple browsers/devices: if one browser shows an error but another works → browser-specific issue (cached bad response, extension interference).

Check if others see the problem: sites like downdetector.com, isitdownrightnow.com, or simply asking colleagues let you quickly distinguish "my problem" from "their problem."

Common failure scenarios and the diagnostic path

"Website returns 'server not found'"

1. Ping → DNS resolution fails
2. DNS lookup → returns NXDOMAIN or wrong IP
3. Check: was the domain renewed? Are the DNS records correct? Is the domain registered?

"Website worked yesterday, not today"

1. Ping → succeeds (IP is reachable)
2. Port scan → port 80/443 closed
3. Check: was the web server stopped? Was a firewall rule added? Did auto-renewal of an SSL certificate fail, causing the server to not start?

"Website loads for me but not for users in another country"

1. Traceroute from your location → succeeds
2. Use online traceroute tools from multiple global locations
3. Check: CDN misconfiguration, DNS geo-routing issues, regional server failure

"HTTPS shows certificate error"

1. SSL checker → certificate expired, wrong domain, incomplete chain
2. Fix: renew certificate, check SAN list, install complete certificate chain

How to use the Ping tool on sadiqbd.com

1. Enter hostname or IP — start with the domain, then the IP if DNS fails
2. Read the result — look for packet loss, latency, or resolution failure
3. Use as step 1 — confirms host reachability before moving to DNS and traceroute

Frequently Asked Questions

Why does ping succeed but the website still doesn't load? Ping tests ICMP reachability, not HTTP/HTTPS service availability. A server can respond to ping while the web server process is stopped, a firewall is blocking port 443, or an SSL certificate has expired. Use the port scanner to verify the specific port is accessible.

My traceroute shows high latency at one hop but the site loads fast. What's happening? The high-latency hop is deprioritising ICMP probes (a common practice). The actual data path may use different QoS treatment. If subsequent hops show normal latency and the site loads at normal speed, this is a false alarm.

Is the Ping tool free? Yes — completely free, no sign-up required.

Network troubleshooting becomes systematic once you understand which tool answers which question. Ping → DNS → traceroute → port scan covers 95% of connectivity problems in a predictable order.

Try the Ping tool free at sadiqbd.com — check host reachability and latency as the first step in any network diagnostic workflow.