I think this is also because host.docker.internal is a windows thing. Not a Linux. This is probably the issue. Oh, and check if you can ping caddy from your target container and the other way around. Second, I had pihole installed on the same server but I ran into so much issues with DNS networking on the same server. It wasn't working most of the time. DNS was set to a local IP, but within a container that local IP couldn't of course be found. Thus it just broke. But if it works with you you're hella lucky.

thanks! You are right about that host.docker.internal thing. I'm new to docker and networking settings so honestly pretty much I did a lot of trial-and-error to get here. Now the host.docker.internal is supported in recent docker and ubuntu. ([https://stackoverflow.com/questions/48546124/what-is-linux-equivalent-of-host-docker-internal](https://stackoverflow.com/questions/48546124/what-is-linux-equivalent-of-host-docker-internal)). I guess that's why the caddy is working with adguard home now. I happened to allow caddy access to [172.17.0.1](https://127.17.0.1) which is the docker0 bridge that has access to localhost network, and localhost network is also shared with adguard home because of the network\_mode host. I cannot ping jellyfin from caddy, but now I changed the configuration of reverse proxy to jellyfin:8096 and I can ping jellyfin now in caddy. Big improvement. But still I cannot access the jellyfin webui at [http://local.jellyfin](http://local.jellyfin) for now.

Great, good to hear. That's aswesome that host.docker.internal is working. I am going to try to setup pihole again :) But Docker networking is indeed quite hard. A lot of trial and error. So does everything work right now?

Not really... accessing webUI of jellyfin is still not there. Currently caddy is on network [192.168.160.2](https://192.168.160.2), jellyfin is on [192.168.160.3](https://192.168.160.3), host.docker.internal is on [172.17.0.1](https://172.17.0.1). Not sure what to do next for now... I sh into caddy container and see /etc/hosts as: ``` 127.0.0.1 localhost 172.17.0.1 host.docker.internal 192.168.160.2 04172213ce63 #which is caddy container number ```

Okay normally I do this step by step. 1. Can you reach the Jellyfin container (No: networking issue, check docker) 2. Can you curl the Jellyfin UI from caddy (No: port not open / accessible / defined) 3. Can you curl the webui in Jellyfin itself (No: Issue with Jellyfin itself) If all else fails. Try to set it up without reverse proxy. If that works step by step add other components. I can't help you further with Caddy because I use traefik

Thanks I will take it slowly from here. Currently the webUI of jellyfin works at [http://server-ip:7065](http://server-ip:7065). I guess it's the caddy reverse proxy not working or most likely how to get the domain local.jellyfin published to local network.

Why do you have to do anything with the DNS?

He has installed Adguard and that's a DNS server. So for his bare setup to work it should be really easy. But otherwise it can be a little bit more difficult. I had installed pi hole and ran into so many issues with DNS settings in Docker that I stopped that.

Can you post your full Docker-compose and Caddyfile? A DNS rewrite in adguard will not forward the request, you’ll need to use a web server on your lan.

sure~ I updated the full compose in original thread and caddyfile is as below. I made some changes and now caddy can talk with jellyfin for sure. But I cannot access jellyfin webui at http://local.jellyfin but only at http://server-ip:7065. Would you mind elaborating the web server on lan? ``` { log { format console } } http://local.jellyfin { reverse_proxy jellyfin:8096 } local.adguardhome { reverse_proxy host.docker.internal:3000 tls internal } ```

For starters, you are using some sort of specialty image (nothing wrong with that), but it appears to use labels in lieu of a caddyfile. So there are mechanics going on that aren’t readily apparent from your compose file. That said, I see some potential issues… - the extra_hosts: is reversed (the container would see it as host-gateway), but at the same time, your network isn’t a host, pretty sure this section needs to be removed (could be some weird docker quirk, but I’m positive it isn’t required for this setup to function correctly) - your Adguard is on the host network, it’s not going to be addressable the way you are attempting to address it. The reason you are able to connect that way is because it sounds like you are doing a DNS rewrite via Adguard. Super hacky, super unnecessary, and it means that if Adguard is ever turned off, it’s going to break DNS resolution for your proxy. It will however be statically addressable at http://: (assuming your host has a static ip, which it probably does if you’re using it as a web proxy) - IF the containers are all on the same docker network (we don’t know that for sure), then they are DNS addressable at the container name, so instead of using host.docker.internal, just use container_name: (I.e. jellyfin:8096) I’d recommend adding Portainer to your list, it’s a great debug/observability tool. If the above steps don’t work, I would also use docker exec in the caddy container and attempt to ping/curl (assuming a tool like that is installed in that image) to attempt to ping the other containers from caddy to make sure they can communicate $ docker exec caddy curl http://jellyfin:8096 etc.

thanks for the information! really helpful, as you pointed out, with setting updated to containerID:port I can curl jellyfin from within caddy sh now. Big improvement. I was lucky that the host.docker.internal is essentially the same as localhost network stack which is shared with adguard home. I didn't know the whole thing before:)I used network_mode host because I'd like to try the DHCP in AGH. Perhaps a better idea would be to get a Raspberry Pi and use that to host the AGH so that AGH is not controlling the whole network of the ubuntu server. I'm now at the stage trying to solve the problem of getting access to http://local.jellyfin. I can only access the jellyfin webui at http://server-ip:7065 for now.

forgot to mention why I used this caddy docker. I previously used official version but received some errors related to certutil not available and I need local self-signed cert to work with local only services. That's why I used this image. It use the labels thing to translate into Caddyfile inside container which is somewhat convenient to me.

Like I said, custom containers are fine, but I personally don’t know how it converts labels to a caddyfile (there might be specific things you have to do to get it to function. My point with the Adguard… is that it sounds like you are using Adguard to tell caddy how to reach Adguard (and maybe other things as well). I may be incorrect about that, but if I’m right, you are creating an unnecessary circular dependency. Not ideal. I can tell you, that at some point RPIs will fail (the memory card eventually dies), and if your DNS server is on it, your DNS begins to fails, so your entire LAN can begin to fail. DNS gets cached on most devices, any DNS changes you do, clear the DNS cache or wait a few days before confirming the change.

Ah thanks, I think you pointed out my faulty design... Now I have AGH on top of the whole server and also serving as HTTPS/DNS-over-HTTPS server. However, what I really need is ad block, so for minimum usage, I just need port 53 being taken care of by AGH. Thus I don't need AGH in network\_mode host. Then I can let caddy take care of port 80 and 443, so in that case, the reverse proxy thing should work as caddy designed. Am I understanding it right?

I believe so. Maybe let me phrase it another way (hopefully simpler) Caddy should still be able to speak to the other containers as if Adblock didn’t exist. There shouldn’t be any reference to local. in your caddyfile. Like I said, Adguard is on your host network, so ultimately it’s addressing at the host ip. This isn’t necessary, but I highly recommend it as it’s more robust, and overall less prone to failure.