Ping and traceroute for network troubleshooting
A failed checkout, unreachable server, and stalled API request can look alike in a browser. Start by separating the local host, network path, name resolution, and application service instead of changing firewall rules at random.
ping tests whether a host answers ICMP and reports round-trip time, while traceroute exposes the route toward a destination and the latency at each hop. Neither proves an application is healthy, but together they narrow the fault quickly.
On RHEL, CentOS, Fedora, and similar systems, use short, repeatable commands and compare results across an IP address, a hostname, and the affected service.
Establish a baseline before changing anything
Begin on the affected machine with ip -br address, ip route, and ping -c 4 <gateway>. If the default gateway does not reply, inspect the interface, Ethernet or Wi-Fi link, DHCP lease, and NetworkManager state before testing anything beyond the local network.
Use the narrowest probe that answers the current question:
| Probe | Primary signal | Best for | Common blind spot |
|---|---|---|---|
ping |
ICMP replies and round-trip time | Gateway and broad reachability | Firewalls may drop ICMP |
traceroute |
Per-hop responses and latency | Locating path changes | Routers may ignore probes |
dig |
DNS answer and status | Name-resolution faults | Does not verify routing or HTTP |
curl |
HTTP status, TLS, and response time | Website and API failures | May hide an ICMP-specific problem |
Compare ping -c 4 1.1.1.1 with ping -c 4 example.com.au. Success for the first and failure for the second points toward DNS; failure for both suggests routing, upstream filtering, or a broken local configuration. Check for sustained packet loss, not just whether any reply arrives.
Separate name resolution from routing
Use dig when a hostname fails but its IP address works. Run dig example.com.au and dig @1.1.1.1 example.com.au, then compare the status and answer sections. A timeout at the local resolver followed by a successful public lookup can indicate faulty DNS configuration rather than a dead destination.
Australian businesses commonly publish .com.au and .au domains, although either name may resolve overseas. If a page links to an external service, such as a casino hold em guide, test the web server separately from that third-party host. The command curl -I --connect-timeout 10 https://example.com.au checks DNS, TCP, TLS, and the HTTP response together.
Read hop behaviour and latency
Use traceroute example.com.au to inspect each hop, remembering that an asterisk is not automatically a fault. Many routers deprioritise or suppress traceroute probes while forwarding normal traffic. If UDP probes are blocked, retry with traceroute -I example.com.au or a TCP probe such as traceroute -T -p 443 example.com.au.
Compare the first responsive hop, the final hop, and the jump in round-trip time. A traceroute from Brisbane toward a Sydney-hosted service may cross Melbourne or international transit, while a Melbourne path can use a different backbone entirely. When the destination also runs Apache, PHP, and MariaDB, the Fedora LAMP setup provides useful service context while checking the web stack.
Match failures to network layers
Match the symptom to the layer. No gateway reply points to the host or local segment; gateway success with public-IP failure points upstream; successful IP pings with hostname failure point to DNS; and successful HTTP with failed ping usually means ICMP is filtered. A connection refusal differs from a timeout because it normally means the host answered, but no service was listening on that port.
Packet capture can settle ambiguous cases. Run sudo tcpdump -ni any 'icmp or port 53 or port 443' while repeating the test. For suspected IPv4 path-MTU problems, try ping -M do -s 1472 1.1.1.1 and reduce the payload size until replies return.
Australian NBN connections add another layer: FTTP avoids the copper segment used by FTTN, while a marginal DSL signal can still affect an FTTN premises. In the Australian cloud market, a Sydney or Melbourne region may sit close to the virtual network, while traffic from regional offices continues across a wider path.
A repeatable diagnostic checklist
Keep each diagnostic pass short and record the command, time, source, destination, and exact output.
- Confirm the interface address, default route, and gateway reachability.
- Compare a destination IP with its hostname to isolate DNS.
- Use four probes and note both loss and latency variation.
- Retry traceroute using ICMP or TCP when UDP probes disappear.
- Check HTTP status and TLS with
curl, not only ICMP. - Capture relevant packets and consult the affected service logs.
Once the cause is identified, change one setting and repeat the same probes to confirm recovery. Keep the final route, DNS result, HTTP status, and any interface or firewall adjustment in the working record. Your next step is to run ping -c 4 1.1.1.1, ping -c 4 <affected hostname>, and traceroute <affected hostname> from the failing machine, then save those three outputs with the timestamp.