Troubleshooting with ip, ss, dig, curl: Essential Network Tools Every Engineer Should Know

Picture this: Your application stops responding, users can’t connect to your service, or API calls are timing out. Before diving into application logs or restarting services, smart engineers reach for fundamental network troubleshooting tools that can quickly pinpoint the real issue.

Whether you’re a system administrator, developer, or DevOps engineer, network problems will find you. The difference between a quick resolution and hours of frustration often comes down to knowing the right diagnostic tools. Today, we’ll master four essential command-line utilities that belong in every engineer’s toolkit: ip, ss, dig, and curl.

These aren’t obscure system administration tools – they’re practical utilities that help you understand what’s actually happening with network connectivity, DNS resolution, and service communication.

The ip Command: Understanding Your Network Foundation

The ip command is your window into the Linux networking stack. It shows network interfaces, IP addresses, routing tables, and network namespaces. Think of it as your network configuration detective.

Examining Network Interfaces

When connectivity fails, start by checking whether your network interfaces are properly configured and active.

1
2
3
4
5
6
7
8

# Display all network interfaces and their status
ip addr show

# Show only interfaces that are currently up
ip link show up

# Get details about a specific interface
ip addr show eth0

The output tells you everything about your network setup:

1
2
3
4

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pq_fq_codel state UP
    link/ether 08:00:27:bb:cc:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic eth0
    inet6 fe80::a00:27ff:febb:ccdd/64 scope link

Look for key indicators: UP means the interface is active, the inet line shows your IPv4 address, and state UP confirms everything is working. If you see state DOWN or missing IP addresses, you’ve found your first clue.

Understanding Routing

Network routing determines how traffic flows between different networks. When you can reach local services but not external ones (or vice versa), routing is often the culprit.

1
2
3
4
5
6
7
8

# Show the complete routing table
ip route show

# See how traffic to a specific destination will be routed
ip route get 8.8.8.8

# Display routes for a particular interface
ip route show dev eth0

A typical routing table looks like this:

1
2

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

The default route handles traffic to external networks, while specific subnet routes handle local traffic. Missing or incorrect routes explain why certain destinations are unreachable.

In containerized environments, you might see additional routes for container networks, but the principles remain the same. Understanding these basics helps whether you’re troubleshooting a simple server or a complex Kubernetes cluster.

The ss Command: Socket and Connection Analysis

The ss (socket statistics) command reveals which services are listening on which ports and shows active network connections. It’s faster and more detailed than the older netstat command.

Discovering Listening Services

When services aren’t accessible, verify they’re actually listening on the expected ports and interfaces.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Show all listening TCP and UDP ports
ss -tuln

# Show only TCP listening ports
ss -tln

# Include process information for listening ports
ss -tlnp

# Show detailed socket information
ss -tlni

The output format is straightforward:

1
2
3

State    Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN   0      128    0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=1234,fd=3))
LISTEN   0      128    127.0.0.1:8080     0.0.0.0:*     users:(("myapp",pid=5678,fd=4))

Pay attention to the local address. 0.0.0.0:22 means SSH accepts connections from any interface, while 127.0.0.1:8080 means your application only accepts local connections. This distinction often explains why services work locally but not remotely.

Analyzing Connection States

Network connections go through various states. Understanding these states helps diagnose performance issues and connection problems.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Show all TCP connections with state information
ss -tan

# Filter connections by state
ss -tan state established
ss -tan state time-wait

# Show connections to specific ports
ss -tan '( dport = :443 or sport = :443 )'

# Count connections by state
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c

Common states include:

  • ESTABLISHED: Active connections
  • LISTEN: Services waiting for connections
  • TIME_WAIT: Recently closed connections
  • SYN_SENT: Connection attempts in progress

Too many connections in TIME_WAIT might indicate connection handling issues, while many SYN_SENT connections suggest network connectivity problems or unresponsive services.

Advanced Filtering

The ss command supports powerful filtering to focus on specific connection patterns:

1
2
3
4
5
6
7
8

# Show connections to a specific subnet
ss -tan '( dst 10.0.0.0/8 )'

# Show connections from a port range
ss -tan '( sport >= 8000 and sport <= 8999 )'

# Combine multiple conditions
ss -tan state established '( dst 192.168.1.0/24 and dport = :80 )'

The dig Command: DNS Resolution Mastery

DNS problems cause a surprising number of connectivity issues. The dig command is your primary tool for investigating DNS resolution, understanding different record types, and debugging name resolution failures.

Basic DNS Queries

Start with simple queries to verify that hostnames resolve correctly:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Basic DNS lookup
dig example.com

# Get just the IP address
dig +short example.com

# Query a specific DNS server
dig @8.8.8.8 example.com

# Query different record types
dig example.com MX
dig example.com AAAA
dig example.com TXT

The standard output provides comprehensive information:

1
2
3
4
5
6
7
8

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

Key details include the resolved IP address, TTL (time to live), and which DNS server provided the answer. Query time helps identify slow DNS resolution.

DNS Troubleshooting Methodology

When DNS resolution fails, use a systematic approach to identify where the problem occurs:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. Test with a reliable public DNS server
dig @8.8.8.8 example.com

# 2. Test your configured DNS servers
dig example.com

# 3. Check reverse DNS resolution
dig -x 93.184.216.34

# 4. Trace the complete resolution path
dig +trace example.com

# 5. Verify your DNS configuration
cat /etc/resolv.conf

If external DNS servers work but your local ones don’t, the problem is with your DNS configuration. If even public DNS servers fail, you might have network connectivity issues.

