What Causes Local DNS to Return the Right IP but the Wrong Service?

Local DNS can return the correct NAS IP yet open the wrong service when the shared reverse proxy routes the hostname to a different virtual host.

On a ZimaSpace home server, several apps may share one LAN address behind Nginx, Traefik, Caddy, or another reverse proxy. DNS only chooses the destination IP. The browser still sends a hostname through TLS SNI and the HTTP Host header, and the proxy decides which container receives the request.

Verify the Split-DNS Answer Is Actually Intended

Compare the local record with the public record and confirm that both hostnames are meant to terminate at the same reverse proxy.

A focused homelab split-dns blog on split DNS can return a private path helps isolate this branch because it addresses the same micro-problem instead of only defining the underlying protocol.

Keep the browser hostname unchanged while changing only the address returned by internal DNS.

Prove the Proxy Routes by Hostname

Send requests with the expected hostname and compare them with direct-IP access to the same NAS.

A focused homelab reverse-proxy walkthrough on the Host header selects the backend helps isolate this branch because it addresses the same micro-problem instead of only defining the underlying protocol.

If direct IP opens a default app while the hostname opens the correct app, DNS is not the fault; the virtual-host routing is behaving as designed.

Check Whether the Host Header Is Being Rewritten

Inspect the Host and forwarded-host headers at the proxy and backend.

A focused security and http explainer on Host header changes can alter routing helps isolate this branch because it addresses the same micro-problem instead of only defining the underlying protocol.

Correct only the layer that rewrites the hostname. Do not add duplicate DNS records to compensate for an HTTP routing error.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Check TLS SNI Before HTTP Routing

Multiple HTTPS apps on one IP must still present the hostname needed to select the intended certificate and virtual host.

A focused sni practical guide on SNI selects among HTTPS sites on one IP helps isolate this branch because it addresses the same micro-problem instead of only defining the underlying protocol.

Compare certificate name and backend route. A certificate for another app is evidence that selection went wrong before the request reached the intended service.

Inspect the Default Virtual Host

If no hostname rule matches, many proxies return a default server that may belong to another app.

A focused focused nginx troubleshooting article on an unmatched hostname can reach the default server helps isolate this branch because it addresses the same micro-problem instead of only defining the underlying protocol.

Create explicit host rules and a neutral default response rather than letting one application become the catch-all for every unknown domain.

Keep DNS Routing Separate From Proxy Routing

Treat DNS as address selection and the reverse proxy as application selection.

A focused dns versus reverse-proxy explainer on DNS and reverse proxies solve different routing layers helps isolate this branch because it addresses the same micro-problem instead of only defining the underlying protocol.

Retest with the exact app hostname from a LAN client. The correct result is the expected certificate, proxy route, and backend without direct-IP bookmarks.

Re-Test the Exact Home-Server Path

After changing one variable, repeat the same NAS or self-hosted workflow from the same client instead of switching to a different test that may use another path.

The related ZimaSpace guide on the adjacent home-server network path helps keep the final verification tied to the same self-hosted environment.

The fix is complete only when the original symptom stays resolved after reconnect, service restart, and a second controlled transfer or request.