Linux Network Troubleshooting Commands: A Practical Guide

Network problems can look alike: a site may fail to load because DNS cannot find its address, a route is broken, a port is blocked, or the web server returns an error. Linux network troubleshooting commands help you test these layers separately instead of guessing. This guide shows how to use getent, dig, ss, traceroute or tracepath, and curl, what their output means, and where each tool's limits begin.

Key takeaways

• Diagnose in layers: name resolution, local sockets, network path, then application response.
• getent checks name resolution through the system's configured name-service sources; dig queries DNS directly.
• ss inspects sockets on your machine, while traceroute and tracepath help investigate the path to a destination.
• curl tests an HTTP(S) request, but a successful connection does not guarantee the application is healthy.
• Options, default protocols, and permissions can vary by distribution and implementation. Check the installed command's manual page with commands such as man curl or man tracepath.

Start with a layered troubleshooting plan

Before running commands, record the exact symptom, destination, time, and whether the issue affects one machine or several. Use a hostname and, when available, its IP address to distinguish name-resolution issues from connectivity issues.

A useful sequence is:

1. Check whether the system can resolve the hostname.
2. Inspect local listening or established sockets if a service is involved.
3. Check whether packets can make progress toward the destination.
4. Test the application protocol and inspect its response.

A failure at one layer does not automatically identify the cause. For example, a DNS lookup can succeed while a firewall blocks the web connection, and an HTTP server can be reachable while returning an error status.

Resolve names with getent and dig

Check the system's view with getent

Use getent to ask the system's configured name-service mechanism for an address:

getent ahosts example.com

The output may contain one or more IPv4 or IPv6 addresses. If it returns nothing, the system did not provide a matching result through the configured sources. That could involve DNS, local configuration such as /etc/hosts, or other name-service modules, depending on the system.

This is often the best first check because applications commonly use the system's resolver configuration. Results can differ from a direct DNS query if the system uses local files, a caching service, or other configured sources.

Query DNS with dig

If dig is installed, query DNS records directly:

dig example.com A
 dig example.com AAAA

The first command asks for IPv4 address records, and the second asks for IPv6 address records. In typical output, look for the ANSWER SECTION and the status in the header. NOERROR means the DNS query completed without a DNS error; it does not necessarily mean that the requested record exists. An empty answer can be valid for a record type that the name does not have.

To ask a particular DNS server, specify it with @:

dig @1.1.1.1 example.com A

Only query DNS servers you are authorized to use and whose policies allow your request. A direct query can help compare a resolver's answer with the system's normal result, but it does not reproduce every application's lookup behavior.

dig may not be installed by default. Package names and installation commands vary across distributions; consult your distribution's package documentation. Options and output details can also vary by implementation, so use man dig where available.

Inspect local connections and listeners with ss

ss displays socket information on the local machine. To list TCP sockets that are listening:

ss -ltn

Common options are:

• -l: show listening sockets.
• -t: show TCP sockets.
• -n: show numeric addresses and port numbers instead of resolving names.

To include UDP listeners, use:

ss -lun

To view TCP connections, including their states:

ss -tan

Look for the local address and port, then check whether the expected service is listening on the expected interface. A service bound to 127.0.0.1 is reachable only through the local loopback interface; a service bound to a particular address may not accept connections addressed to another interface. The exact meaning of wildcard addresses depends on the protocol and system configuration.

To show process information, try:

sudo ss -ltnp

Process details may require elevated privileges. Use sudo only when appropriate, and do not assume a missing process name means no listener exists; permissions can limit what is displayed. ss reports local socket state. It does not prove that a remote client can reach the service through routing rules, host firewalls, or network firewalls.

Trace the route with traceroute or tracepath

A route-tracing tool sends probes with increasing hop limits and reports routers that respond along the way. For example:

traceroute example.com

Implementations differ in their defaults and options. Some use UDP probes by default; others may offer ICMP or TCP modes. Intermediate routers may not respond to probes, and firewalls can filter or deprioritize them. A row of * characters therefore does not, by itself, prove that traffic is blocked or that the destination is down.

tracepath is available on some Linux systems and can be useful where you do not have permission to run a particular traceroute mode:

tracepath example.com

Availability, output, and capabilities depend on the installed implementation and system configuration. Neither tool is a definitive test of application availability: the probe traffic may be handled differently from the actual TCP or HTTP traffic you care about. Run these tests only against destinations you are authorized to diagnose.

