“Is the network up?” is one of the first questions asked whenever something isn’t working — and Linux provides a rich set of built-in tools to answer it precisely, at every layer of the network stack. This article explains, from first principles, how to check connectivity to a remote host and inspect overall network status using ping, traceroute, ss, curl, and related tools, along with how to interpret their output.
The Layered Approach to Connectivity Troubleshooting
flowchart TD
A[Layer 1-2: Physical/Link] --> B[Layer 3: IP/Routing - ping, traceroute]
B --> C[Layer 4: TCP/UDP Ports - ss, nc]
C --> D[Layer 7: Application - curl, dig]Effective troubleshooting typically works its way up this stack: first confirm basic IP reachability, then check whether the specific port is open, then verify the application-level response.
Step 1: Checking Basic Reachability With ping
ping sends ICMP Echo Request packets to a target and waits for Echo Reply packets, measuring round-trip time.
ping example.com
Example output:
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=14.2 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=13.8 ms
Limit the number of pings:
ping -c 4 example.com
Interpreting ping Output
| Observation | Likely Meaning |
|---|---|
| Replies with low, consistent time | Healthy connection |
| Replies with high or variable time | Latency/congestion issue |
Request timeout | Packet loss, or ICMP being blocked |
Destination Host Unreachable | No route to that host |
| No output at all, hangs | DNS resolution failure, or complete network outage |
Important caveat: many servers and firewalls intentionally block ICMP for security reasons. A failed ping does not always mean the host is down — the actual service (e.g., a web server) might be perfectly reachable via TCP even if ICMP is blocked.
Step 2: Tracing the Network Path With traceroute
traceroute reveals every router (hop) a packet passes through on its way to the destination, which is invaluable for pinpointing exactly where a connectivity problem occurs.
traceroute example.com
Install if missing:
sudo apt install traceroute
Example output:
1 192.168.1.1 (192.168.1.1) 1.123 ms
2 10.10.0.1 (10.10.0.1) 5.221 ms
3 * * *
4 93.184.216.34 (93.184.216.34) 14.532 ms
Asterisks (* * *) indicate a hop that didn’t respond — often because that particular router is configured to not respond to traceroute probes, which is common and not necessarily a problem, as long as later hops still respond.
mtr — A More Powerful Alternative
mtr (My TraceRoute) combines ping and traceroute into one continuously updating view:
sudo apt install mtr
mtr example.com
This is extremely useful for diagnosing intermittent packet loss, since it continuously re-probes every hop and shows loss percentages over time.
Step 3: Checking DNS Resolution
Before anything else works, the hostname must resolve to an IP address:
dig example.com
nslookup example.com
dig +short example.com
Step 4: Checking Whether a Specific Port Is Open
Using nc (netcat)
nc -zv example.com 443
Output:
Connection to example.com 443 port [tcp/https] succeeded!
Using curl for HTTP(S) Specifically
curl -I https://example.com
curl -v https://example.com
The -v (verbose) flag shows the entire TLS handshake and HTTP exchange, which is enormously useful for diagnosing certificate or protocol issues.
Step 5: Checking Local Network Status
Viewing Active Connections and Listening Ports
ss -tulnp
| Flag | Meaning |
|---|---|
-t | TCP |
-u | UDP |
-l | Listening sockets only |
-n | Numeric (skip DNS resolution) |
-p | Show the process using each socket |
Example output:
Netid State Local Address:Port Peer Address:Port Process
tcp LISTEN 0.0.0.0:22 0.0.0.0:* sshd
tcp LISTEN 0.0.0.0:443 0.0.0.0:* nginx
This tells you exactly which services are listening on which ports — essential for confirming a service is actually up and bound correctly.
Viewing Network Interface Status
ip addr show
ip link show
Checking Interface Statistics (Errors, Drops)
ip -s link show eth0
Example output showing packet counts, errors, and drops — useful for spotting a failing NIC or cable:
RX: bytes packets errors dropped
1234567 9876 0 0
TX: bytes packets errors dropped
7654321 6543 2 0
Non-zero error/drop counts, especially if increasing over time, point to a physical layer or driver issue.
A Complete Troubleshooting Walkthrough
Scenario: A user reports “the website is down.”
Step 1: Check DNS
dig +short website.com
Step 2: Check basic reachability
ping -c 4 website.com
Step 3: Check the specific port
nc -zv website.com 443
Step 4: Check the actual HTTP response
curl -I https://website.com
Step 5: If it’s your own server, check locally
ss -tulnp | grep 443
systemctl status nginx
Step 6: Trace the path if remote connectivity is the issue
mtr website.com
This layered process quickly isolates whether the problem is DNS, network path, firewall/port blocking, or the application itself.
Comparison Table: Connectivity Tools
| Tool | Layer | What It Tells You |
|---|---|---|
ping | Network (ICMP) | Basic host reachability, latency |
traceroute/mtr | Network | Path taken, where packet loss occurs |
dig/nslookup | DNS | Whether a hostname resolves correctly |
nc | Transport | Whether a specific TCP/UDP port is open |
ss | Transport (local) | What’s listening/connected on this machine |
curl | Application | Actual HTTP(S) response, headers, TLS details |
Real-World Example: Diagnosing a Firewall Block
ping -c 4 10.0.0.5 # succeeds — host is reachable
nc -zv 10.0.0.5 5432 # hangs, then times out — port likely blocked
This specific pattern (ICMP works, but a specific TCP port silently times out rather than being refused) is a classic sign of a firewall dropping traffic to that port, as opposed to the service simply not running (which would typically produce an immediate “connection refused”).
Best Practices
- Work through the layers systematically — DNS, then IP reachability, then port, then application — rather than guessing randomly.
- Don’t rely on
pingalone. ICMP is frequently blocked by design; a failed ping doesn’t prove a host or service is down. - Use
ssinstead of the oldernetstaton modern systems — it’s faster and provides more detailed socket information. - Use
mtrfor intermittent issues since it continuously re-samples, unlike a singletraceroutesnapshot. - Check both ends when possible. A connectivity issue might be local (firewall, DNS) or remote (server down, remote firewall) — checking from multiple vantage points speeds up diagnosis.
- Document baseline “healthy” output for critical systems, so anomalies are easier to spot later.
Troubleshooting
Problem: ping fails but the service works fine in a browser
ICMP is likely blocked by a firewall while the actual TCP service remains reachable. Verify with curl or nc directly.
Problem: traceroute shows all asterisks after a certain hop
That could mean a firewall blocking traceroute probes beyond that point, not necessarily a break in connectivity. Confirm end-to-end reachability separately with ping or nc to the final destination.
Problem: DNS resolves, but connection times out
Likely a routing or firewall issue between you and the destination. Use mtr to see where packets stop progressing.
Problem: ss shows the service listening, but remote connections still fail
Check whether the service is bound to 127.0.0.1 (localhost only) instead of 0.0.0.0 (all interfaces) — a very common misconfiguration:
ss -tulnp | grep myservice
Problem: Intermittent connectivity, hard to reproduce
Run a continuous monitoring tool over time rather than a single test:
mtr --report --report-cycles 100 example.com
Conclusion
Diagnosing connectivity issues in Linux is a systematic process of checking each layer of the network stack in turn: DNS resolution, basic IP reachability, path tracing, port-level connectivity, and finally the application response itself. With tools like ping, traceroute/mtr, dig, nc, ss, and curl in your toolkit — and an understanding of what each one actually tests — you can move from “the network seems broken” to a precise, evidence-based diagnosis in just a few commands.