HAProxy is a reverse proxy.
this post was submitted on 29 Jun 2023
26 points (88.2% liked)
Selfhosted
39945 readers
470 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
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.org (for example a request to https://media.example.org/my/page) to the "backend" service listening on 127.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.