How to Configure Local DNS Overrides for Multiple Reverse Proxies

Create one authoritative local mapping for each application name and point it to exactly one reverse-proxy address per client network. Do not create competing wildcard overrides on multiple DNS servers.

Multiple proxies become confusing when the same public domain is reused internally: a laptop may ask the router, a container may ask a local resolver, and a phone may use encrypted DNS. The result can look like a proxy or certificate fault even though the client simply received the wrong address. Inventory the names, resolvers, proxy listeners, and certificates before adding records.

Assign names to proxy boundaries

List every application FQDN and the proxy that terminates its TLS connection. Use specific records for exceptions and reserve a wildcard only for a domain whose entire namespace belongs to one proxy.

Avoid giving the same name two private A records unless both proxies are intentionally active and identically configured. DNS returns addresses, not service health, so casual round-robin records can send half the clients to a proxy that lacks the route or certificate.

Keep management names separate from user-facing names. If an admin hostname must never resolve on a guest network, place it in a view or resolver available only to the trusted VLAN rather than relying on the proxy to hide it later.

Put overrides in the resolver clients actually use

Create the local zone or host overrides on the DNS service advertised by DHCP for that network. Point each application name to the LAN address of its owning proxy, not to the application container and not automatically to the public WAN address.

Clients and applications can use different resolver libraries and caches, which is why DNS behavior can stay hidden. Verify the server shown in the query output instead of assuming the router's override was consulted.

Disable or account for client-side encrypted DNS during the test. If the client deliberately bypasses local DNS, split-horizon overrides cannot affect it; choose managed DNS policy, a public record plus hairpin routing, or a VPN-provided resolver instead.

Match proxy routes, TLS, and application URLs

On each proxy, configure only the hostnames assigned to it and confirm that the certificate covers those names. A correct DNS answer followed by the wrong certificate proves that traffic reached a listener, but not the intended virtual host.

Test the upstream route from the proxy itself, then test the public hostname from a client. If direct upstream access works but the hostname returns a default site, correct the proxy host match before changing DNS again.

For applications hosted under a path, keep the proxy route and application base URL aligned. The ZimaSpace guide to removing Jellyfin exposure safely also shows why DNS, proxy routes, forwarding, and ACLs must be tracked together.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verify each network and define rollback

Query the FQDN directly against the intended local resolver, then query through the operating system's normal path. Both answers should point to the same proxy for that network, and the TTL should match the local policy.

Open the application from trusted LAN, guest or media VLAN, and VPN as applicable. Record the resolved address, certificate name, HTTP status, and final redirect; these observations identify whether a failure is DNS, TLS, proxy routing, or the application.

Remove stale duplicate records only after all clients pass. Roll back the newest override if different clients alternate between proxies, and stop expanding the wildcard until resolver logs prove which server answered every failing request.