Rocky 9: triage network problems by symptom

Test scope

Executed in a Rocky 9.8 environment (privileged container, host kernel 5.14.0-687.54.1.el9_8, --network host) on the same host: ip -br addr, ip route, ss -lntp, getent hosts example.com, curl https://example.com, curl http://127.0.0.1:9/, ping -c1 -W1 192.0.2.1. Log: plans/content-expansion/evidence/logs/rocky-network-troubleshoot.log.

This page is organised by symptom, not by OSI layer; one symptom can span several layers.

Symptom A: nothing gets out (check the default route first)

ip -br addr show
ip route show

lo      UNKNOWN  127.0.0.1/8 ::1/128
eth0    UP       80.66.196.187/32 ...
default via 172.31.1.1 dev eth0 proto static metric 100

Without the default via ... line there is no “slow internet” to discuss — packets have nowhere to go. Fix the route before blaming DNS or ports.

Symptom B: names do not resolve

getent hosts example.com
cat /etc/resolv.conf

2606:4700:10::6814:179a example.com
2606:4700:10::ac42:93f3 example.com

getent uses the system resolution chain, matching what applications experience. When it returns nothing, check the nameservers in /etc/resolv.conf, resolvectl status if systemd-resolved is in use, and whether port 53 is reachable at all.

Symptom C: connection refused

curl -sS --max-time 3 http://127.0.0.1:9/
ss -lntp | head -5

curl: (7) Failed to connect to 127.0.0.1 port 9: Connection refused
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=967,fd=7))

Refused means the network works and the peer actively rejected the connection: nothing running, wrong port, or bound to 127.0.0.1. Comparing with ss -lntp is the fastest next step.

Symptom D: silent timeout (100% packet loss)

ping -c 1 -W 1 192.0.2.1
ping -c 1 -W 2 1.1.1.1

1 packets transmitted, 0 received, 100% packet loss, time 0ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Read them separately: 192.0.2.1 is reserved, so its timeout is expected (a control case); 1.1.1.1 succeeding proves outbound connectivity. In a real incident, reaching the gateway but not the internet usually means policy or upstream loss.

Symptom E: intermittent failures

for i in 1 2 3; do curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" --max-time 5 https://example.com; done
getent hosts example.com | head -3

200 0.475
200 0.497
200 0.511

Three usual causes: DNS returning several addresses (one is broken), MTU/fragmentation (large packets fail, small ones pass), and multiple paths/gateways. Sampling three times with timings is far more informative than a single failure.

Common traps

• ping only: ICMP is often dropped while TCP works fine;
• Treating refused as a network fault: it is evidence the network works;
• Ignoring the bind address: 0.0.0.0 and 127.0.0.1 are different worlds externally.

Practice: from symptom to conclusion

ip route show | head -3
getent hosts <domain>
ss -lntp | grep <port>
curl -sS -v --max-time 5 http://<target>:<port>/ 2>&1 | tail -5

Checks:

1. You can say whether a default route exists
2. You can say whether resolution succeeded
3. You can distinguish refused from timeout
4. Your conclusion names one layer or one class of cause

FAQ

常见问题

What does a missing default route look like?

Same-subnet traffic may still work, but anything off-subnet fails (often Network is unreachable or plain timeout). No `default` line in ip route is the tell.

How do I quickly tell refused from timeout?

Refused returns immediately with connection refused; a timeout waits until your limit (curl --max-time). Check service and port for refused, routing and policy for timeout.

Where do I start with intermittent failures?

Sample several times (three curls with timings), then check whether DNS returns multiple addresses, whether MTU drops large packets, and whether there are multiple default gateways. One failure is not enough to diagnose.

Next steps

• Static IP and keyfiles: nmcli static IP
• Firewall rules: firewall-cmd rules
• Post-install checks: 7 checks after install