This is an old revision of the document!
Reverse proxy servers are typically used to forward requests from outside clients to internal servers. The clients are not aware there is an intermediary server, and often, the reverse proxy hosts an SSL for encryption (https) purposes.
The example picture at the bottom of the page describes the following workflow: We see a client device reaching a firewall via a hostname which dns will translate to its public facing IP, the firewall will then forward the request via PAT (port address translation) to the reverse proxy server. Usually this port is 80 or 443, or both, and PAT will be configured to forward to the reverse proxy server's internal/private IP.
The reverse proxy server will then use the hostname the client was trying to reach to determine which internal server it needs to forward to. Several hostnames can be used, or more often, sub-domains. For instance, right now, you are reaching my wiki server via wiki.iviolet.net. Your laptop or desktop's request for this sub-domain hit my edge device (firewall), PAT sent the request to my reverse proxy server, and that server forwarded the request to my wiki server based on the sub-domain. The same would happen with my cloud server, home automation server, or plex server, all based on sub-domain.
This can be done with a website, several different websites, webui's, or whatever else you would like to be accessible from the outside. Reverse proxy servers also allow for hardened security as you can place the server in your DMZ (demilitarized zone), use your reverse proxy server to provide SSL to your internal servers, and reduce the amount of PAT entries, ACL's, and network objects in your firewall or router configuration. Instead, you can simply point 80/443 to your reverse proxy, this avoids exposing multiple ports, forwarding them directly to different servers, and putting your network at risk.
Discussion