Before we plumb my own confusing thoughts, let me first supply the sentence that made it really simple for me to understand exactly what a reverse proxy does (from “Mastering Nginx”):
A reverse proxy is a web server that terminates connections with clients and makes new ones to upstream servers on their behalf.
So freaking simple, right? If this is all you came for, please, quit reading this and move on to the book.
What had stymied me for many years was pondering the idea, of, what part of a proxy does a reverse proxy reverse? From the standpoint of an ignorant consumer, a my client and a proxy server have a one to one relationship. I have an originating IP address that makes a request to the proxy IP which, in effect, stamps its own identity in lieu of my own before passing it on to the destination.
Also freaking simple. And then I would start thinking about what reverses, and my mind would boggle.
The idea that a proxy server can handle inbound requests from multiple clients is RARELY acknowledged without some substantial digging. Most of the immediately searchable literature is about using the proxy server as a client, instead of how the internals of the proxy server actually work - as in handling request from multiple unrelated clients and then rerouting them so it appears they all originated from the same IP address.
I think part of the confusion is that conceptually, there are multiple, incomplete ways to look at the reversal when not considering the entire request cycle. After struggling with this for a while, I realized I was ignoring the response aspect of the relationship, because the reverse proxy does do its initial work when a request is inbound to the proxy server, same as a straightforward proxy.
Then it kind of hit me:
A proxy server makes a request look like it came from a different IP than the true source, and a reverse proxy makes it look like the response came from a different IP than the true source.
A proxy can be used to shield the identity of the actual requestor, a reverse proxy can be used to shield the identity of the actual destination.
Great. I get it now. And I hope this helps anyone who has also understand how the two are related. I’ll leave you with some ASCII art, which helped me arrive at this conclusion:
[shield the source] from multiple independent clients, allocate requests to a single specific IP ____ --> | | --> | | ---> --> |____|
[shield the end points] from a single client, conditionally allocate requests to specific IPs ____ | | ---> xxx.xxx.xxx.01 --->| | ---> xxx.xxx.xxx.02 |____| ---> xxx.xxx.xxx.03