How to Troubleshoot a Remote App That Works by IP but Not by Domain

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Troubleshoot a Remote App That Works by IP but Not by Domain - Zima Store Online

If an app works by IP but not by domain, the server is reachable and the failure is usually in DNS, hostname-based routing, TLS, or redirects.

Remote access by IP proves that some network path reaches the home server, but a domain request carries additional identity through DNS, the TLS server name, the HTTP Host header, and the application’s configured public URL. The fastest diagnosis preserves the same client, port, and server while checking each identity layer in order instead of changing the reverse proxy, certificate, and DNS records at the same time.

Confirm That the IP Test Reaches the Intended Service

Record the exact IP address, port, protocol, and response that work remotely. Check whether the IP opens the real application, a reverse-proxy default page, a router login, or another service sharing the same public address.

A homelab reverse-proxy walkthrough explains that a proxy can host several apps on one address because it examines the requested Host header before choosing the upstream service.

If the IP reaches only a default site, it proves the proxy is reachable but not that the target app route works. Keep one known response marker, such as a page title or header, so later tests identify the correct virtual host.

Compare Public DNS With the Working IP Address

Query the domain through an authoritative nameserver and at least one external recursive resolver. Record every A and AAAA answer, TTL, and whether a CNAME points to another hostname.

Self-hosting guidance notes that cached answers may remain until the previous TTL expires, so a recent change can leave some clients using an older DNS destination after the authoritative record is corrected.

If the A record differs from the working IP, correct the record or DDNS updater. If A is correct but AAAA points to an unreachable IPv6 path, test each address family separately and remove or repair the broken record.

Connect to the Working IP While Preserving the Domain

Use a client that can connect to the known working IP while sending the domain as the HTTP Host header and TLS server name. This changes the destination without discarding the identity the proxy and certificate expect.

Server Fault explains that an HTTP reverse proxy can use the Host header to select a route in the same way as name-based virtual hosts.

If the preserved-domain request works, DNS is the failing layer. If it reaches the proxy but returns the wrong site or 404, inspect virtual-host matching and route priority; if TLS fails before HTTP, inspect SNI and certificate selection.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Check TLS SNI and Certificate Identity

Compare the certificate returned for the domain with the certificate returned for the bare IP. Record the subject names, issuer, expiry, and whether the proxy presents a default certificate.

SNI carries the hostname in the TLS ClientHello before the encrypted HTTP request, allowing the proxy to select the secure virtual host. An IP-only request may therefore lack the hostname used during TLS selection even when it reaches the same listener.

Fix the domain certificate and SNI route rather than expecting a certificate for a private or dynamic IP. If a CDN or TCP proxy sits in front, confirm it passes or terminates SNI for the intended hostname.

Verify Internal and External DNS Do Not Send Different Paths

Compare the domain result from mobile data, a public resolver, and the home LAN. Split DNS may intentionally return a private proxy address at home and a public address remotely, but both answers must reach the same logical hostname route.

A Level1Techs homelab discussion shows that local reverse-proxy access can require its own DNS design when public DNS and home routing take different internal and external paths.

If only one resolver returns the wrong address, fix that DNS view. If the public address works by IP but the domain fails everywhere, keep the focus on Host, SNI, certificate, and application identity rather than split DNS.

Check Canonical URLs and Redirects Before Declaring DNS Fixed

Inspect every redirect after the domain reaches the app. The reverse proxy or application may send clients to an internal hostname, old domain, wrong scheme, private port, or obsolete callback URL.

The ZimaSpace article on whether split DNS can repair an inside-only failure covers the adjacent case where the hostname is correct but the route differs by location.

The issue is resolved only when authoritative DNS returns the intended address, the domain selects the correct certificate and proxy route, redirects preserve the public hostname, and the full remote workflow succeeds without substituting the IP.