Linux
Intermediate 14 min read Linux

Networking Essentials & Commands

Every outage conversation starts with 'is it the network?' Learn the TCP/IP model that underlies all Linux networking — addresses, ports, sockets and DNS — then master the exact commands (ping, ip, ss, curl, wget, traceroute, nslookup) to inspect interfaces, verify listeners and blame the right layer in under a minute.

networkingTCP/IPpingip addrifconfigssnetstatcurlwgettraceroutenslookupDNSportsinterfacestroubleshootinglinux
Prerequisites: Introduction to Linux
Introduction

What is this?

Linux networking is how every service talks to the rest of the world, and 'it's a network problem' is the most common excuse for an outage that isn't. This topic builds a working model of TCP/IP — addresses, ports, sockets and DNS — then teaches the exact commands DevOps engineers reach for (ping, ip, ss, curl, wget, traceroute, nslookup) to inspect interfaces, verify listeners and decide in under a minute whether a failure is yours, theirs or somewhere in between.

Motivation

Why do you need it?

  • Connection refused, timeouts and packet loss all present differently and need different tools; knowing the toolbox turns guesswork into diagnosis.
  • You cannot deploy, scale or debug microservices without knowing what listens on which address and port.
  • ip and ss are the modern replacements for ifconfig and netstat; being fluent in both reads like a native speaker on any server.
  • curl is the swiss-army knife for testing APIs, headers, timeouts and redirects without a browser.
  • Splitting a problem into layers — interface, route, DNS, socket — lets you blame the right component in a war room instead of the wrong one.
Think about it

Mental model

Imagine

A postal system with a phone book

Think of

TCP/IP networking

The IP address is a street address (172.17.0.2), the port is the office number inside the building (:80), and DNS is the phone book that turns 'example.com' into a street address. ping is ringing the doorbell to ask 'is anyone home?', and traceroute is watching which post offices the letter passes through.

Mechanics

How it works

  • Every machine gets at least one IP address per interface, and the loopback interface (127.0.0.1) always points at the machine itself.
  • A service listens on an IP:port pair — a socket — where 0.0.0.0 means 'all interfaces' and 127.0.0.1 means 'this machine only'.
  • TCP is connection-oriented: client and server complete a three-way handshake (SYN, SYN-ACK, ACK) before data flows, which is why HTTP and SSH run over TCP.
  • DNS maps human hostnames to IP addresses; name resolution is the first layer to suspect when a connection fails with a 'could not resolve host' error.
  • A connection is identified by four numbers — source IP, source port, destination IP, destination port — so thousands of clients can share a single server port like :443.

The path a request takes from your terminal to a web server, layer by layer.

Your terminal
DNS resolution
Kernel routing
TCP handshake
Server socket
Response bytes
Reference

Key commands

ping -c 4 8.8.8.8

Send 4 ICMP echo requests to test connectivity and measure round-trip time.

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=14.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=14.9 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 14.590/14.831/15.066/0.196 ms
ip a

Show every network interface with its MAC and IP addresses (the modern ifconfig).

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
ip r

Show the routing table — which gateway each destination is sent through.

default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
ss -tulnp

List TCP (-t) and UDP (-u) listeners (-l), with numeric ports (-n) and owning processes (-p).

Netid State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port  Process
tcp   LISTEN 0      4096    0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=214,fd=9))
tcp   LISTEN 0      4096    127.0.0.1:6379      0.0.0.0:*          users:(("redis-server",pid=128,fd=6))
netstat -tulnp

The older, slower sibling of ss — still asked about in interviews and found on legacy boxes.

Proto Recv-Q Send-Q Local Address   Foreign Address  State    PID/Program name
tcp        0      0  0.0.0.0:80       0.0.0.0:*        LISTEN   214/nginx
tcp        0      0  127.0.0.1:6379   0.0.0.0:*        LISTEN   128/redis-server
curl -I https://example.com

Fetch only the HTTP response headers — perfect for checking status codes without downloading the body.

HTTP/2 200
content-type: text/html; charset=UTF-8
content-length: 1256
server: ECS (dcb/7F83)
wget -q https://example.com/file.zip

Download a file from the internet to disk, with -q to suppress progress noise.

(no output) — then: ls -lh file.zip  →  -rw-r--r-- 1 root root 4.2M file.zip
traceroute -n 8.8.8.8

Show every router hop between you and the target; -n skips DNS lookups on each hop.

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1   1.204 ms   1.198 ms   1.190 ms
 2  10.0.0.1      5.511 ms   5.506 ms   5.499 ms
 3  8.8.8.8       14.233 ms  14.231 ms  14.228 ms
nslookup example.com

Query DNS and print the resolver and the resolved addresses.

Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34
Hands-on

Examples

Answer 'is it the network?' with a four-command health check

Answer 'is it the network?' with a four-command health check
# 1. Is my interface up, and do I have an address and a route?
ip a
ip r
 
# 2. Is my app actually listening, and on which address?
ss -tulnp | grep 8080
 
# 3. Can I reach the outside world, and does DNS work?
ping -c 3 1.1.1.1
nslookup example.com
 
# 4. What does the server reply on the wire?
curl -v --max-time 5 https://example.com

