Immich-netwerk: hoe detectie, DNS en routing bereikbaarheid mogelijk maken

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.

Immich Networking: How Discovery, DNS, and Routing Produce Reachability

De bereikbaarheid van Immich is het resultaat van een geordende keten: endpointselectie, DNS-resolutie, pakketroutering, proxy- of NAT-doorsturing en applicatierespons.

Een telefoon kan Immich via een lokaal IP-adres bereiken terwijl dezelfde hostnaam op wifi mislukt, of op afstand werken terwijl thuis een langere route wordt genomen. Deze uitkomsten ontstaan door verschillende naam- en routebeslissingen, niet door één universele status waarin “het netwerk actief is”.

Bereikbaarheid begint met het endpoint dat een client kiest

Een client kan geen route nemen naar “Immich” als abstracte service; hij gebruikt een schema, hostnaam of adres, poort en soms een pad. Native applicaties, browsers, bladwijzers en gedeelde links kunnen verschillende endpoints opslaan. Hun bereikbaarheid kan al verschillen voordat er een pakket de server bereikt.

Een communitydiscussie over Immich lokaal en op afstand beschikbaar maken beschrijft problemen wanneer een router geen split-horizongedrag kan bieden en de client niet automatisch tussen lokale endpoints kan schakelen. De casus laat zien dat endpointselectie en lokale DNS-mogelijkheden samen bepalen welk pad een client thuis probeert.

Noteer de exacte URL die elke client gebruikt en vermeld of deze is ingevoerd, via een link is geopend of eerder is opgeslagen. Vergelijk schema, host, poort en pad. Combineer een werkend lokaal IP-adres en een falende openbare hostnaam niet tot één resultaat; het zijn verschillende bestemmingscontracten.

DNS selecteert een adres, geen werkende service

DNS zet de geselecteerde hostnaam om in een adres. Openbare en lokale resolvers kunnen opzettelijk verschillende antwoorden geven, terwijl verouderde caches een oud router- of serveradres kunnen behouden. Een correct antwoord identificeert alleen een bestemming; het bewijst niet dat de poort, proxy, certificaat of applicatie daar beschikbaar is.

Een Caddy-communitycasus beschrijft hoe Immich via een lokaal IP-adres werkt terwijl een lokaal pad op basis van DuckDNS mislukt en vragen over hairpin-NAT oproept. De details zijn omgevingsspecifiek, maar tonen aan dat naamresolutie en retourpaden van de router kunnen verschillen, zelfs op hetzelfde thuisnetwerk.

Vraag de hostnaam op vanaf het netwerk van de getroffen telefoon of browser en vergelijk het antwoord met het verwachte lokale of openbare adres. Herhaal dit via mobiele data. Als de antwoorden opzettelijk verschillen, documenteer dan split DNS. Als ze onverwacht verschillen, corrigeer dan eerst het autoritatieve record of de cache voordat je Immich-containers wijzigt.

Routing, NAT en proxies voltooien de leveringsketen

Na DNS heeft de client een route nodig. Verkeer op afstand kan via een internetprovider, router, port forwarding, tunnel of reverse proxy lopen; lokaal verkeer kan rechtstreeks gaan of via de openbare rand teruglopen. Elke laag moet de juiste poort afleveren en de aanvraagcontext behouden die de applicatie verwacht.

Het Immich-datapad-artikel van ZimaSpace onderscheidt client-, netwerk-, applicatie-, database- en mediaver afhankelijkheden. Dat gelaagde model voorkomt een veelgemaakte fout: Immich herstarten terwijl de applicatie lokaal al antwoord geeft en de eerste defecte afhankelijkheid zich buiten de container bevindt.

Volg het pad in deze volgorde: adres, route, luisterende poort, proxyd oel, TLS-naam en applicatierespons. Een geslaagde ping is niet voldoende, omdat de web- of API-poort nog steeds geblokkeerd kan zijn. Evenmin bewijst een landingspagina van de proxy dat aanvragen de Immich-service bereiken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Gebruik een gelaagde bereikbaarheidstrace

Maak twee kolommen voor thuis-wifi en mobiele data. Noteer in beide de geselecteerde URL, het DNS-antwoord, de route of gateway, de TCP-verbinding, het TLS-resultaat, de HTTP-status en één geauthenticeerd Immich-API-antwoord. Gebruik hetzelfde account en asset, zodat identiteit of rechten de netwerkvergelijking niet veranderen.

Een Immich-handleiding voor een thuisserver toont DNS-routing als vereiste vóór de stappen voor certificaat- en applicatietoegang. De volgorde ondersteunt de diagnostische regel: latere lagen kunnen een onjuiste naam-naar-adreskoppeling niet compenseren, terwijl correcte DNS op zichzelf geen doorsturing of applicatiegezondheid valideert.

Stop bij de eerste laag waarvan de waargenomen waarde afwijkt van het verwachte pad. Corrigeer alleen die laag en herhaal beide kolommen, omdat een oplossing op afstand lokaal hairpin-gedrag kan verstoren. Bereikbaarheid is bevestigd wanneer beide bedoelde paden dezelfde applicatieaanvraag voltooien, niet alleen wanneer een hostnaam wordt omgezet.