I have the following configurations to point my domain to my service, but I can't seem to get it to work. Everytime i try to go into "music.[my-domain].com" it won't resolve. Does it look like im missing anything? The service is hosted at 192.168.1.139:30043
Unbound DNS override:
Host: music
Domain: [my-domain].com
Type: IPv4 Address
Value: 192.168.1.1
NginX
Upstream server:
Description: Music server
Server: 192.168.1.139
Port: 30043
Priority: 1
Upstream:
Description: Music server
Servers: Music server
TLS enabled: true
TLS supported versions: TLSv1.2, TLSv1.3
HTTP Location:
URL Pattern: /
Upstream Servers: Music server
Force HTTPS: false
Match type: None
URL Path Prefix: none
HTTP Server:
TLS Certificate: music.[my-domain].com (renewed through ACME client)
HTTP Listen Address: 80, [::]:80
HTTPS Listen Address: 443, [::]:443
Server name: music.[my-domain].com
Locations: Music server
You use upstream - TLS enabled: true
does your service use tls?
What happens when you uncheck that.
if that works and you want ssl/https, let nginx do that.
Set https location, force https on true
and https server, HTTPS Only on true
If the Unbound override only says [my-domain].com, then music.[my-domain].com will obviously not be resolved. You can use *.[my-domain].com as an alias in Unbound.
It seems like your DNS is pointing "music" to 192.168.1.1, which is probably your router, not the actual server at 192.168.1.139. You'll want to point it directly to your server's IP if this is for internal use.
Also, private IPs like 192.168.x.x won't work from outside your network. To access it externally, you'll need port forwarding or a public-facing proxy.
Your NginX setup looks fine if it can reach the server internally.
If you want an easier way to manage access without complicated network changes, some use residential proxies like Fleetproxy (https://fleetproxy.io/).
Hope that helps!
Hey @ssddone,
Thanks for sharing the setup details — super helpful! If you're still running into trouble with the policy-based routing, one thing you might want to double-check is whether your WireGuard tunnel is correctly assigned to a gateway group and that the firewall rule for LAN devices (like 192.168.1.8) explicitly uses that gateway. Sometimes a simple misconfiguration there can prevent traffic from going through the WG tunnel, even if the handshake is successful.
Also, ensure that "Skip rules when gateway is down" is disabled under System > Settings > General, especially if you're testing while the tunnel is not always up.
If you're using DNS to route specific traffic, don't forget to account for DNS leak protection — some people use Unbound with custom forwarding rules or DNS overrides to keep DNS traffic in the same policy route.
Let us know if you found a fix — this could help others too!