HTTPS is working but HTTP is not loading

1. Caddy version: v2.5.0 h1:eRHzZ4l3X6Ag3kUt8nj5IxATprhqKq/wToP7OHlXWA0=

2. How I installed, and run Caddy:


a. System environment: Debian

Docker version 20.10.5+dfsg1, build 55c4c88
docker-compose version 1.25.0
Linux version: 5.10.0-17-amd64

b. Command:

docker-compose up caddy

c. Service/unit/compose file:

    image: caddy:2.5.0-alpine
    container_name: caddy
    restart: always
      - 80:80
      - 443:443
      - 2019:2019
      - ./caddy-data:/data
      - ./Caddyfile:/etc/caddy/Caddyfile
      - /home/<user>/web:/var/www

d. My complete Caddy config: {
  root * /var/www/ICheeredWebsite

3. The problem I’m having: works fine is not loading

It seems that the HTTP request is not being redirected to the HTTPS version. It took a very long time for me to discover this issue because I only checked “” which automatically redirected to the https version, and the chrome browser on my phone redirects manually enetered http links to the https version automatically before making the request.

4. Error messages and/or full log output:

These are the logs from the docker container that is running caddy.

{"level":"info","ts":1675590145.8682392,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"warn","ts":1675590145.868944,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1675590145.869519,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["//","//localhost:2019","//[::1]:2019"]}
{"level":"info","ts":1675590145.8696437,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1675590145.8696597,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1675590145.869693,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000438a80"}
{"level":"info","ts":1675590145.8699696,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["",""]}
{"level":"info","ts":1675590145.869972,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
{"level":"info","ts":1675590145.8711853,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1675590145.8712063,"msg":"serving initial configuration"}
{"level":"info","ts":1675590145.8749053,"logger":"tls","msg":"finished cleaning storage units"}

5. What I already tried:

I tried the following additions to my Caddyfile:

# Force redirect http to https {  
# Redirect everything from port 80 to https
*:80 {
    redir https://{domain}{uri}

I checked my router’s port-forwarding and port 80 traffic is forwarded correctly to the server.

6. Links to relevant resources:

(The solution didn’t work for me)

Your ISP might block it, though. Consider asking them if that’s the case.
You could also test localhost using the following command from the server that’s running Caddy:
curl -I --connect-to

That’s very old. Please update to the latest release, which is currently v2.6.2

Also, remove - 2019:2019 and add - 443:443/udp for http/3 instead

Thanks for your response. I updated the version:

v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

And adjusted the port definitions to your suggestion.

When I try running the command you supplied to test locally, I’m not sure what to make of it but it seems that it can’t find the HTTP location. I ran it once with HTTP and once with HTTPS to check the difference:

 ✘ user@host  ~/services  curl -I --connect-to
HTTP/1.1 302 Found
Location: https:///
Server: Caddy
Date: Mon, 06 Feb 2023 09:58:57 GMT

 user@host  ~/services  curl -I --connect-to
HTTP/2 200 
accept-ranges: bytes
alt-svc: h3=":443"; ma=2592000
content-type: text/html; charset=utf-8
etag: "rd0bqn1h5"
last-modified: Sun, 05 Jun 2022 13:49:35 GMT
server: Caddy
content-length: 1913
date: Mon, 06 Feb 2023 09:59:00 GMT

Well I still don’t know what the problem was, but I removed and re-created my caddy file, restarted the container, and reloaded the caddy file (docker-compose exec caddy caddy reload --config /etc/caddy/Caddyfile) and now the problem has disappeared…

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