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.
{{:proxy.jpg?600|}}
You'll need a linux machine of some sort for this. Reverse proxies are fairly lightweight so I would suggest spinning up a debian virt or utilizing a raspberry pi with raspbian if you want a physical proxy. This guide will assume your linux server is already setup, so if it isn't, head over to my 'building a debian virtual machine' guide and start there first.\\
ssh to your linux server using your program of choice (secure CRT, MTputty, etc)\\
use sudo for the commands if you are not logged in as root\\
update linux and install nginx:\\
apt-get update\\
apt-get install nginx\\
disable the default host:\\
unlink /etc/nginx/sites-enabled/default\\
create your first host in the sites-available directory:\\
nano /etc/nginx/sites-available/myfirsthost\\
this will open the file editor, which you can paste this into:\\
server { \\
listen 80; \\
location / { \\
proxy_pass http://internal-IP-of-your-first-host; \\
} \\
} \\
\\
control x, y (this exits nano and saves)\\
We now create a symbolic link from the 'myfirsthost' config file in your 'site-available' directory to the same file name in your 'sites-enabled' directory:\\
ln -s /etc/nginx/sites-available/myfirsthost /etc/nginx/sites-enabled/myfirsthost\\
test and restart nginx:\\
service nginx configtest\\
service nginx restart\\
If all goes well, visiting the IP of your proxy server should result in being forwarded to your first host. If configtest returns errors, you will need to troubleshoot them, check your IPs, file names, and syntax of the commands you've run. \\
If you add a dns entry (see dns section of wiki) and modify 'yourfirsthost' config a bit further (you will only need to edit the one in the sites-available directory, thanks to the sim link), you can make your proxy a bit more powerful: \\
server { \\
listen 80; \\
server_name your-first-hostname; \\
location / { \\
proxy_pass http://internal-IP-of-your-first-host; \\
} \\
} \\
Now, visiting your-first-hostname (ie: iviolet.net) should hit your reverse proxy server, then forward to your-first-host. Note that this will only work internally, until you actually purchase and setup a domain name (see the domain name section of the wiki) and utilize either static IPs from your ISP, or more commonly --and cheaper, utilize dynamic DNS (also covered in the DNS section of the wiki). \\
Once you've added a few different entries into your 'sites-available' directory, configured them to point to different servers or virtual machines, and sim linked them to the sites-enabled directory, you're ready to really put nginx to work with SSL, sub-domains, and other features. More on that in Helder's reverse proxy guide. \\