Linux Networking Commands: ip, ss, curl, dig, and traceroute for Server Admins

Network Troubleshooting Is Half the Job

Ask any server administrator what eats most of their time, and the answer will not be deployments or configuration. It will be networking. A website that stopped responding. A service that is unreachable from specific locations. DNS that resolves on one server but not another. Email deliverability issues. Latency spikes at 2 AM that nobody can explain.

These tools will solve 90% of those problems. Not because they are magic, but because each one gives you a precise view into a specific layer of the network stack. Together, they form a diagnostic toolkit that turns "something is wrong with the network" into a root cause you can actually fix.

This guide covers the essential commands every Linux server admin should know — with real examples, practical filters, and the context to understand what the output means. Pair it with our broader 20 Linux commands every server admin must know for the non-networking half of the toolkit.

1. ip — The Modern Network Swiss Knife

ifconfig is gone. If you are still using it, you are using a tool from the net-tools package that has been deprecated for over a decade. The modern replacement is ip, part of the iproute2 suite. It is faster, more consistent, and supports IPv6 natively.

View Interfaces and IP Addresses

# All interfaces, all addresses
ip addr show
ip a        # Shorthand

# IPv4 only
ip -4 a

# IPv6 only
ip -6 a

# Specific interface
ip addr show eth0

Sample output for ip -4 a:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP
    inet 95.216.44.123/24 brd 95.216.44.255 scope global eth0
       valid_lft forever preferred_lft forever

What to look for: is the interface UP? Does it have the IP address you expect? Is the subnet mask correct?

Interface Management

# Check link status
ip link show

# Bring interface up or down
ip link set eth0 up
ip link set eth0 down

# Set MTU (useful for VPN troubleshooting)
ip link set eth0 mtu 1400

Routing Table

# View routing table
ip route
ip r     # Shorthand

# Add a static route
ip route add 10.0.0.0/24 via 192.168.1.1

# Delete a route
ip route del 10.0.0.0/24

# Which route will a packet use?
ip route get 8.8.8.8

The ip route get command is underrated. Type any destination IP and it tells you exactly which interface and gateway will be used — no guesswork.

ARP Table (Neighbors)

# View ARP cache
ip neigh

# Flush stale entries
ip neigh flush all

ifconfig vs ip — Why the Change Matters

The net-tools package is absent from most minimal server images. Learn iproute2 and you will never be stuck.

2. ss — Socket Statistics

netstat is another deprecated tool from net-tools. ss (socket statistics) is faster, available everywhere, and shows more detail. The command you will run constantly:

ss -tulnp

Break down what each flag does:

Sample output:

Netid  State   Recv-Q Send-Q  Local Address:Port  Peer Address:Port  Process
tcp    LISTEN  0      128     0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=1234))
tcp    LISTEN  0      511     0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=5678))
tcp    LISTEN  0      511     0.0.0.0:443          0.0.0.0:*          users:(("nginx",pid=5678))

More Useful Filters

# Summary statistics
ss -s

# All established TCP connections
ss -t state established

# Connections to a specific IP
ss -t dst 203.0.113.50

# Connections on a specific port
ss -t sport = :443

# TIME_WAIT connections (high count = potential problem)
ss -o state time-wait | wc -l

# CLOSE_WAIT connections (high count = app not closing sockets)
ss -t state close-wait

Connection States Explained

When you see thousands of TIME_WAIT connections: check net.ipv4.tcp_tw_reuse and your keep-alive settings. When you see growing CLOSE_WAIT: the application is not closing socket handles properly — restart it and look at the code.

3. ping — The First Test You Always Run

Simple but essential. Before you open tcpdump or mtr, you ping. If ping fails, you know the problem is at layer 3 or below (routing, firewall, interface). If ping works but the service does not, the problem is at the application layer.

# Basic connectivity test (5 packets)
ping -c 5 google.com

# Fast ping (200ms interval instead of 1 second)
ping -c 100 -i 0.2 192.168.1.1

# MTU path discovery (find the maximum packet size)
ping -s 1472 -M do 203.0.113.1

# IPv6
ping6 -c 5 ipv6.google.com

Understanding the output:

PING google.com (142.250.74.206): 56 data bytes
64 bytes from 142.250.74.206: icmp_seq=0 ttl=117 time=8.204 ms
64 bytes from 142.250.74.206: icmp_seq=1 ttl=117 time=7.891 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss
round-trip min/avg/max/stddev = 7.891/8.100/8.204/0.121 ms

