Help with caddy v2 config

I have trouble with writting a v2 Caddyfile that is equivalent to v1 Caddyfile

v1 Caddyfile is as follow:

(snippet) {
        tls cert.pem privkey.pem
}

https://func1.example.com {

import snippet 
    gzip
    timeouts none
    proxy / https://google.com {
        except /xxx
    }
    proxy /xxx 127.0.0.1:12312 {
        without /xxx
        websocket
    }
}

My v2 Caddyfile is not valid. I’d like some help.

(snippet) {
        tls cert.pem privkey.pem
}

https://func1.example.com {
	import snippet
	
	reverse_proxy / https://google.com

    reverse_proxy /xxx 127.0.0.1:12312{
        #  send request URI without prefix /xxx to backend (127.0.0.1:12312)
        uri strip_prefix /xxx 
    }
}

Hi @silentred,

There’s a few built-in tools to help you sort issues like this out.

I can spot two major issues at a glance, but here’s how you could find them:

  • caddy fmt: can help with spacing, bracing, and indenting for readability
  • caddy validate: loads the config, reports any errors it found, and then exits

Slapping your Caddyfile down and running caddy validate gives me this:

➜ caddy validate
2021/07/25 07:36:07.188 INFO    using adjacent Caddyfile
validate: adapting config using caddyfile: subject does not qualify for certificate: '}'

Looks like there’s an issue with the braces in particular. This is pretty much always the result of a mismatch.

I ran caddy fmt on it:

➜ caddy fmt --overwrite

➜ cat Caddyfile
(snippet) {
        tls cert.pem privkey.pem
}

https://func1.example.com {
        import snippet

        reverse_proxy / https://google.com

        reverse_proxy /xxx 127.0.0.1:12312 {
                #  send request URI without prefix /xxx to backend (127.0.0.1:12312)
                uri strip_prefix /xxx
        }
}

➜ caddy validate
2021/07/25 07:37:23.079 INFO    using adjacent Caddyfile
validate: adapting config using caddyfile: parsing caddyfile tokens for 'reverse_proxy': Caddyfile:12 - Error during parsing: unrecognized subdirective uri

So it looks like the brace problem is no longer a problem! (Can you see where caddy fmt added a space immediately after the reverse_proxy /xxx 127.0.0.1:12312 line? This was causing Caddy to interpret that brace as part of the upstream server, resulting in a mismatched brace.)

But now we’ve got unrecognized subdirective uri.

This one’s easy to solve: uri isn’t a subdirective of reverse_proxy, it’s its own directive. It has to be separate, it can’t be in a brace block.

To strip a prefix before reverse proxying, the easiest way is in a route - for example:

  route /example {
    uri strip_prefix /example
    reverse_proxy upstream
  }

Or using the handle_path directive, which implicitly strips the prefix as part of the operation:

  handle_path /example {
    reverse_proxy upstream
  }

Command Line — Caddy Documentation
uri (Caddyfile directive) — Caddy Documentation
reverse_proxy (Caddyfile directive) — Caddy Documentation
route (Caddyfile directive) — Caddy Documentation
handle_path (Caddyfile directive) — Caddy Documentation

2 Likes

Also, note that path matching is exact in Caddy v2, so /foo matches only exactly /foo and not /foo/bar. You must use a * as a suffix to tell Caddy to match the rest, like this: /foo*. See the matcher docs for full details:

2 Likes

@Whitestrake @francislavoie Thank you. I have figured out it.

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