Un URL diretto funzionante circoscrive il problema al percorso di avvio
Se un'applicazione si apre quando si inseriscono l'IP host e la porta, il container, la pubblicazione della porta e il percorso LAN di base stanno già funzionando. Il problema è più probabilmente nell'URL generato dal riquadro di ZimaOS, nella gestione del link da parte del browser o in metadati dell'applicazione temporaneamente obsoleti.
La risposta della community ipotizzava che il launcher fosse stato caricato prima di Docker e avesse conservato un percorso non aggiornato. È plausibile, ma non è stato dimostrato: l'utente aveva già riavviato Docker e il gestore delle app, un riavvio completo non aveva risolto subito il problema e i riquadri hanno iniziato a funzionare circa un giorno dopo. Durante la diagnosi del link, mantenete quindi questa incertezza.
Confrontate la destinazione del riquadro con l'indirizzo funzionante noto
Fate clic con il pulsante destro del mouse sul riquadro e copiate l'indirizzo del link senza aprirlo. Confrontate schema, hostname, IP, porta e percorso con l'URL inserito manualmente che funziona. Una porta errata o un vecchio indirizzo host indicano metadati dell'app obsoleti; una differenza tra HTTP e HTTPS indica una gestione del proxy o della sicurezza del browser.
Aprite l'URL del riquadro copiato in una nuova scheda. Se non funziona e il browser mostra un errore, annotate l'esito esatto. Se il clic non apre alcuna scheda, verificate il blocco dei popup, il filtraggio delle estensioni e la stessa dashboard in una finestra privata o in un altro browser.
Non modificate il networking dei container prima di aver completato questo confronto. Se l'indirizzo copiato dal riquadro è corretto e funziona quando viene incollato, il problema riguarda l'evento di clic della dashboard o il profilo del browser. Se l'indirizzo copiato è errato, il problema è a monte, nei metadati del launcher.
Aggiornate prima solo i livelli client e metadati
Ricaricate la dashboard senza usare la cache, disconnettetevi e accedete di nuovo, quindi provate un profilo del browser pulito. Disattivate una alla volta le estensioni che modificano le pagine o proteggono la privacy per l'origine ZimaOS locale. Questi controlli reversibili dovrebbero precedere il riavvio dei servizi host.
Se ogni client pulito riceve lo stesso URL errato dal riquadro, annotate il nome dell'app, la porta visualizzata, l'indirizzo copiato, l'indirizzo funzionante e la versione di ZimaOS. Riavviate una volta l'app e lasciate alla dashboard il tempo di rilevarla nuovamente. Eseguite quindi un solo riavvio ordinato di ZimaOS come verifica, non come prova di una soluzione.
Evitate di scollegare l'alimentazione mentre l'archiviazione è attiva. L'utente originale aveva provato una rimozione completa dell'alimentazione senza un ripristino immediato, quindi non dovrebbe essere il passaggio successivo predefinito. Non cancellate i dati dell'app e non reinstallate i container se i relativi URL diretti continuano a funzionare.
Verificate lo stato del container solo se anche il percorso diretto inizia a non funzionare
Controllate lo stato dell'applicazione e la porta pubblicata in ZimaOS. Se l'accesso diretto rimane funzionante, fermatevi al confine del launcher. Se anche l'accesso diretto non funziona più, esaminate il primo errore rilevante nei log del container e confermate che la porta sia ancora associata all'interfaccia host prevista.
Provate un'app interessata e una non interessata. Un singolo riquadro con una porta obsoleta suggerisce metadati specifici dell'app, mentre il malfunzionamento di tutti i riquadri in un solo browser suggerisce un problema client. Il malfunzionamento di tutti i riquadri su più client dopo un aggiornamento è un indizio più forte a carico del gestore delle app o del livello dashboard.
Dopo ogni ripristino, ripetete il test del clic originale nello stesso browser, dopo aver ricaricato la dashboard e dopo un normale riavvio. Il ripristino significa che il riquadro apre costantemente lo stesso indirizzo dell'URL diretto funzionante, non semplicemente che lo stato del container risulta “in esecuzione”.
Segnalate il problema con i due URL invece di ripristinare il sistema
Se il problema si ripresenta, acquisite l'URL copiato dal riquadro e quello funzionante inserito manualmente, oscurando se necessario i dettagli privati dell'host. Includete data e ora, nome dell'app, browser, estensioni, versione di ZimaOS e indicate se un altro client si comporta allo stesso modo.
Segnalate se il problema è comparso dopo un aggiornamento dell'app, una modifica della porta, un cambio dell'indirizzo host, una configurazione del proxy o un aggiornamento di ZimaOS. Questi fattori aiutano l'assistenza a riprodurre la mappatura obsoleta invece di aspettare che si risolva nuovamente da sola.
Fermatevi prima di eseguire un ripristino alle impostazioni di fabbrica, eliminare l'app o effettuare una pulizia generale di Docker mentre l'accesso diretto funziona. La discussione originale si è conclusa con un ripristino spontaneo e senza una causa confermata, quindi una riparazione distruttiva eliminerebbe prove senza intervenire su un guasto verificato.
Domande frequenti
Il riavvio di Docker ricrea tutti i link delle app di ZimaOS?
La discussione non lo dimostra. L'utente ha riavviato Docker e il gestore delle app, ma il problema è rimasto temporaneamente.
Perché incollare l'URL del riquadro funziona mentre il clic no?
Questo risultato circoscrive il problema alla gestione dei clic da parte del browser, alle estensioni o a JavaScript della dashboard. Provate una finestra privata e un altro browser prima di modificare il server.
Devo reinstallare l'app interessata?
Non mentre l'URL diretto funziona e i dati sono integri. Confrontate prima gli indirizzi e raccogliete le prove relative al launcher.
Le osservazioni originali e la cronologia ancora irrisolta sono disponibili nella discussione sui riquadri delle app di ZimaOS.