• TTL (Time to Live) — Decremented at each hop. If TTL drops from 64 to 52, you are 12 hops away. Asymmetric TTL across pings suggests routing changes.
• Packet loss — Even 1% loss is significant for production services. 100% loss means firewall or routing issue.
• stddev (standard deviation) — High stddev means inconsistent latency. Good latency average with high stddev often indicates bufferbloat.

When ping fails: It does not always mean the host is down. Many servers block ICMP. Use curl or nmap to check TCP connectivity before concluding the host is unreachable.

4. curl — HTTP Testing and API Calls

curl is the most versatile tool on this list. It handles HTTP, HTTPS, FTP, SMTP, and dozens of other protocols. For web server admins, it is indispensable.

Basic Usage

# Headers only (check HTTP status, redirects, cache headers)
curl -I https://example.com

# Verbose output (full TLS handshake, request/response headers)
curl -v https://example.com

# Follow redirects
curl -L https://example.com

# Save to file
curl -o output.tar.gz https://releases.example.com/latest.tar.gz

# Skip TLS verification (TESTING ONLY — never in production scripts)
curl -k https://self-signed.example.com

Testing APIs

# POST with JSON body
curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "action": "status"}' \
  https://api.example.com/v1/check

# With authentication header
curl -H "Authorization: Bearer eyJhbGci..." https://api.example.com/v1/me

# PUT request
curl -X PUT \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}' \
  https://api.example.com/v1/settings/firewall

Timing Breakdown

This is one of the most powerful curl features for performance troubleshooting. Create a format file:

cat > /tmp/curl-format.txt << 'EOF'
    time_namelookup:  %{time_namelookup}s
       time_connect:  %{time_connect}s
    time_appconnect:  %{time_appconnect}s
   time_pretransfer:  %{time_pretransfer}s
      time_redirect:  %{time_redirect}s
 time_starttransfer:  %{time_starttransfer}s
                    ----------
         time_total:  %{time_total}s
EOF

curl -w "@/tmp/curl-format.txt" -o /dev/null -s https://example.com

Sample output:

    time_namelookup:  0.003421s
       time_connect:  0.023156s
    time_appconnect:  0.089234s
   time_pretransfer:  0.089301s
      time_redirect:  0.000000s
 time_starttransfer:  0.156432s
                    ----------
         time_total:  0.157891s

How to read this:

• time_namelookup — DNS resolution time. Over 100ms = DNS problem.
• time_connect - time_namelookup — TCP connect time. Over 100ms = routing/firewall.
• time_appconnect - time_connect — TLS handshake. Over 200ms = certificate or cipher issues.
• time_starttransfer - time_appconnect — Time to first byte (TTFB). This is your application response time.

Testing Before DNS Cutover

# Test your new server before switching DNS
curl --resolve example.com:443:NEW_SERVER_IP https://example.com

# Test HTTP on a different IP
curl --resolve example.com:80:NEW_SERVER_IP http://example.com/health

curl vs wget

Rule of thumb: use curl for API calls and HTTP testing, and wget for downloading files and mirroring sites.

5. dig — DNS Lookup

DNS is the source of more production incidents than most admins want to admit. dig (domain information groper) gives you precise control over what you query and shows the full answer including TTL, authoritative servers, and the complete resolution path.

Basic Queries

# A record (IPv4) — default
dig example.com

# Just the answer, no headers
dig +short example.com

# MX records (mail servers)
dig example.com MX

# TXT records (SPF, DKIM, DMARC)
dig example.com TXT

# AAAA records (IPv6)
dig example.com AAAA

# All records
dig example.com ANY

# Clean output — answer section only
dig example.com +noall +answer

TXT records are also where SPF, DKIM, and DMARC live — see our complete guide to DNS record types for what each one does.

Query Specific DNS Servers

# Query Google's resolver (test if your DNS propagated publicly)
dig @8.8.8.8 example.com

# Query Cloudflare
dig @1.1.1.1 example.com

# Query your authoritative nameserver directly
dig @ns1.example.com example.com

# Compare results — if different, you have propagation lag
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
dig @your-server-ip example.com +short

Trace the Full Resolution Path

dig +trace example.com

This is the most useful flag when DNS is not resolving correctly. It shows the complete chain from root servers down to the authoritative server. Sample output (truncated):

.                   518400  IN  NS  a.root-servers.net.
.                   518400  IN  NS  b.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53

com.                172800  IN  NS  a.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net)

example.com.        172800  IN  NS  ns1.examplehost.com.
;; Received 644 bytes from 192.5.6.30#53(a.gtld-servers.net)

