Thanks for the detailed post. This is interesting! If I understand correctly, you have several working configs, and a few that don’t work, and the crux of your question is:
but still not sure why some of the ways don’t work properly, and what is the best way.
There’s a few things I will point you to that will help explain… Caddyfile 101, so to speak.
-
In order to keep the Caddyfile easy to write, handler directives have a default order that is sensible for most configs: Caddyfile Directives — Caddy Documentation (you can change the order either by using global options or by defining routes manually)
-
You should run
caddy adapton your configs to see the resulting JSON. You will be able to quickly and clearly see what the actual handler chains look like. -
Read this wiki article for advanced understanding of composing handlers using the Caddyfile:
Ultimately, as long as a config works for you, I would say it boils down to preference. You can look at the resulting JSON config and see if any of those make more sense under the hood.
You might even be able to simplify your config a little more. Your “default” or “fallback” proxy doesn’t necessarily need to explicitly exclude the other ones. Proxying is a terminal handler, meaning future handlers won’t be called (because a proxy handles the request by responding to it), so you can assume that later proxies won’t be called if earlier ones are. That means you can probably remove matchers like @website path not /ajax-googleapis/* /aws-cdn/* kind of like you did on your last attempts.
Does that all make sense?