What a Reverse Proxy Does (and Why You Need One)

If you've looked into deployment, you've seen the term "reverse proxy" and probably the name Nginx. It sounds advanced, but the idea is simple — and it sits at the heart of how real web applications are served.

A doorman in front of your app

A reverse proxy is a server that sits in front of your application and handles incoming requests on its behalf. Visitors talk to the proxy; the proxy passes their requests to your app and relays the responses back. Your app never faces the public internet directly — the proxy is the front door.

"Reverse" compared to what?

A regular (forward) proxy sits in front of clients, making requests out on their behalf. A reverse proxy sits in front of servers, receiving requests on their behalf. Same idea, opposite direction — hence "reverse."

What it actually buys you

A reverse proxy is where a lot of important jobs naturally live:

• HTTPS termination — it handles certificates and encryption, so your app doesn't have to.
• Routing — it can send different paths or domains to different apps behind it.
• Load balancing — it can spread traffic across several copies of your app.
• A protective layer — your app stays hidden behind it, and the proxy can serve static files and absorb some abuse.

One clean front door handling encryption, routing, and traffic — so each app behind it can stay simple and focus on its own job.

Why you'll almost always use one

Even for a single small app, putting Nginx in front to terminate HTTPS and serve traffic is the standard, sensible setup. As you grow to multiple apps or multiple servers, the same proxy scales with you. That's why it's one of the first things you meet when you start deploying for real.