example.com.        3600    IN  A   93.184.216.34
;; Received 56 bytes from 205.251.196.1#53(ns1.examplehost.com)

Reverse DNS Lookup

# PTR record — who owns this IP?
dig -x 8.8.8.8

# Short form
dig -x 8.8.8.8 +short
# Returns: dns.google.

PTR records matter for mail servers. Gmail and other providers reject mail from IPs with no PTR record or PTR that does not match the EHLO hostname.

Understanding dig Output

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

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

;; AUTHORITY SECTION:
example.com.         900     IN  NS  a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.  3600    IN  A   199.43.135.53

• QUESTION — What you asked
• ANSWER — The actual records. TTL (3600 seconds) tells you how long this is cached.
• AUTHORITY — Which nameservers are authoritative for this domain
• ADDITIONAL — Extra records (often IP addresses for the nameservers)

Simpler Alternatives

# nslookup — interactive mode, less detail than dig
nslookup example.com

# host — single-line output, easiest syntax
host example.com
host -t MX example.com

6. traceroute and mtr — Follow the Network Path

When ping works but latency is high, or when specific routes are failing, you need to see the path packets take between your server and the destination. traceroute shows it once; mtr shows it continuously with statistics.

traceroute

# Basic traceroute
traceroute example.com

# No DNS resolution (much faster)
traceroute -n example.com

# TCP traceroute on port 443 (bypasses ICMP blocks)
traceroute -T -p 443 example.com

# UDP traceroute (default on Linux)
traceroute -U example.com

# Increase timeout (useful for slow hops)
traceroute -w 5 example.com

Sample output:

traceroute to example.com (93.184.216.34), 30 hops max
 1  _gateway (192.168.1.1)  0.458 ms  0.401 ms  0.389 ms
 2  10.0.0.1 (10.0.0.1)  1.234 ms  1.198 ms  1.201 ms
 3  * * *
 4  ae0-u1.fra1.de.example-isp.net  8.234 ms  8.102 ms  8.319 ms
 5  93.184.216.34  15.891 ms  15.734 ms  15.812 ms

* * * means the router at that hop dropped the probe packets (ICMP TTL exceeded). This is extremely common and does not mean the path is broken — use -T for TCP traceroute to get past firewalls that block ICMP.

mtr — Real-Time Combined Tool

