caddy: Infinite Redirect with Caddy 0.9.3

1. What version of Caddy are you running (caddy -version)?

Caddy 0.9.3

2. What are you trying to do?

Serve https with automatic SSL

3. What is your entire Caddyfile?

https://sub.domain.com

log stdout
prometheus 0.0.0.0:9180

tls user@domain.com

proxy / upstream:80 {
  transparent
}

4. How did you run Caddy (give the full command and describe the execution environment)?

docker run -d --link upstream -p 0.0.0.0:80:80 -p 0.0.0.0:443:443 my-caddy-image

5. What did you expect to see?

The content of https://sub.domain.com/

6. What did you see instead (give full error messages and/or log)?

Infinite redirects from https://sub.domain.com/ to https://sub.domain.com/

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

Use this Dockerfile:

FROM alpine:3.4
RUN apk --update --no-cache add \
  ca-certificates \
  curl \
  git \
  openssh-client \
  && rm -rf /var/cache/apk/*
RUN mkdir -p /bin /srv
RUN curl -fsSL "https://caddyserver.com/download/build?os=linux&arch=amd64&features=cors%2Cgit%2Chugo%2Cminify%2Cprometheus%2Cratelimit%2Crealip%2Csearch%2Ccloudflare%2Cgooglecloud%2Croute53" -o /tmp/caddy.tar.gz \
  && cd /tmp \
  && tar xvzf caddy.tar.gz \
  && mv /tmp/caddy /bin/caddy \
  && rm -rf /tmp/caddy.tar.gz
VOLUME [ "/srv" ]
WORKDIR /srv
ADD Caddyfile /Caddyfile
EXPOSE 80 443 9180
CMD [ "/bin/caddy", "-http2=false" ]

and the above Caddyfile, run:

docker build -t my-caddy-image .
docker run -d -p 0.0.0.0:80:80 -p 0.0.0.0:443:443 my-caddy-image

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 1
  • Comments: 22 (6 by maintainers)

Commits related to this issue

Most upvoted comments

this was neither a bug in the upstream nor caddy, but a unlucky combination of configurations:

  • the stack was running in docker-compose
  • the upstream in the caddyfile was set to gitlab (plain no https scheme, so implicitly http)
  • the docker-compose service for gitlab was linked to the name gitlab to allow caddy to talk to the gitlab container
  • on a non-https request, caddy redirects to https://gitlab.domain.com
  • on a https request, the upstream name gitlab is resolved to gitlab.domain.com and a request to caddy (not the upstream) is issued - triggering the https redirect, since the backend is configured as plain http.

As a lesson learned: don’t name your upstream to something that can be resolved to the fqdn caddy is listening on. Maybe this is worth mentioning in the docs, @mholt ?

@arraisgabriel 👍, have fun with Caddy!

@elcore I’ve had the same problem here and your suggestion fixed it. In my case, my upstream was redirecting the request to HTTPS, causing the infinite loop.

Thank you =)

Can’t reproduce it either. What is upstream:80 doing ?