I have a noob question but seem overwhelmed with all the information I get about it. Basically, why do I need a reverse proxy if all my services are not public? Every guide or video for self hosting there’s always talk of a reverse proxy, have been doing it wrong?
Here’s my setup: I have proxmox running with LXC containers and VM’s for different services some have docker. I have HAProxy on PfSense with a wildcard cert. and the built-in dns resolver, and I vpn home every time I need something.
Have I be going about this the wrong way? Would I benefit from Nginx or traefik? Or is HAProxy enough? Sorry for the stupid question, I’m like a kid with a new toy and overwhelming myself.
HAProxy is a reverse proxy.
As mentioned it’s a stupid question, it’s just all of this talk of Nginx got me confused that I need to have it on proxmox or everything will crumble
The purposes of reverse proxies vary.
One of the main reasons is that you want to host multiple services on the same IPv4 and port since you usually only get one IPv4 (works for IPv6 too but there getting more than one from your hoster is a lot easier). This is known as name-based virtual hosting.
Another thing that is often (but not always) handled by a reverse proxy is SSL/TLS termination. That way the actual application doesn’t have to worry about the certificates or crypto-related security updates. Sometimes TLS is used again on the bit between the reverse proxy and the backend server but if they are both on the same physical machine that bit is often skipped.
There are also other services such as rate limiting, caching or fully featured Web Application Firewalls (WAF) and of course CDNs that come in reverse proxy form but you shouldn’t need to worry about those too much for a small personal website that isn’t used by thousands of users.
This answer says it all. A reverse proxy dispatches HTTP requests to several “backend” services (your applications), depending on what domain name is requested in the HTTP request headers. For example using Apache as a reverse proxy, a config block such as
<VirtualHost *:443> ServerName media.example.org ... ProxyPass "/" "http://127.0.0.1:8096/" </VirtualHost>will redirect requests made on port 443 with the HTTP header
Host: media.example(for example a request tohttps://media.example/my/page) to the “backend” service listening on127.0.0.1(local machine), port 8096 (which may be a media server, a wiki, …). This way you only have to expose ports 80/443 to the outside network, and the reverse proxy will take care of dispatching requests to the correct “backend” service.Most web servers can be used as reverse proxies.
In addition, since all requests go through the proxy, it is a good place to manage centralized logging, SSL/TLS certificates, access control such as IP whitelisting/blacklisting, automatic redirects…
Thank you! mentioning headers got me to tinker and fix a service that wasn’t running with HAP.
Thank you so for tolerating my question and the informative answer
A reverse proxy can still be useful internally by allowing you to collect many different services under one name. It can greatly reduce your certificate management as well. I can’t think of much else you’d gain though.
But you don’t NEED one. I manage my home network without one, and I have two dozen machines, counting VMs. Gotta vpn to get to anything, except game servers and SMTP. Nothing wrong with that approach.
So reverse proxies are often used in self-hosted and home lab environments to keep things simple.
Most self hosted apps end up with something like http://someip:1234 and http://someotherip:8372. With a reverse proxy you can setup and internal/private domain and have http(s)://app1.myinternaldomain.com or http(s);//myinternaldomain/app2 depending on which way you want to do it.
Reverse proxies are NOT required usually for self hosted apps on your internal network. they just help with organization, because remembering port numbers is stupid. Frankly you could also use one of those dashboard apps with links, or even just old school bookmarks. But some of us set up all these apps for the of it and to learn how all this stuff works, getting a reverse proxy into the mix is just one more step in that.
In addition: NGINX is a webserver that can also work as a reverse proxy. That’s how It’m using it most of the time. HAProxy and NGINX will do the job nicely and don’t have too much overhead. Traefik on the other hand is an edge router and - IMHO - far more complex to configure. Especially for your usecase it’s oversized, since it also does loadbalancing and a lot of other stuff, your setup already does sufficiently well.
I don’t know, nginx gave me some really hard time… Traefik was way easier to setup, specially with my docker containers.
But that’s probably because I’m more into yaml formatting, than pure nginx syntax.
It’s just subjective, how easy or hard something is to configure :-) If traefic solves your problem and you can configure it easily: Win!
In a sense reverse proxies are like DNS. You don’t really need them (can just use IP addresses), but they can make using your services a whole lot easier. You can hide internal changes to your hosting infrastructure from the outside world for example, just like “hiding” IP address changes of your servers. E.g. if you change something about your self-hosted lemmy instance all links to it can keep working, because they link to the proxy. They can also handle SSL certificates, so the services don’t have to do that themselves, making life easier for their devs.
I did avoid them for a long time. Once I started to figure out how to self certify for https NPM became very helpful. DNS challenge does not require you to open any ports. you need a domain that supports dns challenge, though. Pointing cname to local ip of reverse proxy. And some routers may require rebind protection entry for that domain. Afterward: https and nice names for all my local only services.
