Internal DDNS subdomain workings

1. Caddy version (caddy version):

v2.4.6

2. How I run Caddy:

a. System environment:

Using docker desktop for windows 4.7.0

b. Command:

Currently using docker commands, will switch to docker compose after I am satisfied with my understanding of the workings:

docker run -d -p 443:443 -p 80:80 -p 8080:8080 --name website -v ${PWD}/Caddyfile:/etc/caddy/Caddyfile:ro -v caddy_data:/data caddy-duckdns

The image caddy-duckdns is one I created using a dockerfile while doing a crash-course docker (shown below), essentially it is the base image with duckdns module:

FROM caddy:2-builder AS builder
RUN xcaddy build \
--with github.com/caddy-dns/duckdns

FROM caddy:2
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

http://my-domain.duckdns.org {
  respond "Hello world"
}

http://duck.my-domain.duckdns.org {
  respond "It's a duck world!"
}

3. The problem I’m having / What I tried:

I am pretty new to the whole world of servers / websites / certificates and still a little inexperienced in docker, so perhaps WHY this is not working is rather obvious, in that case a ELI5 explanation is perhaps more appropriate.
(While writing this help request I actually got a little further than I was initially, guess the template is helping :smile: )
my-domain.duckdns.org points to an internal IP adress. Now I am trying to understand how subdomains can be redirected so I can use these subdomains to point to different containers on my home server.

I started out with a simple caddyfile:

:80 {
  respond "Hello world"
}

:8080 {
  respond "Goodbye world"
}

Opened in browser, got the right responses when typing in the IP address with the given ports. Sweet! In the future I will of course be using reverse_proxy but for testing this was fine.
I also verified I got the hello world response when using my-domain.duckdns.org in the browser.

Next I tried the caddyfile listed above, but then my browser returns a ERR_CONNECTION_CLOSED response. I tried it without the HTTP:// part but then I get the error ERR_SSL_PROTOCOL_ERROR. Now this one I think I understand, by default caddy uses HTTPS and I havent got a certificate and this server is not reachable from the web so a secured connection cannot be established. (Correct?)

I have also tried this caddyfile, which uses (a slightly magic for me) DNS challenge to get a certificate:

my-domain.duckdns.org {
  tls {
    dns duckdns <duckdns token>
  }
  respond "Hello world"
}

duck.my-domain.duckdns.org {
  tls {
    dns duckdns <duckdns token>
  }
  respond "It's a DUCK world"
}

And this works as expected!
Now, when writing this, I also tested the http version listed above with curl (as recommended by the template), which IS getting the correct responses!
So I guess my real question boils down to: why is my browser getting the ERR_CONNECTION_CLOSED response when trying to navigate to http://my-domain.duckdns.org when using the http version of my caddyfile?

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

PS: I am not seeing the preview in chrome or edge, any help on that as well?

Just to clarify, you’re pointing it to a 192.168.x.x address, for example? This would mean that requests would not work outside your LAN at all, only within your network.

Browsers will cache (a.k.a. remember) that HTTPS was used for a domain, if used at all, so if you try to use HTTP again, it’s probably ignoring what you told it and trying to connect over HTTPS. If you’re using http:// then Caddy isn’t listening for HTTPS requests, so the connection doesn’t succeed.

Try making the requests with curl -v instead, which doesn’t have any such caching behaviour.

2 Likes

Thanks for the help!

That is correct, I got the idea from here: Running a private vaultwarden instance with Let's Encrypt certs · dani-garcia/vaultwarden Wiki · GitHub.

I see, that could explain my situation indeed. When I tried it using curl I did get the response that I was expecting. Is there an easy (and sure) way to clear the cache in chrome to verify that this was the problem? Or I could create a different domain that I have not yet visited on HTTPS to see if I get the same response?

Yeah, just clear the cache in your browser’s settings.

I just found the time to test the suggestions offered here and everything is working as I would expect now. So the caching behavior was indeed the reason I was having trouble getting my configuration correct. Thanks for the help!

2 Likes

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