You type an address, press enter, and a page appears. What actually happened in that half second?
Your browser found a server, asked it for the page, and the server answered. That request and response, repeated billions of times a day, is the entire web. Once you can see the steps in that round trip, you can tell where a broken site is broken, and that is half of the DevOps job.
Part 5 put your code in Git. At some point that code runs on a server and answers requests from the internet. When it stops answering, someone pages you. To fix it fast you need a mental model of the path a request takes, so you can point at the exact link in the chain that failed instead of guessing. This part builds that model, and it uses tools you already have from Part 4.
One request, one response
A browser is not magic. It sends a block of text called an HTTP request to a server, and the server sends back an HTTP response. You can watch this yourself with curl, a command that makes the same request a browser would and prints the raw answer. The -I flag asks for just the response headers, the summary the server sends before the page itself.
$ curl -I https://example.com
HTTP/2 200
content-type: text/html; charset=UTF-8
content-length: 1256
cache-control: max-age=3600
server: nginxRead the first line. HTTP/2 is the protocol version, and 200 is the status code that means the request worked. The lines below are headers: the content type tells the browser it is getting HTML, and the server header names the software that answered. That is the whole shape of every web interaction. Your browser asks, the server replies with a status and some headers and a body. Everything else is detail layered on top.
The journey from address to page
The request does not fly straight to one machine. It passes through several stops, and each one is a place a failure can happen. Knowing the stops in order is what lets you diagnose a down site in minutes.
First stop: DNS turns a name into a number
Computers do not find each other by name. They use numeric addresses called IP addresses. DNS, the domain name system, is the phone book that turns example.com into an address like 93.184.216.34. Your browser asks a DNS server for the number before it can send anything. You can do the same lookup by hand:
$ dig +short example.com
93.184.216.34When DNS is misconfigured, the site is unreachable even though the server is perfectly healthy, because nobody can find the number. This is why the first thing an experienced engineer checks on a down domain is whether the name still resolves.
Next stops: load balancer, app, database
With the address in hand, the request goes to a load balancer, a traffic cop that spreads incoming requests across several identical app servers so no single one is overwhelmed. The app server runs your code, which usually needs data, so it asks a database and waits for the answer. The response then travels back up the same chain to the browser. A slow database makes the whole page slow. A crashed app server makes the load balancer route around it, or return an error if none are left. Each stop is independent, and each one fails in its own way.
Status codes tell you whose fault it is
Every response carries a three digit status code, and the first digit tells you the category. You do not need to memorize the hundred codes that exist. Learn the five families and you can read any response at a glance.
| Family | Meaning | Common example |
|---|---|---|
2xx | Success, it worked | 200 OK |
3xx | Redirect, look elsewhere | 301 Moved Permanently |
4xx | Client error, the request was wrong | 404 Not Found |
5xx | Server error, the server broke | 500 Internal Server Error |
502 / 503 | Gateway or unavailable, the app is down or busy | 502 Bad Gateway |
You get paged because the site returns
502 Bad Gateway. That code is precise, and it saves you time. A 502 comes from the load balancer or reverse proxy, and it means the proxy reached out to your app server and got nothing usable back. The proxy is fine. The app behind it is not. So you skip DNS and the load balancer entirely and go straight to the app: is the process running, does ss -tulnp show it listening on its port, what do its logs say? Compare that to a 404, which means the app answered fine but has no such page, or a 500, which means your code ran and threw an error. The number points you at the right link in the chain before you touch anything.Ports let one server run many things
An IP address gets you to a machine. A port gets you to the right program on that machine. One server can run a website, a database, and an SSH login at the same time, each listening on its own port. When you connected over SSH in Part 4, you were reaching port 22. When your app serves a website, it is usually on port 80 or 443. Here are the numbers you will see constantly.
| Port | Used for |
|---|---|
22 | SSH, remote login |
80 | HTTP, plain web traffic |
443 | HTTPS, encrypted web traffic |
5432 | PostgreSQL database |
3306 | MySQL database |
The S in HTTPS is TLS, the encryption that scrambles traffic between browser and server so nobody in the middle can read it. When a certificate expires, browsers refuse to connect and users see a scary warning, even though the app is running fine. Expired certificates are one of the most common self-inflicted outages in the industry, which is why teams automate their renewal and alert on it well before the deadline.
Your two best friends for web debugging are
curl and the browser network tab. On a server with no browser, curl -I gives you the raw status and headers in one line. In a browser, the network tab shows every request a page makes, its status code, and how long each one took. When a page feels slow, open that tab and sort by time. The culprit is almost always one request sitting near the top of that sorted list. Seeing it there beats guessing every single time, and it is the first move a seasoned engineer makes on a slow page.Caching and the CDN: the fast web barely touches your server
Look back at the very first curl output. One header was cache-control: max-age=3600. That line is the server telling the browser it may keep this response for an hour before asking again. Caching is the reason the web feels fast. If every image and stylesheet had to travel all the way to your server on every visit, sites would crawl. Instead, copies are stored close to the user and reused.
A content delivery network, or CDN, takes this further. It is a fleet of servers spread around the world that hold copies of your static files. A visitor in Tokyo gets served from a nearby edge server instead of waiting for a round trip to a machine in Virginia. Your origin server, the real one running your code, only gets asked when the edge does not already have a fresh copy. For a busy site, the CDN can absorb the large majority of traffic, and your origin sees only a fraction of the requests.
Caching has a famous downside. You deploy a fix, but users keep seeing the old broken version because their browser or the CDN is still serving the cached copy. That is where the status code 304 Not Modified and cache purging come in. When your change does not seem to appear, the first question is not is my deploy broken, it is am I looking at a cached copy. Clearing the CDN cache after a release is a routine DevOps step for exactly this reason, and forgetting it is behind a surprising number of it works on my machine but not for users reports.
You do not need every status code
Some study guides make beginners drill dozens of individual status codes. That is wasted effort. In real work you need the five families cold and maybe six specific codes: 200, 301, 404, 500, 502, and 503. The rest you look up the twice a year you meet them. What actually pays off is understanding the chain, so that when you see a code you can say which stop produced it. A person who knows that a 502 means look at the app, not the proxy is worth ten who can recite the full list but cannot act on any of it.
The same goes for the deep networking theory. You do not need to recite every layer of a textbook model to be effective. You need to know that a request travels through DNS, a load balancer, an app, and a database, and that each can fail on its own. That practical map beats memorized trivia in every real incident.
Walk me through what happens when you type a URL and press enter. This is asked in half of all infrastructure interviews. A strong answer follows the chain: the browser resolves the domain to an IP through DNS, opens a connection to that address on port 443, negotiates TLS, sends an HTTP request, the load balancer routes it to an app server, the app may query a database, and the response travels back with a status code. You do not need every detail. Naming the stops in order, and mentioning that each is a failure point, tells the interviewer you understand the system and not just one box in it.
When a site is down, the panic in the room is really one question: where is it broken? The junior who can calmly say the domain still resolves, the load balancer returns a 502, so the app is down, checking its logs now has just turned chaos into a plan. You are not expected to fix everything alone. You are expected to place the failure on the map so the team stops guessing. That single skill makes you useful during the exact moments that matter most.
Free, ten minutes, no setup beyond a terminal. Run
curl -I https://github.com and read the status line and headers. Then run dig +short github.com and see the IP addresses behind the name. Finally, run curl -I https://github.com/this-page-does-not-exist and watch the status change to a 404. How to check you did it right: the first command shows a 2xx or 3xx, the dig returns one or more numbers, and the last command clearly shows a 404. You just watched DNS, HTTP, and status codes work with your own eyes.Web questions a DevOps beginner should answer
What is the difference between a 502 and a 504?
Both come from a gateway or proxy in front of your app. A 502 means the proxy got a broken or empty reply from the app. A 504 means the proxy waited and the app never answered in time, a timeout. 502 usually means crashed, 504 usually means too slow. Knowing which one you are seeing tells you whether to look for a dead process or a slow query.
Is HTTPS really that important for a small site?
Yes. Browsers now mark plain HTTP pages as not secure, search engines rank them lower, and any login or form over plain HTTP can be read by anyone on the network path. Free automated certificates have made HTTPS the default everywhere, so there is no reason to skip it.
What is a load balancer, really?
A single entry point that receives all traffic and forwards each request to one of several identical servers behind it. It lets you run many copies of your app for capacity and survive a server dying, since it simply stops sending traffic to the dead one. It is also where you often terminate TLS and see those 502 and 503 codes.
Do I need to learn networking deeply for DevOps?
Learn the practical chain first: DNS, ports, HTTP, TLS, and load balancing. That covers the vast majority of daily problems. Deeper networking helps as you grow, but the request path in this part is the foundation everything else sits on, so start here and add depth when a real task demands it.
You now have a map of where your code lives once it is running and how a request reaches it. Next up is Part 7 on CI/CD, the automation that takes every commit you push and turns it into a tested, deployable build without a human touching it.
New here? Start with Part 1 on what DevOps actually means and Part 4 on the Linux command line. If cloud terms are fuzzy, the Cloud for Beginners series pairs well with this one.
References
MDN: An overview of HTTP
MDN: HTTP response status codes
Cloudflare: What is DNS?
About The Author
DrJha