mtr (Matt's Traceroute) combines ping and traceroute into a live, updating view. It is the preferred tool for diagnosing intermittent latency and packet loss.

# Interactive live view
mtr example.com

# No DNS resolution
mtr -n example.com

# Report mode (send 100 packets, print summary)
mtr --report -c 100 example.com

# TCP mode on port 443
mtr -T -P 443 example.com

Sample report output:

HOST: server1.example.com          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. _gateway                        0.0%   100   0.4   0.4   0.3   0.7  0.1
  2. 10.0.0.1                        0.0%   100   1.2   1.3   1.1   2.1  0.2
  3. ???                            100.0%   100   0.0   0.0   0.0   0.0  0.0
  4. ae0-u1.fra1.de.isp.net          0.0%   100   8.3   8.4   8.1   9.2  0.3
  5. 93.184.216.34                   0.0%   100  15.8  15.9  15.7  16.4  0.2

Hop 3 shows 100% loss — but hop 4 and 5 are fine. This means hop 3 is a router that drops probe packets but still forwards real traffic normally. Not a problem. If hop 4 also showed packet loss, that would be a real issue.

7. wget — File Downloads and Site Mirroring

# Download a file
wget https://releases.example.com/package.tar.gz

# Resume an interrupted download
wget -c https://releases.example.com/large-file.tar.gz

# Download to a specific filename
wget -O backup.tar.gz https://releases.example.com/latest

# Output to stdout (pipe to other commands)
wget -q -O - https://scripts.example.com/install.sh | bash

# Check if a URL is accessible (no download)
wget --spider https://example.com/health

# Mirror entire website
wget --mirror --convert-links --page-requisites \
     --no-parent https://docs.example.com/

# Recursive download (2 levels deep)
wget -r -l 2 https://example.com/

The --spider flag is useful in health check scripts — it returns exit code 0 if the URL is accessible, non-zero otherwise, without downloading the content.

8. tcpdump — Packet Capture

tcpdump operates at a lower level than everything else on this list. It captures actual packets on the wire. When you need to see exactly what is being sent and received — not what your application thinks is being sent — this is the tool.

# Capture on interface (Ctrl+C to stop)
tcpdump -i eth0

# Specific port
tcpdump -i eth0 port 80

# Specific host
tcpdump -i eth0 host 203.0.113.1

# Both port and host
tcpdump -i eth0 'port 443 and host 203.0.113.1'

# Save capture to file for analysis in Wireshark
tcpdump -i eth0 -w /tmp/capture.pcap

# Read capture file
tcpdump -r /tmp/capture.pcap

# Show packet contents as ASCII
tcpdump -i eth0 -A port 8080

# No DNS/port name resolution (faster, cleaner)
tcpdump -i eth0 -nn

Useful Filters

# TCP traffic only
tcpdump -i eth0 tcp

# UDP traffic only
tcpdump -i eth0 udp

# Incoming traffic only
tcpdump -i eth0 dst 95.216.44.123

# Outgoing traffic only
tcpdump -i eth0 src 95.216.44.123

# SYN packets (new connections)
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# RST packets (connection resets — find dropped connections)
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

# HTTP requests
tcpdump -i eth0 -A 'port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

For anything beyond quick inspection, save to a .pcap file and open in Wireshark on your workstation. Wireshark's GUI makes it much easier to follow TCP streams, filter conversations, and analyze TLS handshakes.

9. nmap — Network Scanner

nmap maps what is open on a host or network. It goes well beyond what ss shows locally — it scans from the outside, showing what the rest of the internet actually sees.

Legal warning: Only scan hosts you own or have explicit written permission to scan. Unauthorized port scanning is illegal in many jurisdictions and violates the terms of service of virtually all hosting providers.

# TCP connect scan (no root required)
nmap -sT 203.0.113.1

# SYN scan — stealth, faster (requires root)
nmap -sS 203.0.113.1

# Specific ports
nmap -p 22,80,443,3306,5432 203.0.113.1

# All 65535 ports (slow)
nmap -p- 203.0.113.1

# Service version detection
nmap -sV 203.0.113.1

# OS detection
nmap -O 203.0.113.1

# Scan entire subnet
nmap 192.168.1.0/24

# Comprehensive scan (OS + version + scripts + traceroute)
nmap -A 203.0.113.1

# Fast scan (common ports only)
nmap -F 203.0.113.1

# Save results to file
nmap -oN scan-results.txt 203.0.113.1

Practical use case: after setting up a new server, run nmap -sT YOUR_SERVER_IP from an external machine to verify that only the ports you intended to expose are actually open. Surprises happen — management ports left open, services that auto-start, forgotten firewall rules. For the attack side of open ports, see our guide on how DDoS attacks work and how to defend against them.

10. Firewall Management — iptables, nftables, ufw

Linux offers three layers here: raw netfilter (via iptables or nftables), and a simplified frontend (ufw). Knowing all three is important because you will encounter all three in production.

iptables (Legacy but Widely Deployed)

# List all rules with counters
iptables -L -n -v

# List a specific chain
iptables -L INPUT -n -v --line-numbers

# Allow SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP and HTTPS
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# Allow established connections (important — do this before DROP)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Drop everything else (do this LAST)
iptables -A INPUT -j DROP

# Save rules (survives reboot)
iptables-save > /etc/iptables/rules.v4

nftables (Modern, Ubuntu 22.04+)

nftables replaced iptables as the default in modern kernels. Better performance, cleaner syntax, atomic rule updates.

# Show all rules
nft list ruleset

# Show a specific table
nft list table inet filter

# Add a rule to allow port 443
nft add rule inet filter input tcp dport 443 accept

# Basic table structure
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport 22 accept

ufw — The Human-Friendly Layer

# Enable/disable
ufw enable
ufw disable

# Allow a port
ufw allow 22/tcp
ufw allow 443/tcp

# Allow from specific IP only
ufw allow from 203.0.113.5 to any port 22

# Deny a port
ufw deny 3306/tcp

# Delete a rule
ufw delete allow 80/tcp

# Show all rules with status
ufw status verbose

# Check without enabling
ufw --dry-run enable

When to Use Which

11. Network Configuration Files

Knowing the commands is half the battle. Knowing where configuration lives is the other half.

Key Files

# Local DNS override — hostname to IP without DNS
/etc/hosts

# DNS resolvers (Ubuntu 18.04 and earlier, or non-systemd-resolved systems)
/etc/resolv.conf

# Server hostname
/etc/hostname
hostnamectl set-hostname server1.example.com

# Legacy network interfaces (Debian)
/etc/network/interfaces

# Modern network configuration (Ubuntu 22.04+)
/etc/netplan/*.yaml

Netplan Example — Static IP on Ubuntu 22.04+

cat /etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 95.216.44.123/24
      routes:
        - to: default
          via: 95.216.44.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      dhcp4: false

# Apply without reboot (revert in 120s if you don't confirm)
netplan try

# Apply permanently
netplan apply

The netplan try flag is your safety net when reconfiguring network on a remote server. If you accidentally break connectivity, it automatically reverts after 120 seconds.

12. Practical Troubleshooting Scenarios

Commands in isolation are useful. A systematic diagnostic approach is more useful. When these tools point at the application layer rather than the network, the next stop is usually the logs — see Linux Log Files: Where to Find Them and How to Read Them.

Scenario 1: "The Website Is Unreachable"

# Step 1: Is DNS resolving?
dig example.com +short

# Step 2: Can we reach the server at all?
ping -c 5 SERVER_IP

# Step 3: Is the service listening?
# (From the server itself)
ss -tulnp | grep ':80\|:443'

# Step 4: Is the firewall blocking it?
nmap -p 80,443 SERVER_IP   # from external machine

# Step 5: What does the HTTP response look like?
curl -v https://example.com

# Step 6: Any routing issues?
mtr --report -c 20 SERVER_IP

Scenario 2: "Connection Refused"

# Check if the service is actually running
systemctl status nginx

# Check what is actually listening
ss -tulnp | grep nginx

# Check firewall rules
ufw status verbose
nft list ruleset

# Check if the port is accessible from outside
nmap -p 80 SERVER_IP

Scenario 3: "The Website Is Slow"

# Break down where time is spent
curl -w "@/tmp/curl-format.txt" -o /dev/null -s https://example.com

# Is it network or server?
mtr --report -c 100 SERVER_IP

# Is it the application?
time curl -o /dev/null -s https://example.com

# Capture what is actually happening on the wire
tcpdump -i eth0 -w /tmp/slow.pcap host CLIENT_IP &
# reproduce the slow request
# kill tcpdump
# analyze in Wireshark

Scenario 4: "DNS Is Not Resolving"

# Test with external resolver first — is it a local DNS problem?
dig @8.8.8.8 example.com

# Check your server's configured resolvers
cat /etc/resolv.conf

# Is local resolver working?
dig @127.0.0.1 example.com

# Full trace to find where resolution breaks
dig +trace example.com

# Is the authoritative server responding?
dig @ns1.example.com example.com

Scenario 5: "Port Is Open but Connections Drop"

# Look for RST packets (connection resets)
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'

# Check for conntrack table exhaustion
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

# Check socket buffers
sysctl net.core.rmem_max net.core.wmem_max

# Fail2ban blocking?
fail2ban-client status sshd

Quick Reference Cheat Sheet

Interface & Routing

Connections & Ports

DNS

Connectivity Testing

Frequently Asked Questions

What replaced ifconfig and netstat on modern Linux?

ip (from the iproute2 suite) replaced ifconfig for interfaces and routing, and ss replaced netstat for socket statistics. Both are faster and available by default on modern minimal server images, while net-tools is often absent entirely.

Why does ping sometimes fail even though the server is online?

Many servers and firewalls block ICMP traffic (the protocol ping uses) while still accepting normal TCP connections. Use curl or nmap to test actual TCP connectivity on the relevant port before concluding a host is unreachable.

What is the difference between traceroute and mtr?

traceroute shows the network path once, as a single snapshot. mtr combines ping and traceroute into a continuously updating view, which makes it far better for diagnosing intermittent latency or packet loss that a single traceroute snapshot would miss.

Is it legal to run nmap against any server?

No. Only scan hosts you own or have explicit written permission to scan. Unauthorized port scanning violates the terms of service of virtually all hosting providers and is illegal in many jurisdictions.

Network Mastery Is Server Mastery

Every tool in this guide solves a specific problem at a specific layer. ip and ss tell you what is configured locally. ping and mtr tell you whether packets reach their destination. curl and dig test application-layer and DNS behavior. tcpdump shows you what is actually on the wire when everything else disagrees with what should be happening.

The pattern is always the same: start at the lowest layer (is the interface up?), move up through routing, then firewall, then the service, then DNS, then the application. Each tool eliminates a layer from suspicion. By the time you have worked through all of them, you will have your answer.

If you are running Panelica, you already have built-in firewall management (nftables under the hood), real-time network monitoring via Prometheus and Grafana, and per-user bandwidth tracking — so many of these diagnostics happen through the dashboard rather than the command line. But the command line never breaks, never requires a UI to load, and works even when your panel is the thing you are troubleshooting. These tools belong in your muscle memory.