Why do so many people use NGINX?
Why do so many people use NGINX?
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?
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 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.
It just works and it's in every distros default repo, it's pretty easy to set up and can be a webserver for static files, PHP sites, etc.. It can be a reverse proxy for HTTP(s) traffic or just forward TCP/UDP.
There's also endless documentation out there for how to do something in nginx.
HAProxy is a nightmare to use in my experience. It just feels so clunky and old.
Caddy is nice, but downloading and updating it is a pain because you need modules that aren't included in the repo version.
Right there with you on “just works,” as well as the simple fact that the config snippets you need are readily available - either in the repo of whatever you’re putting behind the proxy, or elsewhere on the internet.
I consistently keep in mind that it’s ultimately an RU product, of course. But since it’s open source and changes relatively infrequently, that’s mitigated to a large degree from where I sit.
Nothing against Caddy, though Apache gets heavy quickly from a maintenance standpoint, IMHO. But nginx has been my go to for many, many years per the above. It drops into oddball environments without having to rip and tear existing systems out by the roots, and it doesn’t care what’s behind it.
Ages ago, I had a Tomcat app that happened to be supported indirectly by an embedded Jetty (?) app that didn’t properly support SSL certs in a sane way on its own.
That was just fine to nginx and certbot, the little-but-important Jetty app just lived off to the side and functionally didn’t matter because with nginx and certbot, nothing else gave a crap - including the browser clients and the arcane build system that depended on that random Jetty app.
Nginx is owned by F5 now which is an American company so it's not RU anymore
HAproxy cannot serve static files directly. You need a webserver behind it for that.
Apache is slow.
Nginx is both a capable, fast reverse-proxy, and a capable, fast webserver. It can do everything HAproxy does, and what Apache does, and more.
I am not saying it is absolutely best for every use-case, but this flexibility is a large part of why I use it in my infra (nad have been using it for a decade).
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.
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.
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.
It's easy to use, reliable, and doubles as a webserver so I only need one software to host my websites and also do the reverse proxying to the other webservices.
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 :)
Honest question: why not use nginx?
I have run it in so many different scenarios, both professionally and personally, its crazy. Nginx has never failed me, literally. My homeserver is quite limited but nginx has a very small footprint, it performs beautifully well and it satisfies all my hosting, proxying, redirecting and streaming needs.
It works for modern and legacy applications, custom code, webhosting, supports all the modern features and its configuration is very easy with literal thousandsof examples available online.
Apache probably can do all that but I hate how unintuitive its configuration is to me personally. HAproxy cant do half the stuff nginx does.
As for caddy Ive heard of it but never really used it. What does it offer that nginx doesnt?
What does it offer that nginx doesnt?
Automatic HTTPS, you don't have to use certbot or something similar to get/renew certificates. Also, its configuration is really simple and straight forward.
Thank you for your reply!
Personally I am fine with nginx configuration, at least when using containers. The syntax is fine and all I need to do is map one file into the container
But I took a look at the automatic cert feature and wow, that is very, very nice. I may give caddy a try for this feature only - it would simplify my current setup.
I am also surprised it allows using HTTPS over port 443 for cert renewal. I didnt even know this was possible, so I was always stuck with DNS challanges.
So again, thanks for your reply!
The only time I use caddy is to serve static files... I then put a nginx proxy in front of it to expose it lol
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.
When NGINX showed up it beat the then dominant apache on resource utilzation hands-down.
It's also very configurable and has a lot of modules, both in-house and third party.
The only downside for me: as of late the whole commercial part of the project has been gobbling up everything to shove the non-free version to the point where it's hard to find info on the free version, e.g., the wiki page that lists all the third-party modules. The nginxtutorials site seems to be a good resource.
Btw one of the main devs forked it into freenginx:
Dounin writes in his announcement that "new non-technical management" at F5 "recently decided that they know better how to run open source projects. In particular, they decided to interfere with security policy nginx uses for years, ignoring both the policy and developers' position." While it was "quite understandable," given their ownership, Dounin wrote that it means he was "no longer able to control which changes are made in nginx," hence his departure and fork.
Also, fun fact: this is probably the only instance of russian software muricans don't cry Commie! all the time (maybe because the parent company was acquired).
Because everyone told me to
- simple config & setup
- good performance
- popular/packaged by every single distro
- just works
Security
Caddy is good but it tried to do to much. This means that security bugs could be way more common. It has been audited by outside people and the issues they found were fixed but I am will very doubtful that it is secure yet
I think security is a fair point, given caddy's younger age compared to nginx, but I wouldn't say it tried to do too much.
I think a large factor is because so many people use it. A lot of people come to self hosting without much knowledge and just copy configs etc. from a Tutorial. Those tutorials will 90% of the time use Apache or nginx. I remember back when I set up my first servers I mostly followed instructions and copied configs. Years later I understood I had set up Apache with virtual hosts and what that means/how it works but it might as well just have been nginx.
As for why so many people use these two I think it also has to do with "adoption" in another way. Back before nginx Apache was the standard everything else was "different". Then nginx appeared to solve the Problems of Apache and then there were 2 ... These days you can probably do anything you want/need with the 2 servers so no reason to use anything else.
Professionaly I usually use either HAProxy and Apache or Nginx (or sometimes HAProxy and Nginx) but if there are special requirements that might change.
I came to MySQL and Apache because they were the backend for other services I wanted to start,. Later, when I wanted to build my own, I already had Apache running, so why would I add nginx? I did let other services add sqlite, but have (in most cases) figured out how to switch those to MySQL.
All of that has been running for 20 years. I'm sure it would be good for my dementia-risk to learn how to start ngnix and migrate all those services, but it's far more attractive not to mess with what works.
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.
Traefik + CrowdSec + Authelia ftw
Traefik gang here 👊 !
But only because it works so easily with docker !! I remember a time where I though that you need a diploma and read/learn/understand a 10000 page dictionary to make nginx work properly.
Also hated the syntax of nginx... It can look so ugly and gibberish :/.
But I do believe Nginx is superior and more mature in many more aspects than Treafik. Still, Traefik is a breeze and is in IMO way easier to configure with docker than Nginx.
I use Traefik as my main reverse proxy as well for the same reason—container niceties. But then I actually also use nginx.. inside container images, like for containers that just serve static files for example.
Use the right tool for the job!
Yeah it's Traefik for me as well! Heavy docker user, of course - it's nice just tossing some labels into my Portainer stacks and letting Traefik figure it out. If I wasn't so invested with containers I'd be using nginx.
I used to use traefik back when it was new and less complex and the 2.0 complexity forced my hand to drop it for my homelab.
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.
Counter question: Why does everyone call it "engine X" and not "enjinx", which would be the way cooler pronunciation?
Directly from the nginx home page:
nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev.
I call it N Jinx. Always have and I’ll never be convinced otherwise that it’s not.
oh I've only ever read it, never heard it pronounced, do people really pronounce it engine X?
That is the way it’s pronounced, yes.
Huh. That is way cooler
It's actually n-jynx duh
I always did? A friend pointed out to me once the "correct" pronunciation. I like this way more.
I always said "in GIN icks" (gin like the alcohol) based on someone else's pronunciation years ago. I never realized it was meant to have anything to do with "engine" as a result.
@selfhosted @Findmysec what is the problem with nginx? 🤔
Why not? Why should I use Apache instead of Nginx? I don't know about Caddy, Nginx is simple enough not to care about simpler solutions. But in general, I know Nginx and it does the job.
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.
Caddy's developer gives me the ick. He's way too pompous in PRs on GH. nginx is just a constant -- it does exactly what you need to and does it well.
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.
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.
Caddy certainly was the easier option but it's as complex as nginx now and id argue it's hard to to use.
Why do you say that?
I've used both plenty and only once I thought Caddy was harder: caching. It requires you to install a plugin that also doesn't have the easiest of configs. I think there's a new and simpler one nowadays, but haven't tried it yet.
I now use Caddy by default for everything new I make/host.
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.
Nginx scales better than Apache does for static content and proxying, so it started to take over market share.
A home gamer handling a handful of users is unlikely to ever notice a difference.
But the configuration for nginx is simpler nout of the box for most things which is probably the real reason people use it at home.
TLDR: probably a lot of people continue using the thing that they know if it just works as long as it works well enough not to be a bother.
Many many years ago when I learned, I think the only ones I found were Apache and IIS. I had a Mac at the time which came pre installed with Apache2, so I learned Apache2 and got okay at it. While by release dates Nginx and HAProxy most definitely existed, I don't think I came across either in my research. I don't have any notes from the time because I didn't take any because I was in high school.
When I started Linux things, I kept using Apache for a while because I knew it. Found Nginx, learned it in a snap because the config is more natural language and hierarchical than Apache's XMLish monstrosity. Then for the next decade I kept using Nginx whenever I needed a webserver fast because I knew it would work with minimal tinkering.
Now, as of a few years ago, I knew that haproxy, caddy, and traefik all existed. I even tried out Caddy on my homelab reverse proxy server (which has about a dozen applications routed through it), and the first few sites were easy - just let the auto-LetsEncrypt do its job - but once I got to the sites that needed manual TLS (I have both an internal CA and utilize Cloudflare' origin HTTPS cert), and other special config, Caddy started becoming as cumbersome as my Nginx conf.d directory. At the time, I also didn't have a way to get software updates easily on my then-CentOS 7 server, so Caddy was okay-enough, but it was back to Nginx with me because it was comparatively easier to manage.
HAProxy is something I've added to my repertoire more recently. It took me quite a while and lots of trial and error to figure out the config syntax which is quite different from anything I'd used before (except maybe kinda like Squid, which I had learned not a year prior...), but once it clicked, it clicked. Now I have an internal high availability (+keepalived) load balancer than can handle so many backend servers and do wildcard TLS termination and validate backend TLS certs. I even got LDAP and LDAPS load balancing to AD working on that for services like Gitea that don't behave well when there's more than one LDAPS backend server.
So, at some point I'll get around to converting that everything reverse proxy to HAProxy. But I'll probably need to deploy another VM or two because the existing one also has a static web server and I've been meaning to break up that server's roles anyways (long ago, it was my everything server before I used VMs).
Thanks for the comment, that was a good read
I'll probably look into newer fancier options such as Caddy one day, but as far as I remember Nginx has never failed me : it's stable, battle tested, and extremely mature. I can't remember a single time when I've been affected by a breaking change (I could not even find one by searching changelogs) and the feature set makes it very versatile. Newer alternatives seem really interesting, but it seems to me they have quite frequent breaking changes and are not as feature rich.
That being said, I'd love to see side-by-side comparison of Nginx and Caddy configs (if anyone wants to translate to Caddy the Nginx caching proxy for OSM I shared earlier this week, that would make a good and useful example), as well as examples of features missing from Nginx. This may give me enough motivation to actually try Caddy :)
(edit : ad->and)
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.
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]
What about envoy proxy?
Nothing else on the market has as low latency implications to workloads that I am aware of.
I have heard a lot about Envoy proxy from Istio but never looked into it for baremetal usage. I'll keep an eye out, thanks
I was coming from Lighttpd which at the time had a very similar config syntax to Nginx. It was pretty much a no brainer, considering I wanted to shift to an automated Letsencrypt renewal process at the same time.
Sadly I wrote some python web services for CGI (not django/flask) that cannot be run anymore, since NGINX only supports FCGI, rather than just CGI as far as I can tell
fcgiwrap is what you want for CGI in nginx.
First time hearing of this! Thank you 😁
Me personally, as a newb regarding proxy and homelab, I use nginx because it was super easy to set up (proxmox script) there were many tutorials available and it just works great. I had to debug some things and this also worked great, so just a perfect package.
Nginx "just works(tm)" had never got into the way, its been rock solid and has not changed significantly over the years.
Why would I need something else?
There's a lot of good resources for Nginx, it's fast (faster than Caddy), and has a ton of features, so you can use it for pretty much anything HAProxy, Apache, or Caddy can do, and not sacrifice much in performance.
That said, I mostly use HAProxy and Caddy. Here's my basic setup:
- HAProxy at the edge VPS - routes requests to machines based on SNI
- WireGuard VPN - connects my internal devices to my VPS
- Caddy in Docker - runs on internal network on my NAS/homelab - manages LetsEncrypt renewals and reverse proxies to internal Docker network
- Nginx in Docker - FE for NextCloud; this simplifies things so all my TLS is handled in one place, and Caddy doesn't need to touch files
I use a local DNS server on my router so my domains can route directly to Caddy instead of going over the internet when on my network, otherwise I may just have HAProxy handle LetsEncrypt certificates.
From what I can tell, Nginx is a little more efficient than Caddy, but Caddy is plenty fast for my needs. I'm considering switching from NextCloud to the new ownCloud Infinite Scale, and if I do, I'd ditch nginx completely.
Nginx was the easiest to setup for me at the time and I've no reason to fix what isn't broken.
I learned nginx when I was hosting websites. I had it set up and running when it was time to add reverse proxies into my setup. It didn't take much more from the virtual hosts I was already using.
Now, I don't host many individual sites anymore and haproxy has a plugin on my firewall for the handful of services I run now.
I use Traefik because it solved a problem with the static configuration approach which Nginx had / still has.
In a scenario with multiple services behind Nginx, taking one down or replacing an instance is massive headache. I tried to script around it, but basically the Nginx container would choke on the fact that a service does not [yet / anymore] exist, and together with the docker networking stack it turned out to be an insurmountable problem.
Traefik otoh discovers services based on (in my case) labels on the docker containers running locally. And then updates the configuration on the fly.
Basically the static approach to configuration resulted in massive headache when I needed to enable zero downtime deployments and updates behind Nginx. And Traefik handled it perfectly without dropping a single request.
Nowadays I manage my dynamic configuration with ansible and update the values in for the file-based configuration provider with a playbook. I don't need a UI to manage my inventory, I use ansible for that. Traefik handles the rest perfectly.
Completely agree, which is why I do the same.
Additional bonus: proxies that interact with the docker API directly (I think also caddy can do it) save you from exposing the services on any port at all (only in the docker network). So it's way less likely to expose a port with a service by mistake and no need for arbitrary and unique localhost ports.
Because modsec.
The only reason that I tend to use it is because of the included webserver. It's not bad but the paywalling of functionality needed for it to be a proper LB left a bad taste in my mouth. That and HAProxy blows out of the water in all tests that I've done over the years where availability is at all a concern. HAProxy also is much more useful when routing TCP.
I use nginx & docker-proxy. Because the model I copied used that setup. Having messed with it a bit, I’m understanding it more and more. Before that, the last time I messed with a web server (Apache), nginx wasn’t around. Lately, I’ve seen a similar docker setup to mine that doesn’t use docker-proxy. If I find time, I’ll probably play with that some on my dev rig.
As a security professional, what finally got me to move from Apache to NGINX was OpenResty.
I sometimes still put Apache behind it, depending on my goals.
Often I already have nginx running for serving some static content anyway.
Otherwise, I’m traefik all the way.
@Findmysec
Contrary to most, I never made the Apache-to-nginx switch. I actually don't find nginx that much easier to configure, so the effort of rewriting all my templates was too high.Caddy is a different story. I can replace swathes of configuration lines with just two? And get letsencrypt automatically without having to give it a single thought? Gimme!
Indeed, I don't find NGINX that easy to configure either
I'm reminded of this blog/article on Ars about ripping out OLS and reverting to NGINX. There's some good info there, and also links to other of his posts on the subject and references. Good read.
**
**
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.