Een werkende directe URL beperkt de fout tot het startpad
Als een applicatie opent wanneer je het IP-adres en de poort van de host invoert, functioneren de container, de gepubliceerde poort en de basisroute binnen het LAN al. Het probleem zit waarschijnlijker in de URL die door de ZimaOS-tegel wordt gegenereerd, de manier waarop de browser die link verwerkt of tijdelijk verouderde applicatiemetadata.
In het communityantwoord werd voorgesteld dat de launcher vóór Docker werd geladen en een verouderde route behield. Dat is plausibel, maar niet bewezen: de gebruiker had Docker en de applicatiebeheerder al opnieuw gestart, een volledige herstart hielp niet meteen en de tegels begonnen ongeveer een dag later weer te werken. Houd die onzekerheid in stand terwijl je de link zelf onderzoekt.
Vergelijk de bestemming van de tegel met het bekende werkende adres
Klik met de rechtermuisknop op de tegel en kopieer het linkadres zonder het te openen. Vergelijk het schema, de hostnaam, het IP-adres, de poort en het pad met de handmatig ingevoerde URL die wel werkt. Een verkeerde poort of een oud hostadres wijst op verouderde applicatiemetadata; een verschil tussen HTTP en HTTPS wijst op verwerking door de proxy of browserbeveiliging.
Open de gekopieerde tegel-URL in een nieuw tabblad. Als dat mislukt met een zichtbare browserfout, noteer dan het exacte resultaat. Als er helemaal geen tabblad wordt geopend, test dan blokkering van pop-ups, filtering door extensies en hetzelfde dashboard in een privévenster of een andere browser.
Pas de containernetwerken niet aan voordat deze vergelijking is voltooid. Als het gekopieerde tegeladres correct is en werkt wanneer je het plakt, zit het probleem in de klikgebeurtenis van het dashboard of in het browserprofiel. Als het gekopieerde adres onjuist is, zit het probleem hogerop in de metagegevens van de launcher.
Vernieuw eerst alleen de client- en metadatalagen
Laad het dashboard opnieuw zonder cache, meld je af en weer aan en test een schoon browserprofiel. Schakel extensies die de pagina aanpassen of de privacy beschermen één voor één uit voor de lokale ZimaOS-origin. Deze omkeerbare controles moeten voorafgaan aan het opnieuw starten van hostservices.
Als elke schone client dezelfde onjuiste tegel-URL ontvangt, noteer dan de naam van de app, de weergegeven poort, het gekopieerde adres, het werkende adres en de ZimaOS-versie. Start de app één keer opnieuw en geef het dashboard tijd om de app opnieuw te detecteren. Voer daarna één ordelijke herstart van ZimaOS uit als verificatiemoment, niet als bewijs dat het probleem is opgelost.
Haal de stroom niet uit het apparaat terwijl de opslag actief is. De oorspronkelijke gebruiker heeft de stroom volledig verwijderd zonder direct herstel, dus dit moet niet standaard als volgende stap worden aanbevolen. Wis geen appgegevens en installeer containers niet opnieuw zolang hun directe URL's nog werken.
Controleer de containerstatus alleen als het directe pad ook begint te falen
Controleer de applicatiestatus en de gepubliceerde poort in ZimaOS. Als directe toegang goed blijft werken, stop dan bij de launchergrens. Als directe toegang nu ook mislukt, bekijk dan de eerste relevante fout in het containerlog en controleer of de poort nog steeds aan de verwachte hostinterface is gekoppeld.
Test één getroffen app en één niet-getroffen app. Eén tegel met een oude poort wijst op app-specifieke metadata, terwijl alle tegels die in één browser falen op een clientprobleem wijzen. Als alle tegels in alle clients na een update falen, is dat sterker bewijs voor een probleem in de applicatiebeheerder of dashboardlaag.
Voer na herstel de oorspronkelijke kliktest opnieuw uit in dezelfde browser, na het opnieuw laden van het dashboard en na één normale herstart. Herstel betekent dat de tegel consequent hetzelfde adres opent als de bekende werkende directe URL, niet alleen dat de containerstatus “actief” vermeldt.
Escaleer met de twee URL's in plaats van het systeem te resetten
Als het probleem terugkeert, leg dan de gekopieerde tegel-URL en de handmatig werkende URL vast, waarbij je privéhostgegevens indien nodig redigeert. Vermeld tijdstippen, de naam van de app, de browser, extensies, de ZimaOS-versie en of een andere client hetzelfde gedrag vertoont.
Meld of het probleem ontstond na een app-update, poortwijziging, wijziging van het hostadres, proxyconfiguratie of een ZimaOS-upgrade. Met die aanleidingen kan support het verouderde koppelingsprobleem proberen te reproduceren in plaats van te wachten tot het opnieuw vanzelf verdwijnt.
Stop voordat je de fabrieksinstellingen herstelt, de app verwijdert of Docker breed opschoont zolang directe toegang werkt. De oorspronkelijke thread eindigde met spontaan herstel en zonder bevestigde oorzaak, dus destructief herstel zou bewijsmateriaal vernietigen zonder een geverifieerde fout aan te pakken.
Veelgestelde vragen
Rebuildt het opnieuw starten van Docker elke ZimaOS-appkoppeling?
De thread bewijst dat niet. De gebruiker heeft Docker en de applicatiebeheerder opnieuw gestart, maar het probleem bleef tijdelijk bestaan.
Waarom werkt het plakken van de tegel-URL wel wanneer klikken niet werkt?
Dat resultaat beperkt het probleem tot klikverwerking door de browser, extensies of JavaScript van het dashboard. Test een privévenster en een andere browser voordat je de server wijzigt.
Moet ik de getroffen app opnieuw installeren?
Niet zolang de directe URL werkt en de gegevens intact zijn. Vergelijk eerst de adressen en verzamel bewijsmateriaal over de launcher.
De oorspronkelijke observaties en de onopgeloste tijdlijn staan in de discussie over ZimaOS-apptegels.
