Caddy suddenly directs my site to the wrong directive

Help
1

1. Caddy version (caddy version):

v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

Installed with xcaddy build --with github.com/caddyserver/forwardproxy@caddy2=github.com/klzgrad/forwardproxy@naive.

2. How I run Caddy:

caddy run --config ~/Caddyfile

a. System environment:

Ubuntu 18.04.5 LTS

d. My complete Caddyfile or JSON config:

#
# noise here to stop emacs from thinking this is C code
{
# auto_https off
  # auto_https disable_redirects
}

files.zii.lilf.ir {
  encode zstd gzip
  file_server browse {
    root {env.HOME}/Downloads
  }
}

searx.zii.lilf.ir {
  encode zstd gzip
  reverse_proxy localhost:4004
}

mail2.lilf.ir {
respond "wtf5"
}

discourse.lilf.ir {
#  encode zstd gzip
reverse_proxy localhost:8011 #unix//sock/nginx.http.sock 
}

code.zii.lilf.ir {
  # encode zstd gzip
  reverse_proxy localhost:7451
}

v1.zii.lilf.ir, http://v1.zii.lilf.ir {

  reverse_proxy /shark 127.0.0.1:2001 {
        transport http {
            versions h2c
        }
  }

  file_server browse {
    root {env.HOME}/Downloads
  }

}

:443, np.zii.lilf.ir {
route {
  forward_proxy {
    basic_auth alice {$NP_PASS1}
    probe_resistance secret.com
    hide_ip
    hide_via
  }
  file_server browse {
    root {env.HOME}/Downloads
  }
  # respond "pained gold spots accumulated"
}
}

3. The problem I’m having:

As you see, accessing https://mail2.lilf.ir/ will use the last directive of :443 instead of the mail2.lilf.ir directive.

❯ curl mail2.lilf.ir
wtf5

❯ curl http://mail2.lilf.ir
wtf5

❯ curl https://mail2.lilf.ir
<!DOCTYPE html>
<html>
...

4. Error messages and/or full log output:

5. What I already tried:

I tried changing the config a bit. Removing mail2.lilf.ir will cause that address to not return anything. I also updated my caddy, but the problem was not solved. What is weird is that things used to work just fine, and I don’t remember having updated caddy before the breakage …

6. Links to relevant resources:

2

:joy:

Minor thing, but I recommend using the root directive instead, like this:

root * {env.HOME}/Downloads
file_server browse

This is because the root directive sets it site-wide, so if you need to add another directive that needs to be aware of root, it’ll already be ready for you. The root subdirective within file_server is typically meant for when you want to override the site-wide root for some reason.

You can do this instead:

reverse_proxy /shark h2c://127.0.0.1:2001

Just in case you weren’t aware, /shark will only match exactly /shark and not /shark/foo, because Caddy’s path matching is exact. Add a * to the end of the matcher to make it match other paths too.

Yeah, I see the problem – running caddy adapt on your config shows that the route with mail2.lilf.ir is after the one for :443. This looks like a bug with the Caddyfile adapter where site blocks with multiple sites including a catch-all will be sorted with the “power” of the longest hostname in that site. Fixing that bug might be kinda tricky.

The fix though is to split up your :443 and np.zii.lilf.ir into their own sites such that they each get handled separately. Doing that, the :443 site will get properly sorted to the end.

You can make use of Caddyfile snippets to avoid duplication though, so you can have one snippet with the site contents that you import into both sites:

FYI @matt :point_up: bug with the site sorting :slightly_frowning_face:

2 Likes
3

Thanks, this worked. But considering it used to work, I’m afraid a proper fix is needed or it’ll inevitably regress in the future.

4

Yeah, unfortunately that’s one of the most finnicky parts of the codebase because the Caddyfile adapter tries to bend backwards to generate a JSON config that makes sense. JSON doesn’t have a concept of “sites”, it has servers (i.e. listen addresses like :443 and :80) and routes, so mapping Caddyfile sites onto those servers and sorting the routes correctly is tricky.

Thanks for reporting it though :+1:

2 Likes
5

Thanks; this should be fixed in:

@NightMachinary if you could please try it out to confirm, that’d be much appreciated!

3 Likes
6

This topic was automatically closed after 30 days. New replies are no longer allowed.