Een externe app oplossen die via IP-adres wel werkt, maar via domein niet

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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

Als een app via IP-adres wel werkt maar via domein niet, is de server bereikbaar en ligt de oorzaak meestal bij DNS, routering op basis van hostnaam, TLS of omleidingen.

Externe toegang via IP bewijst dat een netwerkpad de thuisserver bereikt, maar een domeinaanvraag bevat extra identiteitsinformatie via DNS, de TLS-servernaam, de HTTP Host-header en de geconfigureerde openbare URL van de applicatie. De snelste diagnose behoudt dezelfde client, poort en server en controleert elke identiteitslaag in volgorde, in plaats van de reverse proxy, het certificaat en de DNS-records tegelijk te wijzigen.

Bevestig dat de IP-test de bedoelde service bereikt

Noteer het exacte IP-adres, de poort, het protocol en de respons die op afstand werken. Controleer of het IP-adres de echte applicatie opent, een standaardpagina van de reverse proxy, een routerlogin of een andere service die hetzelfde openbare adres deelt.

Een handleiding voor reverse proxies in een homelab legt uit dat een proxy meerdere apps op één adres kan hosten, omdat deze de aangevraagde Host-header controleert voordat de upstreamservice wordt gekozen.

Als het IP-adres alleen een standaardsite bereikt, bewijst dat dat de proxy bereikbaar is, maar niet dat de route naar de doelapp werkt. Gebruik één bekende responsindicator, zoals een paginatitel of header, zodat latere tests de juiste virtuele host herkennen.

Vergelijk openbare DNS met het werkende IP-adres

Query het domein via een autoritatieve nameserver en minstens één externe recursieve resolver. Noteer elk A- en AAAA-antwoord, de TTL en of een CNAME naar een andere hostnaam verwijst.

Informatie over self-hosting vermeldt dat gecachte antwoorden kunnen blijven bestaan totdat de vorige TTL verloopt. Daardoor kunnen sommige clients na het corrigeren van de autoritatieve record nog steeds een oudere DNS-bestemming gebruiken.

Als de A-record afwijkt van het werkende IP-adres, corrigeer dan de record of de DDNS-updater. Als A correct is maar AAAA naar een onbereikbaar IPv6-pad verwijst, test dan beide adresfamilies afzonderlijk en verwijder of herstel de defecte record.

Maak verbinding met het werkende IP-adres en behoud het domein

Gebruik een client die verbinding kan maken met het bekende werkende IP-adres en daarbij het domein als HTTP Host-header en TLS-servernaam meestuurt. Zo wijzig je de bestemming zonder de identiteit te verwijderen die de proxy en het certificaat verwachten.

Server Fault legt uit dat een HTTP-reverse proxy de Host-header kan gebruiken om een route te selecteren, op dezelfde manier als naamgebaseerde virtuele hosts.

Als de aanvraag met behouden domein werkt, ligt de foutlaag bij DNS. Als de aanvraag de proxy bereikt maar de verkeerde site of een 404 retourneert, controleer dan de matching van virtuele hosts en de prioriteit van routes. Als TLS al vóór HTTP mislukt, controleer dan SNI en de certificaatselectie.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Controleer TLS-SNI en de identiteit van het certificaat

Vergelijk het certificaat dat voor het domein wordt teruggegeven met het certificaat dat voor het kale IP-adres wordt teruggegeven. Noteer de onderwerpnamen, uitgever, vervaldatum en of de proxy een standaardcertificaat presenteert.

SNI bevat de hostnaam in de TLS ClientHello, nog vóór het versleutelde HTTP-verzoek, zodat de proxy de beveiligde virtuele host kan selecteren. Een aanvraag die alleen het IP-adres gebruikt, kan daarom de hostnaam missen die tijdens de TLS-selectie wordt gebruikt, zelfs wanneer dezelfde listener wordt bereikt.

Herstel het domeincertificaat en de SNI-route in plaats van te verwachten dat een certificaat voor een privé- of dynamisch IP-adres werkt. Als er een CDN of TCP-proxy voor staat, controleer dan of deze SNI voor de bedoelde hostnaam doorgeeft of beëindigt.

Controleer of interne en externe DNS niet naar verschillende paden sturen

Vergelijk het domeinresultaat via mobiele data, een openbare resolver en het thuisnetwerk. Split-DNS kan thuis bewust een privéproxy-adres en op afstand een openbaar adres teruggeven, maar beide antwoorden moeten dezelfde logische hostnaamroute bereiken.

Een homelabdiscussie op Level1Techs laat zien dat lokale toegang via een reverse proxy een eigen DNS-ontwerp kan vereisen wanneer openbare DNS en routering thuis verschillende interne en externe paden gebruiken.

Als slechts één resolver het verkeerde adres teruggeeft, herstel dan die DNS-weergave. Als het openbare adres via IP wel werkt maar het domein overal faalt, richt je dan op Host, SNI, certificaat en applicatie-identiteit in plaats van op split-DNS.

Controleer canonieke URL's en omleidingen voordat je DNS als opgelost beschouwt

Controleer elke omleiding nadat het domein de app bereikt. De reverse proxy of applicatie kan clients doorsturen naar een interne hostnaam, een oud domein, het verkeerde schema, een privépoort of een verouderde callback-URL.

Het ZimaSpace-artikel over de vraag of split-DNS een probleem kan oplossen dat alleen binnenshuis optreedt behandelt het aangrenzende geval waarin de hostnaam correct is, maar de route per locatie verschilt.

Het probleem is pas opgelost wanneer autoritatieve DNS het bedoelde adres teruggeeft, het domein het juiste certificaat en de juiste prox yroute selecteert, omleidingen de openbare hostnaam behouden en de volledige externe workflow zonder vervanging door het IP-adres slaagt.