From Wikipedia;

A proxy server that appears to any client to be an ordinary web server, but in reality merely acts as an intermediary that forwards the client's requests to one or more ordinary web servers.

In other words, it is like a man in the middle that redirects traffic. The most common case is for visiting severs for a name or fully qualified domain name (FQDN), like www.enchilada.lan, instead of the ip of the server (e.g. 192.168.1.25).

This FQDN must be registered in your DNS provider. If you are running a DNS sever in your home lab (like pi-hole, Adguard or technitium), all you need to do is to point the FQDN to the reverse proxy.

For example, setting an A Record: *.enchilada.lan to 192.168.1.25 in your local DNS will redirect sites like taco.enchilada.lan, sope.enchilada.lan, quesadilla.enchilada.lan to the 192.168.1.25 address, which will be our reverse proxy server.

Then the reverse proxy server, will forward the traffic to the desired ip/service/server (say taco.enchilada.lan -> 192.168.1.30, sope.enchilada.lan -> 192.168.1.120 and so on). Setting this configuration depends on the reverse proxy that you use, here are the common ones:

Nginx

nginx is a web server, reverse proxy and more. I think it is the most popular, you can run it standalone or within docker. It is mainly configured through config files. It seems tedious to write each config file, but luckily there are tools to simplify the work and are beginner friendly.

Nginx Proxy Manager

Nginx Proxy Manager is very user friendly nginx configuration project, you configure the reverse proxies through a webui and can also set SSL using Let's Encrypt. You run it in a docker container, log in and start to have fun.

SWAG

SWAG also serves to configure nginx and get SSL certs. Unlike NPM, swag does not offer a webui to configure nginx, but provides several templates for the most common services (located in the /config folder), you can also check them here. After correctly set the swag container, all you have to do is rename the template you want to use from .conf.sample to sample and restart the container.

Traefik

Traefik is a modern reverse proxy, it is very extense as it haves a lot of features and it is mainly focused to intregrate with Kubernetes, Docker Swarm and Mesos. In others words, big scalability. It is just too much for me and the syntax of the configuration always confuses me.

Caddy

Caddy is another popular reverse proxy, it is versy extensible, very well documented and the syntax is very simple to comprehend. The config is managed through a Caddyfile similar to a json file. It also enable HTTPS via self signed certificated or you can enable SSL auto-certification if you have a public domain, using LetsEncrypt.

Using the local root caddy SSL certificate in local environments is ok, the draw back is that you need to copy the root.crt to each device you will use (imagine copying that to +20 devices) or be forced to trust the certificate everytime you visit the site, or just disable HTTPS in the Caddyfile.

Here is how an example of a Caddyfile for a wildcard site:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# with HTTPS enabled
*.enchilada.lan {
    @site1 host site1.mysite.lan
    handle @site1 {
            reverse_proxy 192.168.1.25:8080
    }
}

# or with HTTPS disabled
*.enchilada.lan:80 {
    @site1 host site1.mysite.lan
    handle @site1 {
            reverse_proxy 192.168.1.25:8080
    }
}

The root.crt is located inside the ~/.local/share/caddy/pki/authorities/local path. However, if caddy is running as the caddy user, then the full path should be /var/lib/caddy/.local/share/caddy/pki/authorities/local (this caused me a little bit of confusion, since I did not find it very clear in the local https and data directory docs, until I found this comment).

Final thoughts

  • There are many alternatives for reverse proxy, there is also zoraxy and godoxy.
  • I used godoxy for a moment, since it ingrates easily with docker compose, automatically listens to the active containers and sets the reverse proxy route to the container.
  • I normally use caddy for my homelab without HTTPS, since it is not exposed to the internet and I only access it via tailscale.
  • For services exposed to the internet, I have set NPM and SWAG without many hassle, obtaining the certificates with DuckDNS and HTTP challenges.
If you found this content useful, please support me :
BTC: 1E2YjL6ysiPxRF4AEdXChpzpesRuyzgE1y