This works fine, but Caddy will never serve the files because the reverse proxy matches everything. Is there a way to try the file server first, or do I have to write matchers for the reverse_proxy?
That’s right – the file server and the reverse proxy are both terminal handlers, meaning they don’t invoke the next handler in the chain if they both match a request, and the reverse proxy is coded to come first by default when using the Caddyfile.
Right now, they match all requests (because all request paths start with /). When do you want the file server to be used instead? Caddy doesn’t know what you want to do since you told it to use both the file server and the reverse proxy for all requests, so it just picked the reverse proxy to go first.
You have a couple options off the bat:
You can restrict either the file server or the reverse proxy to match only certain requests.
You can change the order of the directives, using handler_order option in the global config: Home · caddyserver/caddy Wiki · GitHub – you can change the order to that of appearance in the Caddyfile or hard-code your own order for the directives.
Option 1 will tell Caddy to use the file server or the reverse proxy depending on the request, whereas option 2 (without any other changes) will let you tell Caddy to use the file server instead of the reverse proxy when they both match the same request; but that makes having both in the Caddyfile redundant still.
So I think what you want to do is tell Caddy to use one or the other depending on the request, not to use both for all requests (because it can only use 1). Does that make sense?
That makes sense, thanks for the info. I think it would be awesome if the caddy fileserver would take priority for requests that match files in the root, and then hand off to the reverse proxy for those that don’t.
Here’s the matcher that I came up with for avoiding static assets with a webpacker rails app in case anyone else needs it
With this configuration, the try_files option for the file matcher will match the request if any of the given files exist. So it simply tries the request path within the root you specified, and if it doesn’t exist, it will not match – but since we’re in a “not” matcher, it negates that and will match!
So you can use that with the reverse proxy, without needing to specify each static file.