A proxy on the server's side: one public front door that receives all requests and passes them to the right servers behind it.
Why it exists
A public service needs a single front door that can hide, protect, and route to the many servers behind it. A reverse proxy exists to be that front door, taking every incoming request and passing it to the right backend while shielding them from the open internet.
How it actually works
Where a normal proxy sits near the client, a reverse proxy sits in front of your servers. The outside world only talks to it; it decides which internal server handles each request, and can also handle encryption, caching, and load balancing along the way.
This gives you one controlled entry point instead of exposing every server directly, which is safer and more flexible. NGINX is the software that most often plays this role.
A senior PM walks you through it
A junior PM, stuck
In the security review the engineer said "SSL terminates at the reverse proxy" and I nodded like I understood, but I did not know what that front door actually does. I own the write-up from that meeting and I cannot describe the one box the whole conversation was about. I do not want to paraphrase a sentence I cannot explain.
That front door has a small, readable job, and you can learn it in about five minutes. A reverse proxy is the one public address the internet talks to; every request lands there first and it decides where to send each one. I traced a single checkout request through it from Friday's peak and trimmed it so we can read exactly what the door does at each step.
How one checkout request moves through the front door, Friday 2026-03-06 12:41
212:41:07.002 proxy.tiffinbox.com recv GET /api/orders from 203.0.113.9
where the proxy sends each path, over the private network
112:41:07.003 proxy match /api/ forward to app-server 10.0.1.12:3000 over http
212:41:07.050 proxy match /images/ forward to cache 10.0.1.40 over http (HIT)
312:41:07.055 proxy note: 10.0.1.x servers are not routable from the internet
412:41:07.140 proxy 200 from app-server 10.0.1.12, re-wrap https, send to 203.0.113.9
Click a step to see the lines it points at.
Mistakes I've seen
Hearing "terminates" and thinking something broke. Termination is where the encrypted connection is meant to end and be handled; it is by design, not a failure.
Assuming each URL path is a separate server the public reaches directly. The public reaches one address; the proxy fans paths out to app servers and caches behind it, all invisible from outside.
Forgetting the proxy is a single choke point for cross-cutting work. Security, caching, and routing all live at that one door, so a change there touches every request; that is powerful and risky at the same time.
Confusing the reverse proxy's role with the nginx config that implements it. One is the front-door job; the other is the file that spells out the rules. They are two different conversations.
In the write-up, say: "SSL terminating at the reverse proxy means the https connection ends at our one public front door; it decrypts there, routes /api to the app servers and /images to the cache over the private network, and the app servers are never exposed to the internet directly." You described what the front door does instead of nodding at it.
Where a PM meets this
It's the single front door where cross-cutting concerns (security, caching, routing) get handled, useful context when engineers discuss "the edge" of the system.
Often the same box does reverse proxying and load balancing, which is why the terms blur together in conversation.
Hear it in a meeting
"SSL terminates at the reverse proxy, then it routes to the app servers."