Redirect Issues when using Caddy on Azure

scott-david-walker · September 9, 2025, 3:46pm

1. The problem I’m having:

We run several static web apps on azure and we’d like to put a simple reverse proxy in front of them to redirect the traffic depending upon the url.
If I host this on my personal VPS then everything seems to work as expected but on Azure, it all changes. I’m running Caddy on an Azure Container Web App and I’m getting constant failures due to having too many redirects.

2. Error messages and/or full log output:

Too Many Redirects

3. Caddy version:

2.7

4. How I installed and ran Caddy:

Running via a docker file:


FROM caddy:2.7


COPY Caddyfile /etc/caddy/Caddyfile

a. System environment:

Azure App Container (Docker)

c. Service/unit/compose file:

FROM caddy:2.7
COPY Caddyfile /etc/caddy/Caddyfile

d. My complete Caddy config:

www.mydomain.com {
    reverse_proxy https://my-static-webapp.azurestaticapps.net {
    header_up Host my-static-webapp.azurestaticapps.net
    }
}

timelordx · September 9, 2025, 5:29pm

curl -kv https://yourwebsite

scott-david-walker · September 10, 2025, 7:42pm

Host www.mywebsite.com:443 was resolved.
IPv6: (none)
IPv4: my.ip.here
Trying my.ip.here:443…
Connected to www.mywebsite.com (my.ip.here) port 443
ALPN: curl offers h2,http/1.1
(304) (OUT), TLS handshake, Client hello (1):
(304) (IN), TLS handshake, Server hello (2):
(304) (OUT), TLS handshake, Client hello (1):
(304) (IN), TLS handshake, Server hello (2):
(304) (IN), TLS handshake, Unknown (8):
(304) (IN), TLS handshake, Certificate (11):
(304) (IN), TLS handshake, CERT verify (15):
(304) (IN), TLS handshake, Finished (20):
(304) (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
ALPN: server accepted http/1.1
Server certificate:
subject: CN=www.mywebsite.com
start date: Jul 22 00:00:00 2025 GMT
expire date: Jan 22 23:59:59 2026 GMT
issuer: C=US; O=DigiCert, Inc.; CN=GeoTrust Global TLS RSA4096 SHA256 2022 CA1
SSL certificate verify ok.
using HTTP/1.x

GET / HTTP/1.1
Host: www.mywebsite.com
User-Agent: curl/8.7.1
Accept: /

Request completely sent off
< HTTP/1.1 308 Permanent Redirect
< Content-Length: 0
< Date: Tue, 09 Sep 2025 18:16:01 GMT
< Server: Caddy
< Location: https://www.mywebsite.com/
<

Shows a permanent redirect. My guess is that Azure decides to route the traffic internally (not https) and Caddy tries to redirect to https. I’m fairly new to this though and am pretty stumped.

scott-david-walker · September 10, 2025, 7:45pm

Worthwhile to add that if I change the Caddy file from www.domain.com to :80 then everything works ok. Hence my thoughts about early TLS termination on the Azure container app.

timelordx · September 10, 2025, 10:25pm

It looks like something is standing in front of your Caddy (maybe Azure LB?) and then passing all the traffic to Caddy via HTTP rather than HTTPS port. Which makes Caddy respond with HTTP-to-HTTPS redirect.

If that’s the case, add this to your Caddyfile:

{
    auto_https disable_redirects
}

www.mydomain.com {
    reverse_proxy https://my-static-webapp.azurestaticapps.net {
    header_up Host my-static-webapp.azurestaticapps.net
    }
}

scott-david-walker · September 11, 2025, 7:19am

timelordx:

{
    auto_https disable_redirects
}

www.mydomain.com {
    reverse_proxy https://my-static-webapp.azurestaticapps.net {
    header_up Host my-static-webapp.azurestaticapps.net
    }
}

So this now results in a 502 error. I have it working if I do this without the disable_redirects and listening on 80 rather than a specific domain.
Why would this adding auto_https disable_redirects cause a 502?

:80 {
reverse_proxy https://my-static-webapp.azurestaticapps.net {
header_up Host my-static-webapp.azurestaticapps.net
}

}

scott-david-walker · September 11, 2025, 7:26am

Also adding the latest curl:

Trying my-ip:443…

Connected to www.mywebsite.com (my-ip) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
TLSv1.0 (OUT), TLS header, Certificate Status (22):
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS header, Certificate Status (22):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.2 (OUT), TLS header, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS header, Finished (20):
TLSv1.2 (IN), TLS header, Certificate Status (22):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS header, Supplemental data (23):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.2 (OUT), TLS header, Supplemental data (23):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
ALPN, server accepted to use http/1.1
Server certificate:
subject: CN=www.mywebsite.com
start date: Jul 22 00:00:00 2025 GMT
expire date: Jan 22 23:59:59 2026 GMT
issuer: C=US; O=DigiCert, Inc.; CN=GeoTrust Global TLS RSA4096 SHA256 2022 CA1
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
TLSv1.2 (OUT), TLS header, Supplemental data (23):

GET / HTTP/1.1
Host: www.mywebsite.com
User-Agent: curl/7.81.0
Accept: /

TLSv1.2 (IN), TLS header, Supplemental data (23):
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
TLSv1.2 (IN), TLS header, Supplemental data (23):
Mark bundle as not supporting multiuse
< HTTP/1.1 502 Bad Gateway
< Content-Length: 0
< Date: Thu, 11 Sep 2025 07:24:33 GMT
<
Connection #0 to host www.mywebsite.com left intact

timelordx · September 12, 2025, 2:15am

Without auto_https disable_redirects, Caddy creates an automatic HTTP listener. With that directive, I believe, it only creates HTTPS listener. Try this:

{
    auto_https disable_redirects
}

http://www.mydomain.com {
    reverse_proxy https://my-static-webapp.azurestaticapps.net {
    header_up Host my-static-webapp.azurestaticapps.net
    }
}

or just use your solution. That one is good too.

You need to check your Azure configuration. To me, it looks like you have Azure LB standing in front of Caddy. With you redacting your website and IP, I can’t say much. Everything is just a guesswork.

scott-david-walker · September 12, 2025, 7:53am

Adding the http in front seems to have solved my issue

I’m just using a managed container service. So I’m presuming that Azure has lb’s sitting in front of it but I have no control over that unfortunately.

Anyway, I appreciate your help and this should allow me to continue

Thanks!!

system · October 12, 2025, 7:53am

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