V2: reverse-proxy transparent

1. My Caddy version (caddy -version):

v2.0.0-beta9 h1:oILdAOfunJ4ijBN9kOWjFIeH8EufBX/N1pC9HbnwjzU=

2. How I run Caddy:

Please provide all of the relevant information and DO NOT REDACT anything except passwords/keys. Thank you!

a. System environment:

OS, relevant versions, systemd? docker? etc.

CentOS 7 amd64

b. Command:

$ caddy start --config Caddyfile --adapter caddyfile

c. Service/unit/compose file:

Not used

d. My complete Caddyfile:

unknwon.dev {
    reverse_proxy * localhost:4333 {
        transparent
    }
}

3. The problem I’m having:

Please describe the issue thoroughly enough so that anyone can reproduce the exact behavior you’re seeing. Be as specific as possible.

In v1, the transparent subdirective would work, but I can’t find anything similar in v2 docs.

4. Error messages and/or full log output:

reload: adapting config using caddyfile: parsing caddyfile tokens for 'reverse_proxy': /etc/caddy/Caddyfile:23 - Error during parsing: unrecognized subdirective transparent

5. What I already tried:

Read through Home · caddyserver/caddy Wiki · GitHub.

6. Links to relevant resources:

Hi @Unknwon, the error Caddy has output:

This is because there is no transparent preset for v2’s reverse_proxy directive.

For any headers your upstream requires, you will need to add them manually with the header_up subdirective.

GitHub - caddyserver/caddy: Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

Edit: This thread is from early in Caddy 2’s beta cycle, before it was even released. Caddy 2’s default behavior is to pass all headers through to the backend without modification, including setting/augmenting the X-Forwarded-For header for you. Basically, in Caddy 2, “transparent” is the default mode of operation. You do not need to set the headers like you did in v1 unless your backend app has specific/unconventional requirements.

References:

1 Like

Thanks!

The remote IP is basically all I want… :cry:

There might be one as yet undocumented. Once I find it, I’ll edit the post and let you know.

1 Like

@Unknwon, could you try with {http.request.remote} and let me know if that works?

(see: caddy/replacer.go at 7ff02f37b6cbdf8e73a47d94604672ca2f1f1aa7 · caddyserver/caddy · GitHub)

SSHing to my server…

It works! Thank you :smiley:

1 Like

Yeah, before we reach 2.0 stable I’ll be sure to go back and add more shorthand placeholders for the Caddyfile. Right now you have to use their full name for some of them.

Edit: To clarify, for anyone finding this later: there is no “transparent” preset in Caddy 2 because Caddy 2 passes the Host header thru by default already. It also adds X-Forwarded-For automatically. If you need any other headers set, you can do so with header_up.

1 Like

Somewhat related question: can Caddy reverse proxy to the backend app using HTTP/2, or does it always convert to HTTP/1.1 like Nginx?

I’m asking having read this.

It can use HTTP/2, but HTTP/2 requires HTTPS, so make sure to enable HTTPS to your backends. In your HTTP transport, define at least: "tls": {} (or for the Caddyfile, use the tls subdirective in your HTTP transport.)

1 Like

Moderator edit: This thread got a lot of hits but contains outdated information from very early in the beta cycle of Caddy v2. It has been removed here to avoid confusing searchers. Please refer to current documentation instead:

3 Likes

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