Linux

The whole series on one page. Print it, pin it, put it in your runbook. Parts 0 through 6 explain why each of these works. This is the lookup table

Five parts in, we've covered sockets, counters, packets and latency. There's a gap, and it's the one that eats the most time on modern

"The site is slow." Three words, and almost no information. Slow where? Slow for whom? Slow by how much, compared to what? Latency work is mostly attribution — cutting

Counters tell you that something is wrong. tcpdump tells you what happened. Most engineers can start a capture. Far fewer can look at forty lines of output and say "

"We're seeing packet loss." That sentence starts more wasted investigations than any other in infrastructure. It's not a diagnosis. It's a feeling.

You have nginx running. Someone says it's broken. You need to know, in the next thirty seconds: who is connected, from where, to which port, and whether anything

Most engineers learn Linux networking backwards. They memorise commands first, then spend years never quite knowing which one to reach for. So they run netstat -an, stare at 4000 lines,

Somebody says "the app can't reach the database." You have a terminal and no idea where to start. This post is the on-ramp. Vocabulary, then

Worker processes, worker_connections, file descriptors, and the two kernel queues in front of them - plus the order to check things in when someone says nginx is slow.

Complete nftables guide: the modern replacement for iptables with unified IPv4/IPv6, sets, atomic updates, and cleaner syntax for Linux firewalls.

Complete iptables firewall guide: tables, chains, rules, real server configuration, troubleshooting, and practical security examples for Linux systems.

Complete WireGuard VPN guide: hub-spoke setup, peer configuration, routing with AllowedIPs, troubleshooting, and practical use cases for secure networking.