Test an HTTP service with curl

Use curl to test an HTTP or HTTPS endpoint. A basic request displays the response body:

curl https://example.com/

For connection and protocol details, add verbose output:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

The connection timeout limits how long curl waits to establish a connection; the total timeout limits the overall operation. A timeout may indicate a network or service problem, but it can also result from a slow response or an unsuitable timeout for the task. Verbose output can reveal whether name resolution, connection setup, TLS negotiation, or the HTTP exchange failed.

To print the HTTP response status code without displaying the response body, use:

curl -sS -o /dev/null -w 'HTTP %{http_code}\n' https://example.com/

A status such as 200, 301, 404, or 503 is an HTTP response from a server or intermediary. It is different from a curl transport error, which may occur before an HTTP response is received. A redirect response is not necessarily a failure; inspect its Location header or use curl -L if you intentionally want to follow redirects. Be aware that following redirects makes additional requests to the redirect targets.

A HEAD request can show response headers without requesting the body:

curl -I https://example.com/

Some servers handle HEAD differently from GET or do not support it as expected. If the result is surprising, test a normal GET request and discard its body instead. For a quick status-code check, you can also check an HTTP status. The command-line workflow remains useful for examining details such as connection errors, headers, and timing.

A practical troubleshooting workflow

Suppose a service at https://app.example.com/health is reported as unavailable. Use a consistent sequence and note the output at each step:

1. Check system name resolution.

   getent ahosts app.example.com
   

   If this returns no result, investigate the system's resolver configuration and name-service sources. Compare with dig app.example.com A and dig app.example.com AAAA to see whether direct DNS answers are available.

2. Check the destination's route.

   traceroute app.example.com
   

   If traceroute is unavailable, try tracepath if installed. Treat missing hops as inconclusive, and compare from another authorized network or host if possible.

3. Test the HTTP request.

   curl -v --connect-timeout 5 --max-time 15 https://app.example.com/health
   

   Note whether resolution succeeded, a connection was established, TLS negotiation completed, and an HTTP status was returned. A TLS certificate error, connection refusal, timeout, and HTTP 503 point to different stages and should not be treated as the same failure.

4. If you administer the server, inspect its listener.

   sudo ss -ltnp
   

   Confirm that the intended service is listening on the expected port and address. Then check service logs, host firewall rules, and network policy using your platform's approved procedures.

This workflow narrows down the layer where evidence changes. It does not identify every root cause automatically; correlate command output with service logs, configuration, and tests from the client and server sides.

Common mistakes and limitations

• Treating dig and getent as interchangeable. dig queries DNS; getent follows the system's configured name-service path. Different results can be meaningful.
• Assuming a DNS answer proves the service is reachable. DNS only supplies name-resolution information. It does not test a TCP port or application response.
• Reading traceroute stars as proof of an outage. Routers may forward traffic while declining to answer traceroute probes.
• Treating an HTTP error as a network failure. A received 404 or 503 means an HTTP response was returned, though the application may still be unhealthy.
• Relying on only curl -I. Some services handle HEAD differently from GET. Test the relevant request method when behavior matters.
• Using numeric output without recording the hostname. DNS may return multiple addresses, and different clients can select different addresses or address families.
• Installing familiar tools without checking the distribution. dig, traceroute, and tracepath are not guaranteed to be present, and package names differ.

Safer, more effective troubleshooting habits

• Run tests from the machine and network where the problem occurs; a test from elsewhere may follow a different route or resolver.
• Change one variable at a time, such as hostname versus IP address, IPv4 versus IPv6, or client versus server vantage point.
• Use reasonable timeouts and avoid repeated high-volume probes. Troubleshooting commands should not become a source of unnecessary traffic.
• Redact tokens, cookies, private hostnames, and other sensitive data before sharing verbose command output.
• For services you operate, combine client-side checks with server logs, socket state, firewall configuration, and monitoring. A single command is rarely sufficient to establish a root cause.
• For commands that make network requests, verify the destination and authorization. Parsing a URL or observing a status code does not establish that a destination is safe or replace server-side security controls.

Conclusion

Linux network troubleshooting commands are most useful when each one answers a specific question. Use getent and dig to investigate name resolution, ss to inspect local sockets, traceroute or tracepath to gather route clues, and curl to test HTTP behavior. Interpret each result within its limits, compare observations across the relevant systems, and use logs and configuration to confirm the cause.