I have multiple VPS servers (let’s call them Server A and Server B). I’m using an authentication middleware with forward_auth to enable both username/password and OAuth-based login. This setup works flawlessly on Server A for a site like app1.{$DOMAIN}, using the Caddyfile configuration below.
However, when setting up the same on Server B, I encountered an issue. In the tinyauth_forwarder snippet, I replaced the local address tinyauth:3000 with the external FQDN auth.{$DOMAIN} so that Server B can communicate with the authentication service running on Server A.
The problem is that Caddy on Server B doesn’t seem to trust the forwarded headers. When making API requests to the tinyauth service, the original X-Forwarded-* headers from the actual app are being overwritten by those from the reverse proxy instead.
From what I understand, this could be resolved by configuring trusted proxies in Caddy to ensure it properly preserves the forwarding headers. However, I haven’t been able to get that working. I’ve attached the relevant Caddyfile configuration and documentation links for reference.
2. Caddy version:
2.10.0
3. How I installed and ran Caddy:
OS - Ubuntu 24.10, arm64
Caddy is running inside Docker with below Caddyfile
Could you clarify this a bit? I’m getting a little lost with “the actual app” and “the reverse proxy”. Just trying to understand which one you’re referring to in each case.
Caddy forward_auth → auth.{$DOMAIN} (tinyauth reverse proxy on Server A)
If auth succeeds → Caddy → app2:8080
When Server B’s Caddy makes the forward_auth request to auth.{$DOMAIN}, it’s going through Server A’s Caddy reverse proxy. This creates a chain:
Server B Caddy → Server A Caddy → tinyauth container
Server A’s Caddy is overwriting the X-Forwarded-* headers that Server B sent, so tinyauth sees Server A’s IP instead of the original client’s information. I need to ensure that Server A preserves the original headers
Thanks for the heads-up. I’ve added the following configuration to Server A’s Caddyfile. As for the other change you mentioned regarding entrypoints—that’s actually specific to Traefik (another reverse proxy), so no changes are needed within TinyAuth itself. Instead, we just need to replicate that configuration in Caddy.
When I visit app2.{$DOMAIN} in browser, it simply loads directly without getting redirected to tinyauth just like before. Here’s the curl -vL output of the same with my actual subdomain. app1.{$DOMAIN} from Server A correctly redirects to TinyAuth for authentication, then loads the app after login.