Bye-Bye Port Numbers! My Journey to a Proper Reverse Proxy in the Homelab

Hello, Fellow Homelab Enthusiasts!

If you're anything like me, your homelab probably started with a few services, each happily running on its own dedicated port. Plex on 192.168.1.100:32400, Nextcloud on 192.168.1.100:8080, Grafana on 192.168.1.100:3000... you get the picture. For a while, it's manageable. You keep a mental note, or maybe a sticky note, of all those precious port numbers. But then, your lab grows. You add more services, experiment with new tools, and suddenly, you're drowning in a sea of IP addresses and four-digit numbers.

The Port Number Pain Point

My breaking point came when I started deploying more Docker containers. Each new service meant another port to remember, another entry in my mental database. It wasn't just about remembering; it was about the cognitive load. Every time I wanted to access a service, I had to recall its specific port. What if I wanted to share a link with a family member? "Just go to 192.168.1.100:8080" doesn't exactly roll off the tongue, nor is it very user-friendly.

I knew there had to be a better way. The internet, our endless source of wisdom, kept pointing to one solution: a reverse proxy. And so, my journey began.

Enter the Reverse Proxy: My Homelab Hero

The concept of a reverse proxy is beautifully simple: instead of directly exposing all your services on different ports, you have one central server that listens on standard HTTP (port 80) and HTTPS (port 443). This server then intelligently forwards requests to the correct backend service, based on the requested domain name or path.

For my setup, I decided to go with Nginx. It's incredibly powerful, widely documented, and gives you a lot of control. While tools like Caddy or Traefik are fantastic for their auto-configuration capabilities, I wanted to understand the nitty-gritty, and Nginx felt like the right choice for that hands-on learning experience.

The Setup Process (and What I Learned)

1. The Base Nginx Installation

I spun up a new lightweight VM (or a Docker container, depending on your preference) and installed Nginx. The initial config was straightforward: get it running and serving a basic 'Welcome' page. This was the easy part!

2. DNS is Your Friend (and Sometimes Your Foe)

This was one of the biggest learning curves. To make plex.mydomain.local or nextcloud.mydomain.local work, I needed a way to tell my network that these domain names should point to my reverse proxy's IP address. I considered:

• Editing /etc/hosts on each device: Quick and dirty, but not scalable or convenient.

• Setting up a local DNS server: This was the proper solution. I already had AdGuard Home running, which has a fantastic feature for custom DNS entries. I configured it to resolve all *.mydomain.local requests to my Nginx proxy's IP. Learning: Understanding DNS resolution within your local network is crucial for a robust homelab setup.

3. Nginx Configuration: The Magic Happens

This is where Nginx truly shines. For each service, I created a new server block configuration. Here's a simplified example for Nextcloud:

server {    listen 80;    server_name nextcloud.mydomain.local;    location / {        proxy_pass http://192.168.1.100:8080; # The internal IP and port of Nextcloud        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header X-Forwarded-Proto $scheme;    } }

Learning: The proxy_pass directive is the core. The proxy_set_header directives are vital for the backend service to correctly identify the client's IP and the original request protocol (HTTP/HTTPS). Without them, services might misbehave or have issues with authentication or logging.

4. SSL/TLS: Securing My Services

Accessing services via http:// felt... naked. I wanted HTTPS for everything. This meant diving into Let's Encrypt with Certbot. For internal-only domains (like *.mydomain.local), you typically can't use public Let's Encrypt certificates directly, as they require public DNS validation. However, if you have a publicly accessible domain and use it with a subdomain pointing to your homelab via a VPN or reverse proxy exposed to the internet, then Certbot is your best friend.

For my purely internal setup, I initially used self-signed certificates, which came with browser warnings. The better solution, if you don't expose services publicly, is to set up your own Certificate Authority (CA) in your homelab or use a tool like mkcert for development certificates that your devices can trust. If you *do* expose services, Certbot makes it incredibly easy to get free, trusted SSL certificates.

Learning: SSL/TLS is complex, but tools like Certbot simplify public certificate management immensely. For internal services, understanding self-signed certs or setting up a local CA is a valuable skill.

The Sweet, Sweet Benefits

The transformation was incredible:

• Clean URLs: No more cryptic port numbers! Just plex.mydomain.local, nextcloud.mydomain.local, etc.

• Centralized SSL: All my SSL certificates are managed in one place (on the Nginx server).

• Enhanced Security: My backend services are no longer directly exposed. Only the reverse proxy needs to be accessible.

• Easier Management: Adding a new service is now a matter of creating a new Nginx config file and a DNS entry.

• Load Balancing (Future-Proofing): Nginx can also act as a load balancer, which is a fantastic feature for scaling services down the line.

Challenges Overcome

• DNS Resolution: Getting my local DNS server to correctly resolve internal subdomains was a significant hurdle.

• Nginx Configuration Syntax: Small typos or incorrect directives could lead to frustrating 502 Bad Gateway errors. The Nginx logs (/var/log/nginx/error.log) became my best friend.

• SSL/TLS for Internal Domains: Initially, I struggled with how to get trusted certificates for purely internal services without public DNS records.

Final Thoughts

Setting up a reverse proxy felt like a rite of passage for my homelab. It elevated my setup from a collection of services to a more cohesive, professional-feeling environment. The initial learning curve was steep, but the knowledge gained about Nginx, DNS, and SSL is invaluable and applicable far beyond the homelab.

If you're still battling with port numbers, I highly encourage you to take the plunge. It's a rewarding journey that will make your homelab experience significantly smoother. Happy proxifying!