Question about conditionally setting Request headers

1. The problem I’m having:

Hello! I have a question about the headers.request.set functionality. I currently have this block (sorry it’s in TOML–it’s automagically converted to JSON at runtime):

[caddy.http.servers.https.routes.handle.headers.request.set]
Host = ["{http.request.host}"]
X-Real-IP = ["{http.request.remote.host}"]
X-Forwarded-For = ["{http.request.remote.host}"]
X-Forwarded-Proto = ["{http.request.scheme}"]

I am wondering if there’s any way to conditionally set X-Real-IP to Cloudfront-Viewer-Address, but if that header is not there, use {http.request.remote.host} as a default?

I did see handler.headers.replace, but I think that does a wholesale replacement–not a conditional replacement?

2. Error messages and/or full log output:

N/A

3. Caddy version:

2.7.5

4. How I installed and ran Caddy:

N/A

a. System environment:

N/A

b. Command:

N/A

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

N/A

5. Links to relevant resources:

N/A

You don’t need any of those headers. Caddy’s reverse_proxy sets the appropriate proxy headers automatically. See reverse_proxy (Caddyfile directive) — Caddy Documentation (Caddyfile docs, but also applies to JSON).

Also if you have Cloudflare in front of Caddy, you should configure trusted_proxies (http server config), you can use GitHub - WeidiDeng/caddy-cloudflare-ip to automate loading Cloudflare’s IP ranges to trust those, and you can configure client_ip_headers to Cf-Connecting-Ip which is the header Cloudflare uses to pass through the original client IP.

1 Like

You don’t need any of those headers. Caddy’s reverse_proxy sets the appropriate proxy headers automatically. See reverse_proxy (Caddyfile directive) — Caddy Documentation (Caddyfile docs, but also applies to JSON).

I had to add those, or the real IP address of the connecting to client wasn’t reported correctly to upstream services (like WordPress). Are you saying I should remove the set statement I have, and they should already be set correctly?

Also if you have Cloudflare in front of Caddy, you should configure trusted_proxies (http server config), you can use GitHub - WeidiDeng/caddy-cloudflare-ip to automate loading Cloudflare’s IP ranges to trust those, and you can configure client_ip_headers to Cf-Connecting-Ip which is the header Cloudflare uses to pass through the original client IP.

I’m a little confused–I am using AWS Cloudfront in front of Caddy, should I use the Cloudflare IP ranges you mentioned for trusted_proxy settings?

Yes.

Wordpress can easily be configured to read the IP from X-Forwarded-For. Look into that. You don’t need to use X-Real-IP, it’s redundant.

Oh, sorry :man_facepalming: I read Cloudfront as Cloudflare, it’s so similar :grimacing:

Looks like Cloudfront publishes their IP lists here Locations and IP address ranges of CloudFront edge servers - Amazon CloudFront you could use those IP ranges or this plugin GitHub - xcaddyplugins/caddy-trusted-cloudfront: trusted_proxies cloudfront module for Caddy which automates it.

1 Like

Thank you for the info @francislavoie , I think this may come down to an issue with an intermediary proxy (Fabio) that is running on each Nomad server as another ingress layer (yes, I know it’s gross). I am going to simplify this approach eventually (by standardizing on a global Caddy deployment), at which point I think this issue will go away. Thank you!!

You have another proxy between Caddy and your apps? Then yeah make sure that proxy is configured correctly to pass through X-Forwarded-For and it would work fine.

1 Like