Api Multiple backends URI No working

I have the following configuration that proxies back to a node application

proxy / {
        proxy_header Host {host}
        proxy_header X-Real-IP {remote}


proxy /c/ {
        proxy_header Host {host}
        proxy_header X-Real-IP {remote}


tls {
        max_certs 10
log stdout
errors stdout

When i try 国产高清亚洲精品视频 国产福利视频在线精品 97国产免费最新视频# it goes to the first backend .(proxy /

Any ideas what might be wrong

So I flip the uri order in the Caddyfile and now it seems to work.

Thanks for the question.

This behavior is intentional, but we will probably change it before too long. There was already an attempt to do so but we will probably need to revive that effort, since a lot has changed since then; at the time we weren’t in a place to merge in the change.

Right now, the more specific proxy path needs to be first; since proxy chooses the first one that matches, instead of the longest. We’ve since decided there is no reason a user would want anything other than that, so expect that to be improved in a future version!

1 Like

First match is a logic that is easy to understand; I would like to see a warning during startup if there is a longer / more specific match that is masked through ordering rather than a more complex matching logic that makes it hard to understand what to expect.

(As an aside, puppet did switch from “random” ordering to declaration ordering – they call it manifest order – because the previous one was so hard to get right with a growing configuration base that everyone started writing code that was completely explicitly ordered, adding syntactic overhead. This is a somewhat weak argument because a configuration management system is much more complex than a web server, but seeing how people use the web server to work around limitations in their web apps, the difference my not be as big as I am assuming).

There was a PR to make Caddy’s proxy choose the longest matching path, about a year ago: https://github.com/mholt/caddy/pull/114

I finally decided to accept the change today. So if two rules are defined in this order, / and /a, /a will still be used if it matches. I wish I accepted this change a year ago, but I’m learning and will carry that forward now.

The explicit ordering is definitely good as far as simplicity goes, and I can see why puppet made the switch to declaration order, but:

This is a somewhat weak argument because a configuration management system is much more complex than a web server

I disagree that a web server is much less complex than a config management system. A web server has to manage its config, after all. :wink:

Anyway, hope this change is useful.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.