Linux Networking Basics
Learn how Linux programs talk to the network: ports, sockets, DNS, routing, and quick debugging with ss, curl, dig, and traceroute.
Linux networking is the base layer for everything you operate:
- web services (TCP/HTTP)
- databases (TCP)
- internal APIs and health checks
- Kubernetes ingress/service routing
This tutorial gives you a debugging toolbox and mental model.
Learning outcomes
By the end, you’ll be able to:
- inspect listening ports and active connections
- debug connectivity using DNS + TCP checks
- understand basic routing concepts (gateway/route)
1) Ports and sockets: what to check first
Listeners (server side)
# show listening sockets
sudo ss -lntp
# examples:
# -l : listening
# -n : numeric (no DNS lookup)
# -t : TCP
# -u : UDP
Connections (client side)
# show established connections
sudo ss -ant | findstr ESTAB
# show all connections for a PID
sudo ss -pant | grep 12345
Rule of thumb:
- if a port isn’t listening → service isn’t running or can’t bind
- if it’s listening but clients can’t connect → firewall/network/routing/DNS issue
2) DNS: confirm names resolve correctly
Use dig (preferred) or nslookup.
# basic lookup
dig example.com
# query a specific record type
dig example.com A
dig kubernetes.default.svc.cluster.local
3) Test connectivity with curl
If you expect HTTP:
# get headers only
curl -I http://localhost:8080
# show verbose debug
curl -v http://localhost:8080/health
# follow redirects (if needed)
curl -v -L https://example.com
4) Test TCP reachability (when HTTP might not be enough)
Linux doesn’t always ship nc by default, but if you have it:
# check if TCP port is open
nc -vz 192.168.1.10 5432
5) Routing: how packets leave the machine
Inspect routes:
# routing table
ip route
# route lookup to a specific destination
ip route get 8.8.8.8
6) Trace the path (advanced but useful)
# trace route (ICMP-based depending on network)
traceroute example.com
# alternative with TCP (often blocked, but helpful sometimes)
# requires traceroute with TCP support or use of other tooling
Common troubleshooting flows
Flow A: “Service is down”
ss -lntp→ is it listening?systemctl status <service>- check logs (journalctl)
Flow B: “Service is up but clients can’t reach it”
- verify DNS (
dig) - test TCP/HTTP (
curl -v) - inspect routes (
ip route) - check firewall rules (local iptables/ufw or cloud security groups)
Next steps
Next tutorials in the DevOps track:
- shell scripting patterns (automation)
- CI/CD pipelines (GitHub Actions)
- IaC (Terraform)
- configuration management (Ansible)
Frequently Asked Questions
What does it mean when a port is ‘closed’ vs ‘filtered’?
Closed usually means the host responded but nothing is listening on that port. Filtered means packets are blocked (often by firewall/security groups), so you can’t tell whether something is listening.
Why does `curl` fail while `ping` works?
Because `ping` tests ICMP reachability, but `curl` tests TCP/HTTP. Firewalls often allow ICMP but block TCP/HTTP ports (or the service is down).