Each command isolates one layer: ip checks the local stack, ss checks the application, ping checks raw connectivity, nslookup checks name resolution and curl -v shows the full HTTP exchange. Running these in order tells you exactly which layer to blame before you page anyone.

Real world

In production

  • Readiness probes, health checks and service discovery all reduce to 'is something listening on this IP:port' — ss answers it.
  • Incident response starts by splitting the problem: local stack (ip), application (ss/curl), path (ping/traceroute), name resolution (nslookup).
  • curl scripts are the backbone of API smoke tests, deployment validation and cron-based health checks.
  • Troubleshooting 'why is it slow' usually ends with traceroute and curl timing flags, not hours of log diving.
Guidelines

Best practices

  • Always cap network tests: ping -c 4 and curl --max-time 5 — a stuck test hangs a script forever.
  • Prefer ss over netstat: faster, more complete and the default on modern distros.
  • Bind services to 0.0.0.0 only when needed; keep internal-only services on 127.0.0.1.
  • Use curl -o file or -O to save output instead of dumping HTML into the terminal.
  • Ping the IP before the hostname — it cleanly separates connectivity from DNS.
Watch out

Common mistakes

  • Declaring 'the server is down' after one ping fails because ICMP is filtered by a firewall.
  • Reaching for ifconfig on a system whose network is managed by iproute2 — the output will be misleading or missing.
  • Running ss -tulnp without sudo and missing the -p column, so you cannot see which process owns a port.
  • Forgetting that iptables/nftables can silently DROP packets that ping reports as 100% loss.
Root cause analysis

Common issues

Error
ping: google.com: Temporary failure in name resolution
Root cause

DNS resolvers are unreachable or /etc/resolv.conf is misconfigured.

Fix

Check cat /etc/resolv.conf, test nslookup 8.8.8.8, and restart systemd-resolved with systemctl restart systemd-resolved.

Error
curl: (7) Failed to connect to 192.168.1.50 port 8080: Connection refused
Root cause

Nothing is listening on that address/port, or a firewall is actively rejecting the connection.

Fix

On the target run ss -tulnp, verify the service started, and confirm it is bound to 0.0.0.0 or the reachable interface — not 127.0.0.1.

Error
curl: (28) Connection timed out after 5000 milliseconds
Root cause

Packets are being dropped between the hosts — a firewall DROP rule, wrong route, or packet loss.

Fix

Run ping and traceroute to the target, test another port, and review security groups and firewall rules end to end.

Error
curl: (6) Could not resolve host: example.com
Root cause

No DNS configuration, a typo in the hostname, or the resolver cannot reach upstream.

Fix

Test nslookup example.com, inspect /etc/resolv.conf, and confirm the resolver can reach an upstream like 1.1.1.1.

When things break

Debugging tips

  • echo $? plus verbose flags (-v, -d) tell you exactly where curl gave up.
  • ss -tunap shows established connections and the owning process — the fastest way to find who opened a socket.
  • When a domain will not resolve, compare nslookup against cat /etc/resolv.conf and query 1.1.1.1 directly.
  • curl --resolve example.com:443:127.0.0.1 tests a hostname against a specific IP without touching DNS.
Interviews

Interview checkpoint

Practice

Hands-on lab

Inspect interfaces, open listeners and test external connectivity
20 min · intermediate
In progress
Objectives
  • List network interfaces and addresses with ip a
  • Start a local listener and confirm it with ss -tulnp
  • Test DNS resolution and external connectivity with nslookup and curl
  • Observe the difference between an open port and a closed port

Inspect interfaces, open listeners and test external connectivity

20 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/6
1

Which command shows the IP address of every network interface?

2

What does ss -tulnp display?

3

A service is bound to 127.0.0.1:8080. Why can other machines not reach it?

4

A failing ping proves the remote server is down.

5

Which command shows only the HTTP response headers of a URL?

6

Your web app works on localhost but is unreachable from another server. What is the fastest way to see whether it is actually listening on the right address?

Quick reference

Cheat sheet

Interfaces & addresses
ip aAll interfaces, MAC and IP addresses
ifconfigDeprecated — use ip a
ip rRouting table and default gateway
hostname -IOnly the machine's IPs, no details
ip -br aCompact, one line per interface
Sockets & ports
ss -tulnpTCP/UDP listeners with process (needs sudo for -p)
ss -tunapAll connections (established too) with process
netstat -tulnpOlder alternative to ss
ss -lntp | grep :8080Is anything listening on 8080?
nc -zv host 443Test a TCP port from another host
Transfer & fetch
curl -I https://example.comFetch response headers only
curl -v https://example.comVerbose — show handshake and headers
curl --max-time 5 URLNever let curl hang forever
wget -O file.zip URLDownload to a specific filename
curl --resolve h:443:127.0.0.1 URLResolve a hostname to a test IP
Diagnostics
ping -c 4 8.8.8.8ICMP reachability + RTT, capped
traceroute -n 8.8.8.8Path hops, no DNS on each hop
nslookup example.comQuery DNS for addresses
dig example.com +shortClean DNS answer, one line
cat /etc/resolv.confWhich DNS resolvers are configured
Go deeper

Official documentation

ip(8) — iproute2 man page
docs
ss(8) — socket statistics
docs
curl manual
docs
traceroute(8) man page
docs
nslookup(1) man page
docs