Nginx as a Load Balancer

If you’ve spent any time around web servers, you’ve probably heard the name Nginx thrown around. And here’s the thing:

• It’s one of the most widely used pieces of software running the internet today.
• People mostly know it as a web server, the thing that serves up web pages.
• But Nginx has another superpower, it can also act as a load balancer, spreading incoming traffic across many servers.

So in this lesson we’ll see what Nginx is, how you’d set it up to balance load with a tiny config, and which balancing methods it knows. By the end you’ll be able to read a basic Nginx config and explain it to an interviewer.

🌐 What is Nginx

Let’s start with the basics, because the name covers a few jobs at once. Here’s what Nginx actually is:

• Nginx (you say it “engine-x”) is a popular, fast, free web server. A web server is the software that listens for requests and sends back web pages.
• It’s also a reverse proxy. A reverse proxy is a server that sits in front of your real servers and forwards requests to them, so the client never talks to the backends directly.
• And because it sits in front and forwards traffic, it can spread that traffic across many servers. That’s exactly what makes it a load balancer too.

So one tool, a few hats: web server, reverse proxy, and load balancer. For this lesson, we care about the load balancer hat.

🧩 Why Nginx for Load Balancing

Okay, but why do so many teams reach for Nginx when they need to balance load? A few good reasons:

• It’s lightweight and fast. It can handle a huge number of connections without eating up much memory, so it doesn’t become the bottleneck.
• It’s free and open source, so there’s no license to buy to get started.
• It’s everywhere, which means lots of guides, lots of help online, and lots of people who already know it.
• It does many jobs at once. The same Nginx box can reverse proxy, balance load, cache responses, and serve static files. So you get a lot of value from one tool.

Basically, it’s a safe, well-known choice that does the job well and doesn’t cost you anything to try.

⌨️ A Simple Config

Let’s look at the smallest config that actually balances load. Don’t worry, it’s short. Here’s an Nginx config with three backend servers.

upstream app_servers {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

server {
    listen 80;

    location / {
        proxy_pass http://app_servers;
    }
}

Now let’s read it line by line, top to bottom:

• upstream app_servers { ... } defines a group of backend servers and gives the group a name, here app_servers. “Upstream” is just Nginx’s word for “the servers behind me that I forward to”.
• Each server line inside that block is one backend, written as its IP address and port. So we’ve listed three app servers, all on port 8080.
• server { ... } is the part that faces the outside world. This is Nginx itself listening for visitors.
• listen 80; means Nginx accepts incoming requests on port 80, which is the normal port for web traffic.
• location / { ... } says “for requests to any path, do the following”.
• proxy_pass http://app_servers; is the magic line. It tells Nginx to forward each request to the app_servers group, and Nginx picks one of the three backends to handle it.

So in plain words: a visitor hits Nginx on port 80, and Nginx quietly passes that request along to one of your three app servers. The visitor never knows there were three.

🔁 Algorithms Nginx Supports

How does Nginx decide which backend gets the next request? That’s the job of a load balancing algorithm, the rule it uses to pick. Nginx gives you a few to choose from:

• Round robin is the default. It just hands requests to each server in turn, one after another, then loops back. You don’t have to write anything, you get this for free.
• least_conn sends the next request to the server with the fewest active connections right now. Handy when some requests take longer than others.
• ip_hash picks a backend based on the visitor’s IP address, so the same visitor keeps landing on the same server. That’s useful when a server needs to remember things about that user.

You turn on a non-default one by adding a single line inside the upstream block, like this.

upstream app_servers {
    least_conn;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

If you want the full picture of how these methods work and when to pick each one, check the dedicated lesson on Load Balancing Algorithms. Here we just want you to know Nginx supports them.

⚙️ How a Request Flows

Let’s trace one request through the whole thing, so the picture sticks. Here’s the trip:

• A client (a browser, an app, whatever) sends a request to Nginx.
• Nginx looks at its upstream group and picks one backend using the chosen algorithm.
• That backend does the work and sends its response back to Nginx.
• Nginx hands the response back to the client.

So Nginx sits in the middle the whole time. The client only ever talks to Nginx, never to the app servers directly.

That single Nginx box is the front door, and the app servers are the rooms behind it.

⚡ What Else Nginx Does

Balancing load is just one trick. Since Nginx already sits in front of everything, people lean on it for a bunch of other jobs too:

• SSL termination. Nginx can handle the HTTPS encryption work, so your app servers don’t have to. The lock-and-unlock happens at Nginx, and traffic behind it can stay simple. (“SSL termination” just means HTTPS ends, or terminates, at Nginx.)
• Caching. It can save copies of responses and serve them straight back, so your backends don’t redo the same work for every visitor.
• Serving static files. Images, CSS, and JavaScript can be sent directly by Nginx, fast, without bothering the app servers.
• Health checks. It can notice when a backend stops responding and quietly stop sending traffic there until it recovers.

So that one box is doing a lot of heavy lifting. That’s a big part of why Nginx is so popular.

⚠️ Things to Watch

Here’s the catch, and it’s an important one. If all traffic flows through one Nginx box, then:

• That single box becomes a single point of failure. A single point of failure is any one part whose breakdown takes the whole system down with it.
• If that one Nginx goes down, every backend behind it becomes unreachable, even if all of them are perfectly healthy.

So in real setups, you don’t run just one Nginx. You run two or more, so if one dies another keeps serving. Making the load balancer itself redundant like that is what stops it from being the weak link.

⚠️ Common Mistakes and Misconceptions

A few things trip people up with Nginx. Let’s clear them out:

• “Nginx is only a web server.” It started as one, but it’s also a reverse proxy, a load balancer, and a cache. That flexibility is the whole point.
• “One Nginx is enough.” For learning, sure. But in production a single Nginx is a single point of failure, so you run more than one.
• “Nginx is the app server.” No. Nginx forwards requests to your app servers, it doesn’t run your application code. It’s the front door, not the kitchen.
• “proxy_pass and upstream are the same thing.” They work together but do different jobs. upstream lists the backends, and proxy_pass is what actually sends traffic to that list.

🛠️ Design Challenge

Try this on your own to test yourself.

Imagine Alex runs a small site with two app servers behind one Nginx. Traffic is growing, and some requests are much slower than others. Write down:

• Which algorithm you’d switch to so the busier server doesn’t get overloaded, and why.
• One change you’d make so a crash of the Nginx box doesn’t take the whole site offline.
• One extra job (besides balancing) you could hand to Nginx to take load off the app servers.

If you can answer those three, you’ve got a real working mental model of Nginx as a load balancer.

🧩 What You’ve Learned

You can now read a basic Nginx load balancer setup and explain it. Here’s what you’ve picked up.

• ✅ Nginx is a fast, free web server that also acts as a reverse proxy and a load balancer.
• ✅ An upstream block lists your backend servers, and proxy_pass forwards traffic to them.
• ✅ Nginx supports round robin (default), least_conn, and ip_hash for picking a backend.
• ✅ A request flows client → Nginx → one backend → back to the client.
• ✅ Nginx can also do SSL termination, caching, static files, and health checks.
• ✅ One Nginx is a single point of failure, so run more than one in production.

🚀 What’s Next?

You’ve got Nginx as a load balancer down. Next, go deeper into the ideas it builds on.

• What is a Reverse Proxy? explains the front-door pattern Nginx uses, in detail.
• Load Balancer Architecture zooms out to how load balancers fit into a real system, including how you make them redundant.

Once you’ve got those, the way big systems route traffic will start to feel obvious.