Basic Networking on Linux

A server exists to serve over the network, so when something goes wrong ("can't connect", "the service won't come up") you need to diagnose the network. This article teaches the core networking commands on Linux — enough to answer: what IP does the machine have, which ports are open, can it reach the outside, does DNS work.

Install the tools (a minimal Ubuntu ships without them):

apt update && apt install -y iproute2 iputils-ping curl dnsutils

Note: the old commands ifconfig, netstat, route are deprecated, replaced by the more modern ip and ss set (the iproute2 package). Old tutorials online tend to use the old commands; this article uses the new ones.

IP address: ip addr

View the IP addresses of the network interfaces:

ip addr            # full
ip -br addr        # brief (-br = brief)

lo     UNKNOWN  127.0.0.1/8 ::1/128
eth0   UP       172.17.0.5/16

• lo is the loopback (127.0.0.1) — this machine itself, used by processes on the same host to talk to each other.
• eth0 is a real network card, here with IP 172.17.0.5. The /16 part is the subnet mask (the network range).

Routing: ip route

Where do packets headed out go? Look at the routing table:

ip route

default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 ...

The line default via ... is the default gateway — all traffic not belonging to the local network goes through here to reach the Internet. If a machine "can't reach the network", one of the things to check is whether there's a default route.

Listening ports: ss

A service (web server, database) "listens" on a port. View which ports are open:

ss -tlnp

• -t TCP, -l only listening sockets, -n show port numbers (no name resolution), -p show which process (requires root).

State   Local Address:Port   Process
LISTEN  0.0.0.0:80           users:(("nginx",pid=...))
LISTEN  127.0.0.1:5432       users:(("postgres",pid=...))

This is an extremely useful command when debugging "the service is unreachable": check whether it's actually listening, and where. Notice the difference:

• 0.0.0.0:80 — listening on all interfaces, reachable from outside.
• 127.0.0.1:5432 — only listening on loopback, reachable only from the machine itself.

The classic bug: a service binds only to 127.0.0.1, so outside connections can't get in, even though the service is still "running".

Testing connectivity: ping, curl

ping checks whether you can reach a host (at the network level):

ping -c 2 8.8.8.8

64 bytes from 8.8.8.8: icmp_seq=1 ttl=63 time=43.2 ms

-c 2 sends 2 packets then stops (without -c it pings forever, Ctrl+C to stop). A successful ping means the network layer reaches the destination.

curl checks at the application level (HTTP) — usually more useful than ping for web services:

curl -sI https://example.com    # -s silent, -I headers only

HTTP/2 200

HTTP/2 200 means the connection to the web server succeeded. curl (or wget) also downloads files and calls APIs — the all-purpose tool for HTTP on the command line.

DNS: resolving names to IPs

When you type example.com, the machine has to look up its IP — that's DNS. Check name resolution:

getent hosts example.com     # portable, uses the system's resolution mechanism
dig example.com +short       # more detail (dnsutils package)
nslookup example.com

104.20.23.154   example.com

Two related config files:

• /etc/resolv.conf — the list of DNS servers the system uses (nameserver ...).
• /etc/hosts — local name→IP mappings, looked up before DNS. Add a line like 1.2.3.4 myhost here to force a name to point at a fixed IP (handy for testing, or pointing to internal names).

A workflow for "can't connect"

Put it together into a sequence when a service is unreachable:

1. Does DNS resolve the name to an IP?    → getent hosts <name> / dig
2. Can you reach the host (network)?       → ping <ip>
3. Is the service listening on the right port/interface?  → ss -tlnp (on the target server)
4. Can you reach that port?                → curl <url>  /  nc -zv <host> <port>
5. Is something blocking in between (firewall)?  → check firewall / security group

Working top to bottom usually narrows down the problem: wrong name (DNS), broken network (ping), service down or bound wrong (ss), or blocked (firewall).

🧹 Cleanup

This article is mostly read-only commands, nothing created that needs cleaning up.

Wrap-up

The core (modern) networking command set: ip addr to view IPs, ip route for routing/gateway, ss -tlnp for listening ports (and whether bound to 0.0.0.0 or 127.0.0.1), ping/curl to test connectivity at the network/application layer, and DNS via getent/dig with config in /etc/resolv.conf and /etc/hosts. The DNS → ping → ss → curl workflow narrows down most connectivity issues.

Now that you can check the network, Article 14 covers how to get into a server over it: SSH — remote connection, key authentication, and transferring files with scp/rsync.