The need for a configuration file analyzer is a good sign your software is overly complex and poorly architected.
Configuration files should be self-documenting.
Instead nginx taught us that if != if.
Configuration files should be self-documenting.
Instead nginx taught us that if != if.
add_header inheritance is counterintuitive bot once you know how it works it should not be a problem. Another problematic directive is "if" - AFAIK Igor (nginx creator) designed config to be declarative but had to add "if" (imperative directive) after numerous feature requests and "if" didn't fit existing architecture well.
I'd call it's configuration way less intuitive than the one of ngnix (and I wouldn't call myself a great enjoyer of ngnix configuration).
No doubts I'm not an expert in Caddy and there are some chances it has unique selling proposition, but I'm yet to find it.
My take on Caddy was - something to let your quickly-crafted-something-newshiny-loneley-dev-docker-container-to-be-available-to-the-world - sort of the same case if I do some tests (we call it MVP here) on my great-idea Flask app and I need plain reverse proxy in front of it with SSL termination, as noone except me and may be couple of Shodan bots won't see.
Yet not mentioned unclear stable releases policy for Caddy.
In fact, I'd argue that learning not to use them unless they're absolutely necessary is a good lesson on the importance of keeping things simple. When I was a beginner to web servers, I spent quite a few hours wrangling nginx configs trying to do things like fancy conditional redirects, removing .php extensions from pages, etc.. But over the years I've slowly learned that most of this logic belongs in application code, not in nginx, and nowadays I can set up a new nginx server in minutes because the configuration format is actually quite simple and intuitive once you understand what you really need, and what you should leave out or implement elsewhere.