Linux Network Troubleshooting with ip, ss, dig, and curl

When a Linux service is “unreachable,” the failure can be in several different layers: the local interface, routing, a listening socket, DNS, a firewall, TLS, or the application itself.

Randomly restarting services makes diagnosis harder. A better approach is to move from local state outward and identify the first layer that does not behave as expected.

1. Confirm the interface and address

Start with the addresses configured on the host:

ip addr

Look for the expected interface, whether it is UP, and whether it has the expected IPv4 or IPv6 address.

A shorter view is:

ip -brief addr

If an expected address is absent, HTTP debugging is premature. Investigate network configuration, DHCP, cloud interface attachment, or the relevant network manager first.

2. Inspect the route the kernel will use

Show the routing table:

ip route

For a specific destination, ask the kernel which route it would choose:

ip route get 203.0.113.10

Use documentation-only IP ranges such as 203.0.113.0/24 in examples and tests. Replace the address with the real destination when diagnosing your environment.

The output can reveal the selected interface, gateway, and source address. A missing default route or unexpected source interface explains many “connection timeout” reports.

3. Verify that the service is listening

If the problem is inbound connectivity, confirm that the process actually opened the expected socket:

ss -lnt

Useful flags are:

• -l: listening sockets;
• -n: numeric addresses and ports;
• -t: TCP sockets.

With sufficient permissions, -p can also show process information:

sudo ss -lntp

Pay attention to the bind address. A server listening on 127.0.0.1:8080 accepts only local IPv4 connections. A service intended to receive traffic from other hosts normally needs an appropriate non-loopback bind address, subject to the application’s security requirements.

Do not expose an administrative service publicly merely to make a connectivity test pass.

4. Test the local service before the network path

If a web service should listen on port 8080, test it from the same host:

curl -v http://127.0.0.1:8080/health

A successful local request tells you that the process and local application path are at least working. A local failure points back toward the service configuration, bind address, or process state.

If local access works but remote access fails, focus on routing, host firewall rules, cloud security controls, load balancers, and intermediate network policy.

5. Separate DNS from connectivity

Use dig to inspect DNS resolution:

dig example.com

To ask for a particular record type:

dig example.com A
dig example.com AAAA

Check whether the returned address is the one the application is supposed to use. If a hostname resolves incorrectly, repeatedly testing the wrong address will not reveal the real network problem.

To test an HTTP endpoint while bypassing normal DNS for one request, curl can map a host and port explicitly:

curl --resolve example.com:443:203.0.113.10 \
  https://example.com/

This preserves the hostname for HTTPS and HTTP while directing the connection to the supplied address. It is useful for testing a candidate server before DNS changes propagate.

6. Inspect connection establishment with curl

Verbose curl output shows DNS selection, connection attempts, TLS negotiation, request headers, and response status:

curl -v https://example.com/

For automated checks, prefer explicit limits so a broken endpoint does not hang indefinitely:

curl --connect-timeout 3 --max-time 10 \
  --fail-with-body https://example.com/health

--connect-timeout limits connection establishment. --max-time bounds the entire operation. --fail-with-body makes HTTP 4xx and 5xx responses produce a failure exit status while retaining the response body for diagnosis.

7. Compare IPv4 and IPv6 when needed

A hostname may resolve to both address families. If only one path is broken, client behavior can look intermittent.

Force each family for comparison:

curl -4 https://example.com/
curl -6 https://example.com/

If IPv4 succeeds and IPv6 fails, inspect IPv6 addressing, routes, firewall policy, and upstream support rather than disabling IPv6 reflexively.

Read failures by layer

Different symptoms suggest different investigation paths:

Connection refused

The destination host actively rejected the connection. Common causes include no process listening on that address and port, or a firewall configured to reject rather than drop traffic.

Connection timeout

Packets or responses may be getting dropped, the route may be wrong, or the destination may be unreachable. Inspect network and firewall paths.

DNS error

The client could not resolve the hostname. Check resolver configuration and DNS records before debugging the service port.

TLS or certificate error

TCP connectivity succeeded far enough to start TLS. Investigate hostname, certificate chain, trust store, protocol support, and time synchronization.

HTTP 4xx or 5xx

The request reached an HTTP server. Continue at the application, proxy, authentication, or upstream layer rather than treating it as a basic network failure.

Common pitfalls

Testing only with ping

ICMP may be blocked while TCP services work normally, or ping may work while the required application port is blocked. Test the protocol users actually depend on.

Using deprecated tools by habit

Commands such as ifconfig and netstat still exist on some systems, but ip and ss are the standard tools on modern Linux distributions and expose current kernel networking information directly.

Ignoring bind addresses

“Port 8080 is listening” is incomplete. 127.0.0.1:8080, 0.0.0.0:8080, and an individual interface address have different reachability.

Changing firewall rules before identifying the failure

Opening ports broadly can create security exposure without fixing the actual problem. Establish whether the service listens locally and which network path is failing first.

A repeatable troubleshooting order

Use the same sequence each time: interface, route, listener, local request, DNS, remote connection, TLS, then application response.

That order narrows the problem while preserving evidence. It also produces a useful incident note: instead of “the server was down,” you can report the first failing layer and the command output that demonstrated it.