Why Does a Reverse Proxy Work by Domain but Fail by Local IP?
A reverse proxy works by domain because its routing and TLS rules often depend on the requested hostname, not only the destination IP.
When a home client opens https://app.example.com, DNS supplies an IP but the browser still sends the domain through the TLS handshake and HTTP Host header. Opening https://192.168.1.20 changes those identifiers, so the proxy may select a default site, reject the certificate, miss the application route, or redirect back to the configured public URL. The correct test preserves the intended hostname while changing only the network destination.
Compare the Hostname Request With the Direct-IP Request
Send one request to the domain and one to the local IP, then compare status code, certificate, response headers, redirect location, and reverse-proxy access log. Do not assume both requests are equivalent because they reach the same Ethernet interface.
A homelab reverse-proxy walkthrough explains that the proxy inspects the HTTP Host header to route several services through one IP and port.
If the domain request matches an application route while the IP request hits a default page or 404, the proxy is operating as configured. The next decision is whether direct-IP access is actually required or whether local DNS should preserve the domain.
Test the Local IP While Preserving the Intended Host Header
Use a client tool that connects to the local proxy IP while sending the application domain as the Host header. For HTTPS, also preserve the domain as the TLS server name rather than replacing it with the IP.
Server Fault describes how an HTTP reverse proxy can use the Host header to choose the route in the same way as name-based virtual hosts.
If the forced-host request succeeds, the proxy route and backend are healthy; direct-IP failure is an identity mismatch. If it still fails, inspect the listener, local firewall, proxy entry point, and route priority before changing DNS.
Check TLS SNI and Certificate Matching
HTTPS adds a hostname decision before the HTTP request. The client usually sends Server Name Indication during the TLS handshake so the proxy can select the correct certificate and secure virtual host.
An SNI reverse-proxy implementation notes that HTTPS backends are selected using the clientโs SNI hostname before ordinary HTTP headers can be examined.
Direct access by IP may present a default certificate or fail hostname validation even when the proxy is reachable. Use the domain with local DNS, or deploy a deliberately managed certificate containing the IP only when direct-IP HTTPS is a real operational requirement.
Inspect the Default Site and Route Priority
Review which virtual host handles requests that do not match a configured domain. A default site may return a dashboard, redirect to another hostname, close the connection, or expose a generic error.
A Caddy discussion shows that a request can reach the correct proxy IP while the Host header and TLS name still determine whether the intended upstream is chosen.
Keep the default route explicit and safe. Do not add a broad catch-all proxy to one backend merely to make IP access work, because that can route unknown hostnames or scanning traffic into an application that was meant to be domain-restricted.
Check Whether the Application Redirects to Its Canonical URL
Even when the proxy accepts the IP request, the backend may enforce a configured public base URL and redirect the browser to the domain. Authentication cookies, OAuth callbacks, WebSocket origins, and CSRF checks can also depend on that canonical host.
Compare the proxy log with the application log and inspect the Location header. A redirect to the domain is not a routing failure; it is evidence that the application expects one public identity.
Correct forwarded host and protocol headers when the app generates the wrong external URL. Do not replace the canonical domain with a private IP merely to bypass the redirect, because that can break certificates and remote access.
Use Local DNS When the Domain Is the Intended Interface
Create an internal DNS record that resolves the application domain to the local reverse-proxy address. The browser then uses the efficient LAN path while preserving the same Host header, SNI name, certificate, cookies, and application URL.
The ZimaSpace comparison of reverse proxies and private access paths helps decide whether the domain should remain a local and public entry point or stay behind a private network.
The issue is resolved when the domain works both inside and outside through intentional DNS answers, while direct IP either reaches a documented default site or is deliberately rejected. A domain-routed proxy does not need to behave like an IP-addressed single-site server.
Recommended products
Support & Tips
More to Read
How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...
How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.
How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.
