NGINX for beginners — what even is a reverse proxy?

If you are just starting your web development journey, you’ve probably heard the name NGINX (pronounced "Engine-X") thrown around. Maybe you followed a tutorial to deploy a React app and you had to copy-paste some mysterious location / blocks into a config file.

But here is the big question that stops everyone cold: What even is a reverse proxy?

Let’s ditch the jargon. By the end of this 5-minute read, you’ll understand exactly what NGINX does, why "proxy" isn't a scary word, and why the internet practically runs on this software.

First, the "Normal" Proxy (The One you already know)
To understand a reverse proxy, we need to look at a forward proxy first.

Imagine you are at work or school. You want to watch a video game stream, but the office Wi-Fi blocks it.

The Setup:

You (The Client)

The Office Wi-Fi (The Proxy)

The Game Stream (The Server)

Instead of connecting directly to the game server, you ask the proxy to do it for you. The proxy hides your identity and bypasses the block.

Forward Proxy Job: "Hides the client (you) from the server."

So, What is a Reverse Proxy?
Now, flip that diagram upside down.

You are chilling at home, and you want to visit google.com. You type it into your browser. You don't actually talk to the main Google computers; you talk to a reverse proxy.

The Setup:

You (The Client)

The NGINX Server (The Reverse Proxy)

The App/Coding (The Internal Server)

Reverse Proxy Job: "Hides the server from the client (you)."

You think you are talking to the main computer, but you are actually talking to NGINX, which then politely talks to the main computer for you.

Why Should You Care? (The 3 Superpowers of NGINX)
If all it does is "hide the server," why is NGINX used by Netflix, Airbnb, and Dropbox? Because hiding the server gives you three magical powers.

1. Load Balancing (The Traffic Cop) Let’s say your Node.js app goes viral. One server can't handle 1 million users at once. You spin up 3 identical servers.

Without NGINX: All 1 million users crash into Server #1. Chaos.

With NGINX: NGINX sits in front and says, "User 1, go to Server A. User 2, go to Server B. User 3, go to Server C."

NGINX spreads the work so no single server has a meltdown.

1. SSL Termination (The Security Guard) HTTPS (the padlock in your browser) is complicated to set up on every single app server.

Without NGINX: You have to configure SSL certificates on your Node app, your Python app, and your Go app. Nightmare.

With NGINX: You configure the certificate once on NGINX. NGINX catches the encrypted traffic, decrypts it, and sends the safe, simple HTTP traffic to your internal apps.

1. Serving Static Files (The Speed Demon) Here is the secret that blows most beginners' minds: You should not use your fancy backend code (Python/Node/Ruby) to serve images, CSS, or HTML.

Backend languages are slow at serving files because they have to "think." NGINX is written in C and optimized for this exact job.

nginx

A typical NGINX config for a React app

server {
listen 80;
server_name mywebsite.com;

location / {
    # Don't touch the React files!
    root /var/www/html;
    try_files $uri /index.html;
}

location /api {
    # Wait... this is a reverse proxy!
    # If the URL has /api, send it to my backend server.
    proxy_pass http://localhost:3000;
}

}
The "Aha!" Moment
Look at the config above again. See that /api block?

On the same domain (mywebsite.com), NGINX is doing two things:

Serving your HTML/CSS directly (fast).

Proxying your API requests to your backend (hidden).

If your browser visits mywebsite.com/api/users, NGINX doesn't say "I don't know that route." It says, "Hold on, I know a guy," and forwards the request to localhost:3000/users.

The user (the browser) has no idea your backend is running on port 3000. The server (Node.js) has no idea if the user is on a phone or a laptop. They are completely hidden from each other.

How to Prove This to Yourself (5 minutes)
You don't need to deploy to the cloud to see this work. Do this on your laptop:

Install NGINX (use Homebrew on Mac, apt on Linux, or Docker).

Start a simple Python server: python -m http.server 8000

Add this to your NGINX config:

nginx
server {
listen 8080;
location / {
proxy_pass http://localhost:8000;
}
}
Restart NGINX and visit localhost:8080. You are looking at your Python server via the NGINX proxy.

The Bottom Line
Stop thinking of NGINX as a scary server "thing." Think of it as Reception Desk for the Internet.

A visitor arrives (HTTP Request).

NGINX asks: "Do you want a photo? (I'll handle it). Do you want to log in? (I'll call the backend). Is this person annoying? (I'll block them)."

The visitor never sees the chaos happening in the back office.

That is a reverse proxy. That is NGINX.

Once you understand that, the entire world of DevOps, microservices, and cloud hosting suddenly makes a lot more sense.

Found this helpful? Let me know in the comments if you want a Part 2 on "The 5 most common NGINX config mistakes beginners make."

Comments

[S M Tahosin]

Clean explanation. Reverse proxies confused me for the longest time when I was starting out. The diagram really helps. One thing worth adding maybe is the difference between proxy_pass to an upstream block vs a direct URL, that catches a lot of beginners when they try to load balance across multiple app instances.