Zo test je of DNS Immich-verbindingsproblemen veroorzaakt

DNS is alleen een waarschijnlijke oorzaak bij Immich wanneer de falende client de exacte Immich-hostnaam niet kan omzetten naar het adres dat de dienst moet leveren, of wanneer dat antwoord verschilt per resolver, netwerk of tijdstip.

Test naamresolutie afzonderlijk van de bereikbaarheid van de applicatie. Een geslaagde verbinding op IP-niveau kan aantonen dat er een route en poort bestaan, maar bewijst niet dat HTTPS, reverse-proxyroutering, certificaten of hostgebaseerde regels zonder de hostnaam zullen werken. De veiligste werkwijze is om de exact falende naam vast te leggen, deze vanaf de getroffen client op te vragen, resolvers te vergelijken en daarna de oorspronkelijke Immich-actie te herhalen na één wijziging op de DNS-laag.

Definieer de exacte hostnaam en het foutpad

Leg de hostnaam vast die de falende Immich-client daadwerkelijk gebruikt, het netwerk waarop deze zich bevindt, het tijdstip van de fout en of de fout betrekking heeft op de webapp, mobiele app of beide. Begin niet met een algemene test, zoals het opzoeken van een willekeurig openbaar domein, want daarmee bewijs je alleen dat een bepaald DNS-pad werkt.

Vergelijk dezelfde hostnaam vanaf een werkende en een falende client. Noteer elk A- en AAAA-antwoord, de resolver die antwoordde en of de client zich binnen het thuisnetwerk, op mobiele data of achter een VPN bevindt. Verschillende antwoorden kunnen opzettelijk zijn bij split-DNS, maar ze moeten elke client wel naar een bereikbaar eindpunt leiden.

Test als controle of het verwachte serveradres en de poort bereikbaar zijn zonder afhankelijk te zijn van de normale DNS-opzoeking. Gebruik dit alleen om het netwerkpad te onderscheiden: HTTPS-certificaten, SNI, reverse proxies en virtuele hosts kunnen een verzoek op basis van een IP-adres nog steeds weigeren, zelfs wanneer de dienst gezond is.

Vraag DNS op vanaf de falende client, niet alleen vanaf de server

Voer een DNS-opzoeking uit op het apparaat of in de omgeving waar de fout daadwerkelijk optreedt. Als de Immich-client achter een VPN, privé-DNS-profiel, containerstub of door de router geleverde resolver zit, kan een opzoeking vanaf de server een ander resolverpad gebruiken en het probleem verbergen.

Vraag de falende hostnaam eerst op via de standaardresolver van de client en daarna expliciet via een bekende vergelijkingsresolver of de beoogde interne resolver. Een gerichte dig-opzoeking toont het teruggegeven antwoord, de antwoordende server, de status en de opvraagtijd, zodat je kunt zien of de fout een specifieke resolver volgt.

Herhaal de opzoeking meerdere keren in plaats van op één geslaagde poging te vertrouwen. Noteer NXDOMAIN, SERVFAIL, time-outs, verouderde adressen of inconsistente A-/AAAA-antwoorden. Een stabiel correct antwoord verplaatst de verdenking weg van elementaire DNS-resolutie en richting routering, proxy, TLS, firewall of applicatieconfiguratie.

Vergelijk resolverresultaten en fouttypen

Interpreteer de antwoordcode voordat je instellingen wijzigt. NXDOMAIN betekent dat de opgevraagde naam vanuit het perspectief van die resolver niet bestaat; SERVFAIL betekent dat de resolutie niet kon worden voltooid; een time-out betekent dat de resolver niet op tijd antwoordde. Een syntactisch geldig antwoord kan nog steeds verkeerd zijn als het naar een oud routeradres of een onbereikbaar eindpunt verwijst.

Fouten waarbij een naam niet wordt gevonden en tijdelijke resolverfouten zijn verschillende gevallen. Gebruik verschillen tussen naamresolutiefouten om te bepalen of je een ontbrekend record, een onbereikbare resolver of een instabiel DNS-pad moet herstellen, in plaats van elke opzoekingsfout als hetzelfde probleem te behandelen.

Als alleen de thuisresolver het oude of verkeerde adres teruggeeft terwijl een andere resolver de bedoelde openbare waarde teruggeeft, controleer dan lokale overschrijvingen, split-DNS-records, door DHCP geleverde DNS, filterdiensten en caches. Als elke resolver hetzelfde correcte adres teruggeeft, stop dan met het wijzigen van DNS en ga verder met het servicepad.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Gebruik een gecontroleerde omweg om DNS te bevestigen of uit te sluiten

Maak één tijdelijke, omkeerbare controle die alleen de naamresolutie voor de falende client wijzigt. Vraag bijvoorbeeld rechtstreeks een andere resolver op of gebruik tijdelijk een hosts-bestandsvermelding die de exacte Immich-hostnaam koppelt aan het bekende beoogde eindpunt. Bewaar de oorspronkelijke instellingen zodat je de test direct ongedaan kunt maken.

Als de oorspronkelijke Immich-werkwijze begint te werken terwijl de hostnaam hetzelfde blijft en alleen het resolutiepad is gewijzigd, is DNS sterk verdacht. Als dezelfde hostnaam nog steeds faalt nadat deze naar het geverifieerde eindpunt resolveert, ligt de fout buiten DNS en moet je proxyrouting, certificaten, NAT, firewallregels of de Immich-service zelf controleren.

Als één schone opzoeking het probleem binnen het huishoudelijke foutvenster niet reproduceert, vergelijk dan na verloop van tijd de status van host, container, lokale resolver, upstream-resolver, DHCP, VPN en cache. Een DNS-controle over meerdere lagen helpt intermitterende gevallen te vinden die tijdens een eenmalige test verdwijnen.

Wis de juiste cache en test de oorspronkelijke Immich-werkwijze opnieuw

Wis na het corrigeren van een DNS-record, resolver, DHCP-optie, split-DNS-regel of lokale overschrijving alleen de relevante client- of resolvercache, wanneer dat praktisch is. Wis niet herhaaldelijk elke laag zonder vast te leggen wat er is gewijzigd, want daardoor kan een tijdelijk succes onmogelijk te verklaren worden.

Resolveer de hostnaam opnieuw vanaf de getroffen client en controleer het beoogde A-/AAAA-antwoord, de resolver en de responstijd. Open Immich vervolgens via de normale hostnaam, laad oudere items, zoek en voer één veilige upload of andere schrijfactie uit, zodat de test meer omvat dan alleen een inlogpagina.

Herhaal de controle vanuit de netwerktoestand waarin de fout oorspronkelijk optrad, zoals mobiele data, wifi thuis, wifi met VPN-verbinding of na het vernieuwen van de router/DHCP. DNS is pas als hoofdoorzaak uitgesloten wanneer de normale hostnaam correct blijft tijdens de gebeurtenis die het probleem eerder veroorzaakte; bewaar anders het nieuwe bewijs en ga verder op de volgende netwerklaag.