Cannot disable auto-https

Help
1

1. Caddy version (caddy version):

2.4.3

2. How I run Caddy:

Run in docker with port 80 and 443 mapped.

a. System environment:

Docker on Ubuntu (with Portainer)

b. Command:

caddy run --config /etc/caddy/Caddyfile --adapter caddyfile

d. My complete Caddyfile or JSON config:

{
  #debug
  auto_https disable_redirects
}

(basic-auth) {
  basicauth / {
    REDACTED
  }
}

# a snippet to check if a cookie token is set. if not, store the current page as the referer and redirect to auth site
(proxy-auth) {
  # if cookie not = some-token-nonsense
  @no-auth {
    not header_regexp mycookie Cookie myid=REDACTED
    # https://github.com/caddyserver/caddy/issues/3916
  }

  # store current time, page and redirect to auth
  route @no-auth {
    header Set-Cookie "myreferer={scheme}://{host}{uri}; Domain=renescott.dk; Path=/; Max-Age=30; HttpOnly; SameSite=Strict; Secure"
    redir https://auth.renescott.dk
  }
}

# a pseudo site that only requires basic auth, sets cookie, and redirects back to original site
auth.renescott.dk {
  route / {
    # require authentication
    import basic-auth

    # upon successful auth, set a client token
    header Set-Cookie "myid=REDACTED; Domain=renescott.dk; Path=/; Max-Age=3600; HttpOnly; SameSite=Strict; Secure"

    #delete the referer cookie
    header +Set-Cookie "myreferer=null; Domain=renescott; Path=/; Expires=Thu, 25 Sep 1971 12:00:00 GMT; HttpOnly; SameSite=Strict; Secure"

    # redirect back to the original site
    redir {http.request.cookie.myreferer}
  }

  # fallback
  respond "Hi."
}

http://192.168.20.200 {
  respond "hi."
}

portainer.renescott.dk {
  import proxy-auth
  reverse_proxy 192.168.20.200:9000
}
sonarr.renescott.dk {
  reverse_proxy 192.168.20.200:8989
  import proxy-auth
}
radarr.renescott.dk {
  reverse_proxy 192.168.20.200:7878
  import proxy-auth
}
nzb.renescott.dk {
  reverse_proxy 192.168.20.200:6789
  import proxy-auth
}
requests.renescott.dk, request.renescott.dk {
  reverse_proxy 192.168.20.200:5055
}
torrent.renescott.dk {
  reverse_proxy 192.168.20.200:8080 {
    header_up X-Forwarded-Host {host}:443
    header_up -Origin
    header_up -Referer
    header_down -content-security-policy
    header_down -x-frame-options
  }
}
media.renescott.dk {
  reverse_proxy 192.168.20.200:8011
  import proxy-auth
}
dash.renescott.dk {
  reverse_proxy 192.168.20.200:4041
  import proxy-auth
}
glances.renescott.dk {
  reverse_proxy 192.168.20.200:61208
  import proxy-auth
}
home.renescott.dk {
  reverse_proxy 192.168.20.203:8123
}
jackett.renescott.dk {
    import proxy-auth
    reverse_proxy 192.168.20.200:9117
}
cockpit.renescott.dk {
    import proxy-auth
    reverse_proxy 192.168.20.200:9090
}

3. The problem I’m having:

All the sites with domain work great, as I want to use https on these.
But I want to add a site, that is only available on local network on port 80. So when that didn’t work, I tried this simplified site block:

http://192.168.20.200 {
  respond "hi."
}

However, when visiting http://192.168.20.200/ I am auto redirected to https://192.168.20.200/
As far as I understood, that shouldn’t be the case when http has been specified for the site.
I even tried to disable auto redirect with the global auto_https disable_redirects, to no avail.

4. Error messages and/or full log output:

Only log entries added, are these:

{"level":"debug","ts":1630653357.841671,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.20.20:52022: no certificate available for '172.17.0.3'"}

Which makes sense, since I’m being redirected to https, and there’s no certificate since it’s an IP address and not a domain.
172.17.0.3 is the ip address of the container. 192.168.20.200 is the ip address of the host.

2

Sounds like Docker’s userland proxy is causing the requests to look like they’re headed to 172.17.0.3 instead of 192.168.20.200.

Probably best to run a DNS server in your home network to give your server a domain that maps to 192.168.20.200 that you can match with your Caddyfile.

I think the reason the redirect is still happening is that there is a “server” listening for requests on port 80, but since none of the matchers matched, it falls through and hits the default redirect behaviour.

I don’t understand why auto_https disable_redirects didn’t turn that off though, that doesn’t seem right. Are you sure you reloaded your config after making the change?

3

That won’t work for me. I’m trying to reverse proxy a deCONZ interface to be connectable from the Phillips hue app. And the Phillips hue app can only connect via IP and default port.

Yes, I am sure that i reloaded config, as I’ve tried many different changes to the caddyfile after adding that bit.

Any suggestions for matching against any non-domain request? Or overriding the catch-all for port 80, so if no other site is matched, I’ll handle that?

4

Yeah, you can do that with a site block like http://. Redirects for actual domains will still work, and unknown hostnames will fall through to that.

5

I added this block to the bottom of my caddyfile, however now all all requests to port 80 just print Hi (even with domain names), instead of redirecting to https (I did disable the global auto_https disable_redirects

http:// {
  respond "hi."
}

I can live with it, but I would like to have automatic redirect for my domain names.

6

Are you sure you’re using v2.4.3? Please run caddy version in your container to check.

We made some changes that landed in v2.4.0 to improve how sites are sorted to make sure that redirect routes are placed before the user-defined catch-all (i.e. http://). This all makes me think you’re not actually using the version you think you’re using.

7

Yeah, it is version 2.4.3
However, the issue was something cached in my browser. Opening an incognito window, it’s not redirecting.

1 Like
8

FWIW, it’s always a good idea to use curl -v to test server functionality to confirm it’s not some browser edgecase. Browsers are too smart for their own good sometimes, with all kinds of caching behaviour, etc.

1 Like
9

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