Dynamic DNS werkt het verkeerde adres bij wanneer de updater een ander interface of internetuitgang observeert dan waar externe clients naartoe moeten verbinden.
In een thuisnetwerk kan de router een privé-WAN-adres rapporteren achter een andere gateway, kan een server-side updater een VPN- of proxy-uitgang zien, kan een IPv6-updater een IPv4-record overschrijven, of kunnen twee clients hetzelfde hostname vanaf verschillende locaties bijwerken. De diagnose begint met het kiezen van één publieke-adres bron van waarheid en vervolgens precies identificeren welke updater, record, adresfamilie en detectiemethode de verkeerde waarde heeft geproduceerd.
Vergelijk Drie Adressen Tegelijk
Noteer het DDNS-record, het WAN-adres van de router en het publieke adres dat wordt waargenomen door een externe IPv4- of IPv6-service. Voeg tijdstempels toe zodat een legitieme recente wijziging niet wordt aangezien voor een verkeerde update.
Een TP-Link community-voorbeeld toonde een router die een adres rapporteerde uit een provider NAT-pool terwijl het externe internet een ander adres zag, waardoor het DDNS-hostname wees naar het verkeerde WAN-zijde adres.
Als alle drie overeenkomen, is het probleem waarschijnlijk DNS-caching of bereikbaarheid op afstand in plaats van de updatewaarde. Als het DDNS-record overeenkomt met de router maar niet met het externe adres, onderzoek dan upstream NAT; als het met geen van beide overeenkomt, controleer dan de updaterconfiguratie en logs.
Identificeer Hoe de Updater het Adres Detecteert
Bepaal of de DDNS-client een benoemd interface leest, de router bevraagt, een lokale gateway analyseert, het bronadres van het updateverzoek gebruikt, of een externe “wat is mijn IP” service raadpleegt.
Een Zyxel community-discussie vraagt waarom een firewall achter een andere NAT-router het echte publieke adres niet automatisch kan bijwerken wanneer het alleen het upstream privé WAN-adres kent.
Kies externe detectie wanneer de updater achter NAT zit en de provider dit ondersteunt. Kies interface-detectie alleen wanneer dat interface daadwerkelijk het publieke adres bezit; anders kan een perfect functionerende updater door ontwerp de verkeerde waarde publiceren.
Controleer op Dubbele NAT en CGNAT
Controleer of het WAN-adres van de router binnen een privé- of gedeeld bereik valt en of een andere modem of ISP-gateway de eerste NAT uitvoert. Dynamic DNS kan een adres publiceren, maar kan geen inkomende forwarding creëren via een upstream netwerk dat u niet beheert.
Een Duits Synology support-forum geval meldde dat provider NAT ervoor zorgde dat DDNS een adres detecteerde dat niet het daadwerkelijke publieke eindpunt was.
Als u de upstream router beheert, zet dan de downstream router in bridge-modus of stuur het vereiste pad door beide lagen. Als de ISP CGNAT gebruikt, vraag dan een publiek adres aan of gebruik een uitgaande tunnel of relay in plaats van de DDNS-client steeds te wijzigen.
Scheid IPv4- en IPv6-updates
Controleer de A- en AAAA-records onafhankelijk en vergelijk elk met een externe test voor dezelfde adresfamilie. Ga er niet vanuit dat één succesvolle IPv6-update bewijst dat het IPv4-record correct is.
Een client die is geconfigureerd om één interface te monitoren kan een tijdelijk IPv6-adres publiceren, een gedelegeerd prefix-adres dat later verandert, of een IPv4-adres van een VPN-uitgang. Houd aparte update-taken en providerrecords aan wanneer de adresfamilies verschillende levenscycli hebben.
Schakel alleen de verdachte adresfamilie-update uit en herhaal de test. Als de externe toegang herstelt wanneer het onjuiste AAAA- of A-record wordt verwijderd, herstel dan dat pad voordat u dual-stack DNS herstelt.
Vind Dubbele Clients en Verkeerde Recorddoelen
Maak een lijst van elke router, NAS, container, script, cloudhost en mobiel apparaat dat bevoegdheden heeft om het hostname bij te werken. Twee geldige clients op verschillende locaties kunnen elkaar herhaaldelijk overschrijven.
Dynu-gebruikers hebben gevallen gedocumenteerd waarbij één updateclient meerdere records hetzelfde IP lieten delen omdat de account- of clientconfiguratie meer records richtte dan bedoeld.
Geef elke locatie en adresfamilie een uniek hostname, token en update-taak. Intrek ongebruikte bevoegdheden en bevestig dat de log de exacte record noemt die wordt gewijzigd voordat u een succesbericht vertrouwt.
Valideer het Record Door een Echte Adreswijziging
Na het corrigeren van de detectiemethode en updater-eigendom, forceer een veilige WAN-herverbinding of wacht op de volgende legitieme adreswijziging. Noteer het nieuwe externe adres, update-log, gezaghebbend DNS-antwoord, recursief resolver-antwoord en het resultaat van de externe verbinding.
De ZimaSpace-gids over waarom externe toegang oude IP-status volgt biedt de volgende stap nadat de DDNS-waarde zelf correct is geworden.
Het probleem is pas opgelost wanneer één goedgekeurde updater het correcte IPv4- of IPv6-adres publiceert, geen tweede client het overschrijft, het gezaghebbende antwoord binnen het verwachte interval verandert, en een externe client de bedoelde thuisdienst bereikt.
Ondersteuning & Tips
Meer om te lezen

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

