Skip to content
AlmaLinux Community Docs
AlmaLinux
Docs networkNetwork
Search AlmaLinux

    Browse this documentation

    AlmaLinux 9: five layers of network troubleshooting

    Test scope

    Section titled “Test scope”

    Executed on a real AlmaLinux 9.8 host (kernel 5.14.0-687.54.1.el9_8): ip -br addr, ip route, ss -lntp, getent hosts example.com, curl https://example.com, curl http://127.0.0.1:9/ (expected refused), ping 192.0.2.1 (expected timeout) and ping 1.1.1.1 (expected success). Log: plans/content-expansion/evidence/logs/alma-network-troubleshoot.log.

    This page is a general order of investigation; it does not cover firewall policy, proxies or cloud security groups in detail.

    Layer 1: interfaces and addresses

    Section titled “Layer 1: interfaces and addresses”
    Terminal window
    ip -br addr show
    ip route show
    lo      UNKNOWN  127.0.0.1/8 ::1/128
    eth0    UP       80.66.196.187/32 ...
    docker0 DOWN     172.17.0.1/16
    default via 172.31.1.1 dev eth0 proto static metric 100

    Check two things: is the interface UP, and does a default route exist. A DOWN docker0 does not affect outbound connectivity — do not let it mislead you.

    Layer 2: DNS

    Section titled “Layer 2: DNS”
    Terminal window
    getent hosts example.com
    2606:4700:10::6814:179a example.com
    2606:4700:10::ac42:93f3 example.com

    getent follows the system resolution chain (/etc/nsswitch.conf), which is closer to what applications do than dig. No result here means check /etc/resolv.conf and resolvectl, not routes.

    Layer 3: is anything listening?

    Section titled “Layer 3: is anything listening?”
    Terminal window
    ss -lntp | head -5
    LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=967,fd=7))
    LISTEN 0 4096 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",...))

    On the server the order is: is it listening → on which address → is the firewall allowing it. A service bound to 127.0.0.1 is unreachable from outside.

    Layer 4: connectivity — refused is not timeout

    Section titled “Layer 4: connectivity — refused is not timeout”
    Terminal window
    curl -sS --max-time 3 http://127.0.0.1:9/
    ping -c 1 -W 1 192.0.2.1
    curl: (7) Failed to connect to 127.0.0.1 port 9: Connection refused
    1 packets transmitted, 0 received, 100% packet loss, time 0ms
    • refused: the packet arrived and was actively rejected (nothing listening, or REJECT) — the problem is the port or service;
    • timeout / 100% loss: no reply (routing, security group dropping, or DROP on the peer) — the problem is the path or policy.

    192.0.2.1 is a reserved address used here to produce a guaranteed timeout; it is not a real fault location.

    Layer 5: the application itself

    Section titled “Layer 5: the application itself”
    Terminal window
    curl -sS -o /dev/null -w "https_code=%{http_code}\n" --max-time 8 https://example.com
    https_code=200

    When the first three layers are fine and the port is listening but requests still fail, the problem is at the application layer: certificates, Host headers, reverse proxy rules, application logs. Read the service log instead of pinging more.

    Common traps

    Section titled “Common traps”
    • Only using ping: ICMP is often blocked while TCP works; curl -v or nc -zv tells the truth;
    • Treating refused as a network problem: refused usually means the network is fine and the service is down;
    • Ignoring the bind address: 0.0.0.0:8080 and 127.0.0.1:8080 are completely different externally.

    Practice: walk the five layers once

    Section titled “Practice: walk the five layers once”
    Terminal window
    ip -br addr show && ip route show
    getent hosts <target-domain>
    ss -lntp | grep <port>
    curl -sS -v --max-time 5 http://<target>:<port>/ 2>&1 | tail -5

    Checks:

    1. Interface UP and a default route present
    2. The domain resolves
    3. The target port is listening (on the server)
    4. The curl error classifies as refused / timeout / certificate / HTTP status
    5. Your conclusion names a layer instead of “the network is broken”

    FAQ

    Section titled “FAQ”

    常见问题

    ping fails but the service works — is that normal?

    Yes, commonly. Many clouds and firewalls drop ICMP while allowing TCP. Test reachability with curl, nc or ss instead of ping alone.

    What does Connection refused mean?

    The path works and the peer is reachable, but nothing is listening on that port (or it is REJECTed). Check whether the service runs and whether it binds 0.0.0.0.

    How do I tell slow DNS from failed DNS?

    `getent hosts` returning nothing quickly is a failure; a visible pause before an answer suggests a DNS timeout. Time it with `time getent hosts <domain>` and then inspect resolv.conf and the upstream servers.

    Next steps

    Section titled “Next steps”