Need Help in CaddyFile for a Dynamic origin in reverse proxy

1. The problem I’m having:

2. Error messages and/or full log output:

Error: adapting config using caddyfile: parsing caddyfile tokens for 'reverse_proxy': /etc/caddy/Caddyfile:28 - Error during parsing: unrecognized subdirective header

3. Caddy version:

2.7.6 (Latest)

4. How I installed and ran Caddy:

a. System environment:

AWS EC2 Linux

d. My complete Caddy config:

    storage dynamodb test-caddy {
        aws_region us-east-1

:80 {
    respond /health "I'm healthy" 200

:443 {
    tls {

    @originHost {
        expression {} match ""

    reverse_proxy {
        header_up Host
        header_up User-Custom-Domain {host}
        header_up X-Forwarded-Port {server_port}
        header_up Access-Control-Allow-Methods "GET, POST, OPTIONS"
        header_up Access-Control-Allow-Headers "Content-Type"
        health_timeout 5s

        header Origin "" {
        header Origin {} {
            not @originHost

5. More Information in SameSite cookie:

How to handle the sameSite session with this reverse proxy? since if i login it redirects to same page again due to this lax. How to bypass this.

5. Links to relevant resources:

Let me the say if the origin i need its as, If it is apart from just the same origin in Access-Control-Allow-Origin:

You can replace this with header_up Host {upstream_hostport} which avoids needing to repeat the domain twice.

You don’t need this, Caddy already passes through the original domain as X-Forwarded-Host.

This is not useful information. Better to use X-Forwarded-Proto which Caddy already sets by default (which will always be https in your case anyway).

header is not valid inside of reverse_proxy. You have to use header_up to set headers on the upstream request.

The way I would do it is by setting vars using matchers, and then set the header using that variable.

@educrag host
vars @educrag origin ""
vars origin "https://{host}"

reverse_proxy ... {
	header_up Origin {vars.origin}

That said, I’m not sure I understand what you’re trying to do, because the “pseudocode” you have there is essentially tautological. If the host is then setting Origin to that value is the same as setting Origin to the host.

1 Like

Awesome i will work around it, Also i need that User-custom-domain need to unique to identify in my application.

Another Request in the same flow

Incorrect domain set in the Set-Cookie response

This attempt to set a cookie via a Set-Cookie header was blocked because its Domain attribute was invalid with regards to the current host URL.

How to handle this for cross-domain

with caddy anyway without touching the application settings?

As you know the domain won’t be the same with reverse proxy.

I’m confused by the way you worded things, sorry. Probably a language barrier issue. I’ll try to reply as I can but you might need to try again and clarify what you mean.

Why not just use X-Forwarded-Host in your app instead? It’s already available for you, no need to add a new custom header.

I’m not sure what you mean by this.

This sounds like a bug in your application, then. It be reading from X-Forwarded-Host to get the original domain name.

But maybe I’m not following the “flow” you’re talking about.

1 Like

I have a website, and i am using a reverse proxy from caddy to help manage incoming traffic for multiple domains. When someone tries to access my site through the reverse proxy’s domain (let’s call it, there’s an issue: the login process doesn’t work because the cookies needed for logging in are only set up for

If its logged in with other domain it throws an error in browser, so it just loops in the login screen.

How to handle this in caddy without touching the Main configuration in server.

In server this is the configuration which we cant change.

SESSION_COOKIE_NAME = ‘clsessionid’

Then this is a bug in your application, your app should not hard-code the domain for its cookies. You should fix that bug.

Why can’t you change it?

1 Like

Certainly! Its privacy guidelines for our application. We need to ensure that the completion of this reverse proxy project aligns with our privacy standards. Therefore, is there an alternative way to solve this issue using the Caddy configuration without violating our privacy guidelines?

If i remove that there are some clients who will move away from us thats the reason.

Huh? That doesn’t make sense.

All you need to do is change your application to check that incoming requests come from a trusted proxy (i.e. Caddy) by checking that the remote IP address is from a trusted list (e.g. private IP ranges), and if so you can trust that X-Forwarded-Host was not tampered with. Then you can use that header’s value in your cookie logic.

This approach is secure and good design.

1 Like

I dont know how this works, I am using network load balancer with caddy, and my main application run in AWS Elastic bean stack.

Any Reference to get the trusted IP from caddy or that should be done in AWS?

To clarify, I’m saying that your app should trust Caddy’s IP address, meaning that the IP address of the server you run Caddy on (or the range of IPs if you have many) should be added to your app’s config.

All you need to do is check the remote IP address on all incoming connections, and if it matches, then you know the request is coming from a trusted server.

Set that in whatever context in your app, and use that condition to decide whether to use X-Forwarded-Host or not.

Or you could just reject all incoming requests not coming from Caddy (respond with an error) if you want to make sure all requests go through Caddy.

1 Like

That’s where the problem arrives, Many external sites need to access our APP via API like Stripe, Lambda, and GCP cloud functions, etc. In that case, those triggers will be blocked if I restrict them via IP.

Okay, but:

You don’t have to block all requests, only change the cookie logic based on the IP.

1 Like

I am running Caddy in an NLB that only has a DNS name in common. We can’t set IP restrictions because it runs via an auto-scaling group, so the IPs are dynamic. Even so, how can I capture the remote IP address, which cannot be manipulated via a reverse proxy, in order to whitelist it in the app?

A different approach, you could set a header with a secret value that you can check in your app to confirm the request came from Caddy and nowhere else.

header_up Proxy-Secret some-secret-value-you-generate

This would let you avoid checking the remote IP if that’s not viable due to how you deploy.

1 Like

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