Lokale DNS kan het juiste NAS-IP-adres teruggeven, maar toch de verkeerde service openen wanneer de gedeelde reverse proxy de hostnaam naar een andere virtuele host doorstuurt.
Op een ZimaSpace-thuisserver kunnen meerdere apps één LAN-adres delen achter Nginx, Traefik, Caddy of een andere reverse proxy. DNS kiest alleen het bestemmings-IP-adres. De browser stuurt nog steeds een hostnaam mee via TLS SNI en de HTTP Host-header, waarna de proxy bepaalt welke container het verzoek ontvangt.
Controleer of het split-DNS-antwoord inderdaad bedoeld is
Vergelijk het lokale record met het openbare record en bevestig dat beide hostnamen naar dezelfde reverse proxy moeten verwijzen.
Een gerichte homelab-blog over split-DNS op split-DNS kan een privéroute teruggeven helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.
Laat de hostnaam in de browser ongewijzigd en verander alleen het adres dat door interne DNS wordt teruggegeven.
Bewijs dat de proxy op basis van de hostnaam routeert
Verstuur verzoeken met de verwachte hostnaam en vergelijk deze met rechtstreekse toegang via het IP-adres tot dezelfde NAS.
Een gerichte homelab-uitleg over reverse proxies op de Host-header selecteert de backend helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.
Als het rechtstreekse IP-adres een standaardapp opent terwijl de hostnaam de juiste app opent, ligt het probleem niet bij DNS; de routering van de virtuele host werkt dan zoals bedoeld.
Controleer of de Host-header wordt herschreven
Controleer de Host- en forwarded-host-headers bij de proxy en de backend.
Een gerichte uitleg over beveiliging en HTTP op wijzigingen aan de Host-header kunnen de routering aanpassen helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.
Corrigeer alleen de laag die de hostnaam herschrijft. Voeg geen dubbele DNS-records toe om een fout in de HTTP-routering te compenseren.
Controleer TLS SNI vóór de HTTP-routering
Meerdere HTTPS-apps op één IP-adres moeten nog steeds de hostnaam doorgeven die nodig is om het juiste certificaat en de juiste virtuele host te selecteren.
Een gerichte praktische SNI-handleiding op SNI selecteert tussen HTTPS-sites op één IP-adres helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.
Vergelijk de certificaatnaam met de backendroute. Een certificaat voor een andere app is een aanwijzing dat de selectie is misgegaan voordat het verzoek de bedoelde service bereikte.
Controleer de standaardvirtuele host
Als geen enkele hostnaamregel overeenkomt, sturen veel proxy's een standaardserver terug die bij een andere app kan horen.
Een gerichte Nginx-artikel over probleemoplossing op een niet-overeenkomende hostnaam kan de standaardserver bereiken helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.
Maak expliciete hostregels en een neutrale standaardreactie, in plaats van één toepassing als algemene opvang voor elk onbekend domein te laten fungeren.
Houd DNS-routering gescheiden van proxyroutering
Beschouw DNS als de selectie van een adres en de reverse proxy als de selectie van een toepassing.
Een gerichte uitleg over DNS versus reverse proxies op DNS en reverse proxies lossen verschillende routeringslagen op helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.
Test opnieuw met de exacte app-hostnaam vanaf een LAN-client. Het juiste resultaat bestaat uit het verwachte certificaat, de juiste proxyroute en de juiste backend, zonder bladwijzers met rechtstreekse IP-adressen.
Test het exacte thuisserverpad opnieuw
Herhaal na het wijzigen van één variabele dezelfde NAS- of self-hosted-workflow vanaf dezelfde client, in plaats van over te schakelen naar een andere test die mogelijk een ander pad gebruikt.
De gerelateerde ZimaSpace-handleiding op het aangrenzende thuisservernetwerkpad helpt om de laatste controle aan dezelfde self-hosted omgeving te koppelen.
De oplossing is pas voltooid wanneer het oorspronkelijke probleem ook na opnieuw verbinden, het herstarten van de service en een tweede gecontroleerde overdracht of aanvraag opgelost blijft.
Ondersteuning & Tips
Meer om te lezen

Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...

Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.

Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...

