I see so many posts and people who run NGINX as their reverse proxy. Why though? There’s HAProxy and Apache, with Caddy being a simpler option.
If you’re starting from scratch, why did you pick/are you picking NGINX over the others?
You must log in or register to comment.
nginx is mature and has a lot of support online. A lot of server projects assume you’re using nginx, as well. I’ve only ever seen caddy instructions on newer projects and even then, they usually also have nginx instructions.
Plus, I already know how to use it.
You want to access your server under CG-NAT from the outside or what is the point??
You can do that with Wireguard and NAT.
Good question. I chose it initially because it was open source and way easier (in my eyes) than Apache. I don’t recall the others being an option at the time, or I was not aware of them. nginx does what I need without complaint, so I haven’t switched.
At $dayjob I switched from Apache to nginx 15+ years ago. It’s Callback/Event based process model ran circles around Apache’s pre-fork model at the time. It was very carefully developed to be secure, and even early on it had a good track record. Being able to have nginx handle static content without tying up a backend worker process was huge, and let us scale our app pretty well for the investment of time. Since then, Apache implemented threaded + Event based process models, Caddy, traefik, and a bunch of others have entered the scene.
TBH, I think the big thing nowadays is sane defaults, and better configuration, even automatically discovered configuration – traefik is my current favorite for discovering hosts in consul/Kubernetes/simple host definition files, but since traefik can’t directly serve files, I simply proxy from traefik to … nginx :)
NGINX is a bit more hands on than some other options but it’s mature, configurable and there’s a huge amount of information out there for setting it up for various use cases.
in my case, its what I set up when i was first getting into this and it works, so I don’t want to go through setting up anything else.
Nginx handles more connections than Apache, given the same resources. HAProxy does not have web server functionality like the former two, so Nginx is the natural upgrade from Apache. Caddy is relatively new, I’m not sure how it compares other than being easier to set up.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CA (SSL) Certificate Authority DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol NAS Network-Attached Storage NAT Network Address Translation SSL Secure Sockets Layer, for transparent encryption TCP Transmission Control Protocol, most often over IP TLS Transport Layer Security, supersedes SSL UDP User Datagram Protocol, for real-time communications VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) nginx Popular HTTP server
[Thread #888 for this sub, first seen 26th Jul 2024, 04:25] [FAQ] [Full list] [Contact] [Source code]
nginx has more features and flexibility than haproxy, such as being a web server. If I wanted just a pure proxy, I’d use haproxy. Apache is primarily a web server, and a pain to configure.
Personally I use Traefik. Add it to docker-compose, set up LE certs, add a few lines to each container, and it Just Works. No extra config on Traefik itself.
@selfhosted @Findmysec what is the problem with nginx? 🤔
I think a lot of people just haven’t heard of Caddy. Since I’ve found it I haven’t used anything else.
It might be worth looking more deeply into. From a cursory glance, it might be usable for my usecase, but many service have configuration examples for NGINX (or Apache if they’re old). I’ve never seen caddy examples. What has your experience been with adapting those examples to caddy?
Caddy is so simple you don’t really need configuration examples. The extra configuration many docker services have you configure in Nginx are already done by default with Caddy. Though I have seen Caddy config examples around sometimes.
If all you’re using it for is reverse proxying, you don’t need config examples for Nginx or Caddy, just understand how to configure them.
Some good answers in here already. It boils down to a couple points for me:
- Back when I started selfhosting, it was either nginx or apache, and I found nginx better and easier to set up
- All the nginx knowledge I learned years ago still works just the same as it did back then, so why potentially mess things up by switching if it all still works
- Basically every project has an example nginx config for reference, that can’t be said about other proxies
- It is easier to find support online for edge cases that might pop up with nginx due to the ubiquity of its use and years of history
Because I have it in use as my main webserver, sure I could put that behind haproxy too but why? I like to keep my server setup small and easy, without unnecessary duplications. Nginx can everything that haproxy can, and more.
Back when Nginx started, Apache was the only alternative and a big pain in the ass. That’s how it became popular.
Apache still is a pain in the ass. The only guide I found useful were from 20 years ago or so. All “modern” ones I found didn’t explain stuff, but were more like “copy paste this, now you’re done”. They never fit my usecase.
I honestly don’t know why people new to webhosting even bother with Apache when NGINX is around. It’s just so much easier.
Because Nginx Proxy Manager exists.
And also because for me it started from web hosting where Apache and Nginx dominate and later because of many easy to understand example configs from the net including many “docker letsencrypt” examples.
Very much became it exist. Its way simpler to do in the GUI.
Did not have to learn anything specific, and can work for things not in docker containers too, like the Nextcloud Snap.
And it makes it very easy to get and maintain certificates.
NGINX can really do a lot of things out of the box while being pretty easy to configure. NGINX can serve static files, it can proxy emails, it can do FastCGI, it can do UWSGI, it can do HTTP proxying, you can run Lua code inside NGINX to do things, there’s a module for RTMP live streaming. You can also implement some stuff like external authentication to protect your services/authenticate them at the proxy level. It can also do caching. Not all that useful with all those Rust and Go apps with their own built-in web server but if you run large legacy apps at scale it’s great, you can offload a lot of stuff away from your slow ass PHP app.
Caddy’s simpler but the current battle tested popular option is NGINX.
HAproxy is good at what it does but it’s only good at proxying and simple rules. For the most part, it’s used as a load balancer and router and doesn’t really process the requests itself. It can alter some things in it but it’s limited, and it only does HTTP and TCP. So you can’t really run PHP or Python or Ruby or whatever applications directly behind HAproxy. That makes NGINX a better choice there because NGINX deals with HTTP and only passes the request details to the application which doesn’t have to do HTTP on its own. I usually see HAproxy load balancing to NGINX hosts with some PHP/Python/Ruby app behind them.
Apache is old. It’s gotten better but the way it works just doesn’t reflect most modern use cases. I remember when NGINX popped off like 15 years ago and just how much more resource efficient it was and how happy I was with the upgrade. So it exists and still works but not very popular anymore. It’s a bit easier to set up but also a bit weird with things like mod_php which runs directly inside Apache instead of a dedicated user that can be better sandboxed.
Traefik is getting traction in big part because it fits well with the Docker ecosystem and just sets itself up automatically.
There’s also Envoy if you want some serious proxying and meshing but setting that one up is truely headache inducing.
They’re all pretty good web servers regardless, it comes down to preference. There’s no right choice because everyone’s needs are different.
HAproxy is good at what it does but it’s only good at proxying and simple rules. For the most part, it’s used as a load balancer and router and doesn’t really process the requests itself.
To add something here: HAProxy’s ACLs are more powerful than anything nginx, Apache or even Envoy can do. Of course HAProxy is not a web server but “just” a reverse proxy that speaks HTTP (and TCP) but what you can do with its ACLs is often extremely impressive in its simplicity and elegance. A single-line ACL in HAProxy would require loading additional modules in nginx and writing a screenful of configuration directives. Though the average self-hoster will probably never need any of the power HAProxy offers.
In the past 20 years I have professionally used all four of these as web servers and/or reverse proxies and I am pretty confident that HAProxy beats all others when it comes to request processing. Though Envoy might be getting there.
Having used HAProxy for 15 years commercially, I absolutely agree with this. There are lots of complex features of HAProxy that only a dedicated proxy can provide. The acls, deep packet inspection and stick tables are a few.
Whilst it doesn’t directly “serve” PHP or Python - it’s a load balancer so can just have regular Apache or nginx backends serving content which is arguably its main use case. For homelab this doesn’t always make sense but I would pick nginx for high traffic commercial environments.
Traefik’s marketing as the “Docker reverse-proxy” put me off since I like technologies to stay agnostic of each other (personal preference).
Your arguments are correct, and usually I’d run a separate web server but I suppose for a homelab having less things to manage is great
Traefik does auto discovery and you can register different configuration providers. Don’t need docker? Then don’t use the docker label-based provider. It is really flexible and has sensible defaults. Other than a few quirks in the basic auth support I haven’t had any problems. And at work it powers our globally utilized infrastructure without any hiccups.
HAproxy is good at what it does but it’s only good at proxying and simple rules.
It’s possible to write very complex rules/ACLs with HAproxy… stick-tables, ACLs with regexes on whatever HTTP header, source or destination ACLs, map files, geoblocking, lua scripting, load-balancing from round-robin to host header load balancing, dynamic backend servers provisionning through DNS… Not that you can’t do it with Nginx (it started as a reverse-proxy before becoming a jack of all trades), nor that nginx isn’t a great tool (it is!), but HAProxy can do very complex things too. It also follows the good ol’ UNIX philosophy of “one program to do one thing and do it well” and thus doesn’t try to be a webserver, hence why you need a webserver behind it to serve anything from static files to PHP/Python/whatever.
Not sure why you say haproxy can’t serve python. I do it all the time. You just use something like python waitress and then point haproxy to it’s port.
It depends on what you use on the Python side. Classically that would have been uWSGI or one of the *SGI interfaces, and lately ASGI.
Sure, one can totally make Python apps that serve HTTP directly. The same can be done with PHP (and Ruby and others) as well, but most people still run their PHP through PHP-FPM over FastCGI because you can offload a lot of the work to the much faster NGINX side. A fair amount of apps make use of
X-Accel-Redirectto serve private files, so you don’t tie up a PHP worker for an hour serving the user’s 2GB file.But yes, as those languages all move to async computing and away from worker pools, it’s more common to see those serve HTTP directly, and there’s less and less need for a proxy that supports those other protocols. The async event loop is what made NGINX special when it came out, so naturally languages that moves to that model greatly reduce the need for that as well, they too can easily handle thousands of concurrent connections no problems. Plus these days people slap a CDN in front anyway so static file performance doesn’t matter quite as much.
Ye pretty much. I was just quite astounded at that statement as the AI Horde is basically just a lot of python processes behind a very low powered haproxy server.
Personally, I understand people like to stay with the familiar, which is perfectly fine for a non-demanding service, but when something becomes demanding, I find the haproxy specialization serves better. I wish lemmy deployment by default utilized haproxy myself.
Because pingora doesn’t have a Nixos package yet
This is it for me. I used to use caddy a few years ago because writing config files was a breeze. Now I “use” nginx because I can define everything in a few lines of nix and it’s configured automagically for me.
Yeah I love that about nix and I can imagine a clever package writer can make a pingora binary to mimic that configurabllity
IIUC pingora is not standalone, but a set of rust crates? Should be already supported by nixpkgs through rust builders.
Yep it would need to be compiled from the configuration given. I’m vaguely interested in trying. I will look up the rust builders. Thank you
Some people are also building a reverse proxy using pingora called river.
Would that lack the performance benefits that pingora provides by being compiled without configuration file?
I mean pingora out performs nginx which is why cloud flare made it, I believe