Service Discovery and Internal DNS

Modern applications often rely on internal DNS for service discovery. Understanding how to test these lookups is crucial:

1
2
3
4
5
6
7
8
9

# Test internal service names
dig internal-api.company.local

# Check split-horizon DNS
dig @internal-dns-server api.internal
dig @8.8.8.8 api.internal

# Verify search domains
dig short-name

In containerized environments, you might see special DNS zones for service discovery, but the debugging principles remain consistent across different platforms.

The curl Command: HTTP and API Testing

The curl command tests HTTP connectivity, debugs API issues, and validates service responses. It’s essential for troubleshooting web services and APIs.

Basic HTTP Testing

Start with simple connectivity tests to verify that HTTP services are reachable and responding correctly:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Basic HTTP request with verbose output
curl -v http://example.com

# Test with specific timeouts
curl --connect-timeout 5 --max-time 10 http://api.example.com

# Test HTTPS connectivity
curl -v https://secure.example.com

# Skip certificate verification (testing only)
curl -k https://self-signed.example.com

The verbose output (-v) shows the complete HTTP conversation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

* Trying 93.184.216.34:80...
* Connected to example.com (93.184.216.34) port 80 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.68.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 1256

This reveals connection establishment, HTTP headers sent and received, and response codes. Look for connection failures, SSL certificate issues, or unexpected HTTP status codes.

Advanced HTTP Operations

Real-world testing often requires sending specific headers, authentication, or request bodies:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# POST request with JSON data
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer token123" \
  -d '{"username": "test", "action": "login"}' \
  http://api.example.com/auth

# Upload a file
curl -X POST -F "[email protected]" http://upload.example.com

# Follow redirects automatically
curl -L http://redirect.example.com

# Save response headers to file
curl -D response-headers.txt http://example.com

Performance Analysis

Understanding request timing helps identify performance bottlenecks:

1
2
3
4
5
6
7
8
9

# Show detailed timing information
curl -w "@-" -o /dev/null -s http://api.example.com <<'EOF'
      DNS lookup: %{time_namelookup}s
     TCP connect: %{time_connect}s
    SSL handshake: %{time_appconnect}s
    Pretransfer: %{time_pretransfer}s
   Start transfer: %{time_starttransfer}s
    Total time: %{time_total}s
EOF

This breakdown shows where time is spent:

  • High DNS lookup time suggests DNS issues
  • Long connect time indicates network problems
  • Slow start transfer suggests server processing delays

Practical Troubleshooting Workflow

These tools work best when used systematically. Here’s a step-by-step approach for diagnosing connectivity issues:

Step 1: Verify Basic Network Configuration

1
2
3

# Check interface status and IP configuration
ip addr show
ip route show

Step 2: Confirm Service Availability

1
2

# Verify the service is listening
ss -tlnp | grep :8080

Step 3: Test Name Resolution

1
2

# Ensure hostnames resolve correctly
dig api.example.com

Step 4: Test Network Connectivity

1
2

# Test basic TCP connectivity
curl -v telnet://api.example.com:443

Step 5: Test Application Layer

1
2

# Test actual service functionality
curl -v http://api.example.com/health

This systematic approach helps isolate problems to specific network layers, making solutions more targeted and effective.

Let’s see this in action: Suppose you can’t reach a web API. Running through this checklist might reveal that your network interface is fine, the remote service is listening, DNS resolves correctly, but SSL certificate validation is failing. Now you know exactly what to fix.

Beyond the Basics: Advanced Techniques

As you become comfortable with these tools, you can combine them for more sophisticated troubleshooting:

Bash script to test all DNS-resolved IPs:

1
2
3
4
5

# Test connectivity to all IPs returned by DNS
for ip in $(dig +short api.example.com); do 
  echo "Testing $ip:"
  curl -H "Host: api.example.com" http://$ip/health
done

Real-time monitoring commands:

1
2
3
4
5
6
7
8

# Monitor connection establishment in real-time
watch -n 1 'ss -tan state syn-sent'

# Test DNS resolution speed
time dig example.com

# Trace HTTP redirects manually
curl -v -o /dev/null http://redirect.example.com 2>&1 | grep "Location:"

Best Practices for Network Troubleshooting

Start simple: Always begin with basic connectivity before investigating complex scenarios. A missing route or down interface explains many problems.

Use verbose output: The -v flag in curl and detailed options in other commands provide valuable diagnostic information.

Test incrementally: Verify each layer of network communication separately rather than testing everything at once.

Document your findings: Keep notes about what you discover. Network problems often have patterns that become clear over time.

Understand your environment: Different networking setups (cloud, containers, VPNs) have unique characteristics that affect troubleshooting approaches.

Conclusion: Building Network Debugging Skills

Mastering ip, ss, dig, and curl gives you a solid foundation for network troubleshooting in any environment. These tools help you understand how network traffic flows, identify configuration problems, and verify service connectivity.

The key to becoming effective with these tools is regular practice. Use them proactively to understand your systems when they’re working correctly, so you’ll know what normal looks like when problems arise.

Network troubleshooting is part science, part art. The science comes from systematic methodology and understanding how networks function. The art comes from experience, intuition, and knowing which tool to reach for when symptoms appear.

With these four essential commands in your toolkit, you’re equipped to diagnose and resolve the network issues that inevitably arise in modern computing environments. The investment in learning these tools pays dividends every time you quickly identify and fix a connectivity problem that might otherwise take hours to resolve.

Now go forth and may your connections be stable, your DNS queries swift, and your troubleshooting sessions short. Happy debugging! 🔧