So I'm having some issues with setting up Nginx. I have set up certificate and also did the DNS stuff for the domain. However if I for example go to one of the proxy hosts, it defaults to my UGREEN dashboard (on port 9999) for some reason? According to the docs, it remaps the ports, however I think the port 8443 is incorrect in the docs, as that is the port SparkBox dashboard runs on, and if I go to settings in SparkBox dashboard, the HTTPS port seems to be set to 8444? How can I fix the proxies, so that it actually redirects it to the correct site (for example Jellyfin on port 8096 as set in the Proxy Hosts)? And is there any other settings or whatever I will need to change to make it work correctly?
16 replies
tomspark wrote:
Good news, you don't need to wire this up in Nginx Proxy Manager by hand. SparkBox already has a reverse proxy built in, and there's a Custom Domain setup right in the dashboard that does exactly what you're describing: it points your own domain at all your services and gives each one a clean web address with HTTPS, so no more juggling ports. Open your SparkBox dashboard, head to Settings, and look for Custom Domain. It'll walk you through pointing your domain and sort the certificates for you. Give that a go and tell me where it gets you. One heads up: putting the arr stack and the rest straight on the public internet means anyone who finds the address can reach the login screens. If it's mainly you needing access from your phone or laptop, the Tailscale option is the safer route since nothing gets exposed publicly. Both work, just depends what you're after.
tomspark wrote:
Also, good eye — you're right, the docs had the wrong port. They said 8443 for the HTTPS setting, but 8443 is the SparkBox dashboard's own port, so it should be 8444. I've just fixed that in the guide. That mix-up is very likely why a proxy host was landing on the wrong place. If you're sticking with your manual Nginx setup, point the proxy host for each app straight at its container name and internal port (e.g. Jellyfin is sb-jellyfin on 8096), not at 8443/8444.
Seez wrote:
Okay so instead of forwarding port 443, should I then do the HTTP and HTTPS ports listed (8444 and 8080 in my case) in the server config section? or just forward port 80 and 443 "normally"? Or ONLY 443?
tomspark wrote:
To your port-forwarding question: keep the outside ports as the normal 80 and 443 on your router (so visitors reach you at https://yourdomain with no port in the address), but forward them to the ports SparkBox actually listens on, since UGOS is holding 80/443 itself. So: external 80 forwards to 8080 on the NAS, and external 443 forwards to 8444. Keep both 80 and 443 forwarded, not just 443 — the 80 one is what lets the certificate renew and redirects http to https.
Seez wrote:
So I did it like this: Correct? DNS on Cloudflare should be good, did it almost same way as on the WSL: I did this so far on Nginx, but still proxies to the UGREEN dashboard somehow. So like when I click on dns.domain.com it goes to the domain and with :9999 port at the end:
tomspark wrote:
Landing on the UGOS dashboard at :9999 means the request is reaching your NAS, but UGREEN's own admin page is grabbing it before SparkBox ever sees it — UGOS holds ports 80, 443 and 9999 for itself. So the fix is making sure nothing points at those ports. Two things to check: 1. On your router, external 443 should forward to 8444 on the NAS (and external 80 to 8080) — not to 443. If it forwards to 443, UGOS answers instead of SparkBox. 2. In each Nginx proxy host, the forward target should be the app's own container and port (e.g. sb-jellyfin : 8096), never the NAS on 443 or 9999. Quick question so I can pin it down: is your Nginx / Proxy Manager running on the UGREEN NAS itself, or on a separate machine?
Seez wrote:
Nginx is running on the UGREEN NAS via SparkBox :)
tomspark wrote:
Got it — since that Nginx is running through SparkBox, the easiest path is the dashboard's built-in Custom Domain setup (Settings - Custom Domain). It wires up the same thing but works around UGOS holding onto 80/443, so you stop fighting that :9999 redirect. If you'd rather keep setting it up by hand, two quick things help me pin it down: in one of your proxy hosts, what are the 'Forward Hostname/IP' and 'Forward Port' set to? And when it lands on :9999, are you testing from inside your house or from outside it? That tells me whether it's the proxy target or the network path tripping you up.
Seez wrote:
I did try the built-in Custom Domain setup, but it keeps giving me errors: 1. npm.domain.com — "npm.domain.com" is not a valid domain. Use the format app.example.com and try again. 2. When I select the domains I want and click "Setup Selected" it also says "Error DNS Settings"... :( But yeah, I do enjoy doing it manually in NPM too, but built-in setup is also okay.
Seez wrote:
And how I had them setup before was like this:
tomspark wrote:
That manual NPM setup is totally fine to keep as your fallback, no worries there. On the built-in wizard erroring out: the good news is that's almost certainly not a problem with your domain name. Both of those errors really mean the same thing — the certificate check can't reach your box yet. Make sure the domain's DNS points at your NAS's public IP, and if you're on Cloudflare set that record to 'DNS only' (the grey cloud, not orange) so the check can get through; the orange cloud blocks it and throws exactly these errors. Also run sudo sparkbox update first — an older version showed that confusing 'not a valid domain' message for what's really this DNS step. Flip the cloud to grey, retry, and tell me what it says.
Seez wrote:
The DNS is also setup as a wildcard (and type A) with my NAS's Public IP, and is set as grey cloud. (I was testing with my internal nas ip: 10.0.10.3 too) still seems to be the same.
Seez wrote:
Actually when DNS is set to the NAS public IP, the proxy site domains just keep loading and eventually "failing" 🤔
tomspark wrote:
Ah, that's the clue. "Keeps loading then fails" when you point the domain at your public IP and test from inside your own house is almost always your router refusing to reach its own public address from the inside — a lot of home routers block that. It's likely not broken, it just can't loop back on itself. Real test: turn WiFi off on your phone and open the domain over mobile data — if it loads there, it's actually working. Honest take though: if public exposure keeps fighting you, the Tailscale option in the SparkBox dashboard skips all of this — no ports, no certificates, nothing exposed to the internet — and it's the safer route for the arr stack anyway, since you don't really want those login pages open to the whole web. Happy to walk you through either one.
Seez wrote:
Okay weird thing is happening. my npm. domain works for me on my iphone without wifi, but for example my plex url doesn't, it just shows the Nginx Proxy Manager "Congratulations!" site. I had a friend test my plex url, and it works fine for him 🤣 EDIT: It works in Chrome on my iPhone, but not in Safari. some iCloud safari settings or something perhaps idk.
tomspark wrote:
Haha you basically nailed it yourself — that's iCloud Private Relay. When it's on, Safari routes through Apple's network and resolves your domain a little differently than Chrome does, which is exactly why Chrome and your friend both work but Safari lands on that NPM 'Congratulations' default page. Your actual setup is fine — this is just a Safari quirk on your phone, not your server. To confirm: on your iPhone open Settings, tap your name at the top, then iCloud, then Private Relay, and switch it off. Reload the Plex URL in Safari and it should come right up. Nice work getting it all sorted!