V2 - adapt `unrecognized directive: proxy` - moving from Caddy v1

Help
1

Is the it expected for Caddy v2 to error with adapt: Caddyfile:2: unrecognized directive: proxy for the following Caddyfile?

http://127.0.0.1 {
	proxy / http://127.0.0.1:81
}

./caddy2-dev adapt --config ./Caddyfile-test-proxy --adapter caddyfile --pretty

I’m attempting to get a Caddyfile from v1 over to v2 but stumbling at the first hurdle here.

Is proxy supported in the adapt command currently?
Is there a new Caddyfile format for v2 that I missed somewhere in the beta docs perhaps?

I’m using a built from source version of Caddy v2.

1 Like
2

Thank you for trying Caddy 2!

The v2 directive is reverse_proxy: Home · caddyserver/caddy Wiki · GitHub

… so as to distinguish between possible other proxy types (namely a forward proxy, as proxy itself is ambiguous).

2 Likes
3

I’ve been running through one by one - working on getting my Caddyfile v1 converted over to a Caddyfile v2 - still working on it…

So far the following additional Caddyfile v1 directives don’t seem to be supported by Caddyfile v2 beta (yet):

Obviously there may be more by the end - but thought I would put these out there.

I can (short term) disable logging, and script the replacement of snippets.

1 Like
4

Right, thanks for bringing that up, although… I’m surprised snippets don’t work. I forgot to test those, I’ll take a look.

We’ll have a guide for moving a Caddyfile from v1 to v2. I expect that for most people, with this guide, it shouldn’t take more than a few minutes.

And yes we’ll have logging and error handling in the Caddyfile again :slight_smile:

1 Like
5
  • http.status looks like it has changed to respond in v2
  • proxy / reverse_proxy - there is also the subdirective changes:
    • header_upstream / header_up etc.
    • transparent preset - doesn’t seem to exist so long hand via header_up
  • header / headers
  • tls > ask - doesn’t appear to be ask support (in Caddyfile V2, but mentioned in V2 config structure)
  • basicauth - not supported - not a big deal as I can drop those pages from serving.
  • root - Error during parsing: Wrong argument count with single parameter despite documentation look like the 1st parameter is optional “root [<matcher>] <path>”

Pretty sure I can script “Caddyfile v1” > “Caddyfile v2” > “Caddy v2 JSON Config” and then manipulate that to add ask functionality.

1 Like
6

Thank you for sharing this! That’s definitely a good start to a transition guide.

Everything looks right that you said, but I’ll add comments to or clarify a few things.

You’re right, but it will have Caddyfile support soon, just need to get around to it. (Or get a contribution to speed things along)

I might be able to get this up this week.

Ah, this is a bit tricky. The documentation is right – with one nuance. A matcher token, as documented in the wiki, is of one of the three forms:

  • * for all requests
  • a request path, starting with /
  • match:name to specify a complex matcher by name

Since the root directive’s argument is itself a path, on Unix systems it looks like a matcher token; i.e. /var/www is indistinguishable from a matcher token. So you need root * /var/www to capture all requests and make it clear that the path is for the root path, not the request path.

1 Like
7

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