Custom domain problems

Posted by fr05t1k

Hi there, I've got a few problems with the custom domains using duckdns.org. 1. When you try to setup custom domains with NPM (Nginx), It creates proxy hosts with incorrect hosts. Since the arr stack runs under the gluetun network, npm can't reach the containers with these config: 2. If we want to use the contianer names we need to use the container ports. For example, for the filebrowser npm should poxy to port 80, not 8086. 3. When I try to setup hosts with the dns challange I'm getting these errors: ✗ docker.x.duckdns.org — DuckDNS only points the single name "x.duckdns.org" at your server — it can't resolve a per-app subdomain like "docker.x.duckdns.org". Use "x.duckdns.org" for everything, or turn on the DNS challenge below (with your DuckDNS token) to get a wildcard certificate. To fix that I manually added the wildcard certificate in the npm. Not sure if it's the right way to do so. I can fix everything manually, but just let you know :)

4 replies

fr05t1k wrote:

It would be cool if the app can have custom domains in the launcher.

Chris wrote:

You're right on all three, and thank you for writing it up this precisely — these are faults in our wizard, not your setup. The arr apps share gluetun's network, so they have no container name of their own on the proxy network at all. sb-sonarr, sb-radarr, sb-prowlarr, sb-qbittorrent, sb-lidarr and sb-sabnzbd will never resolve from Nginx Proxy Manager, no matter what is filled in. Point those proxy hosts at your NAS's own LAN address plus the published port instead — 192.168.x.x and 8989 for Sonarr, for example. Jellyfin, Seerr, Bazarr and Notifiarr are the only media containers sitting on the shared proxy network, so those really do work by name. Your port point is the same bug from the other side: the wizard fills in the port SparkBox publishes on the host, not the one inside the container. File Browser is 8086 outside and 80 inside, so 80 is correct — same story for Nextcloud, Vaultwarden, Pi-hole, FreshRSS, Gotify and Speedtest. The wildcard was the right call too. That message promises the DNS challenge will get you a wildcard certificate, but the wizard only ever requests the exact name you typed, never .yourname.duckdns.org — so it cannot deliver what it offers. Doing it by hand in NPM is genuinely the only route that works today. All three are written up for Tom, and the launcher idea is logged. — Chris

Chris wrote:

Following up on the launcher part, because it turns out to be more than a wish-list item. The launcher builds every tile from whatever address you are currently viewing the dashboard on, plus the app's host port. So once you set up dash.yourname.duckdns.org and start using the dashboard there, Sonarr's tile becomes dash.yourname.duckdns.org:8989 — your dashboard's own subdomain and the raw port, going nowhere near the proxy hosts you made. From outside your network that opens nothing unless you forward every app port, which is exactly what the proxy was meant to avoid. So your idea is written up for Tom as a gap on our side rather than a nice-to-have. Nothing to change on your box — your manual entries are still the right setup. — Chris

tomspark wrote:

Heads up — 1.6.465 shipped recently and should cover what you reported here. You can grab it straight from the dashboard: Settings → Updates → Update SparkBox. Let me know if that sorts it, or if you're still hitting it. (Prefer the terminal? sudo sparkbox upgrade — note update only refreshes app images and will not move you to a new release.)