Un utente di ZimaOS in Irlanda ha riferito che i download delle immagini Docker raggiungevano talvolta domini proxy regionali come ghcr.1panel.live o daocloud.io, anche dopo aver tentato di cancellare la configurazione. I download interessati fallivano con errori relativi ai certificati TLS o all'accesso regionale, invece di completarsi tramite il registro ufficiale previsto.
Inizialmente le risposte descrivevano questi proxy come mirror obbligatori, ma una successiva risposta del team ZimaOS ha aggiunto un'importante precisazione: ZimaOS prova prima a utilizzare Docker Hub e ricorre a un proxy solo dopo il fallimento di quel download. La discussione documenta quindi un problema del percorso di fallback e una richiesta di controllo “solo registri ufficiali”, non dimostra che ogni download di immagini venga inviato fin dall'inizio a un proxy regionale.
Cosa ha sperimentato l'utente in Irlanda
lucslav ha segnalato ripetuti errori durante l'installazione di immagini Docker usando ZimaOS in Irlanda. Il comportamento si verificava sia tramite l'interfaccia grafica sia tramite i download eseguiti dal terminale, e i tentativi manuali di cancellare la configurazione dei mirror non sembravano rendere permanente la modifica.
L'errore più specifico copiato nella discussione era:
tls: failed to verify certificate: x509: certificate signed by unknown authorityLa richiesta non riuscita indicava domini proxy o mirror anziché soltanto il registro ufficiale delle immagini previsto. Poiché dalla posizione dell'utente la connessione diretta ai registri ufficiali risultava più affidabile, lucslav ha chiesto un modo permanente per disattivare questi percorsi regionali.
I due ulteriori errori segnalati in seguito
In un messaggio successivo, lucslav ha ricordato di aver visualizzato altri due tipi di messaggi. Uno indicava che il servizio era disponibile soltanto nella Cina continentale. L'altro affermava che il certificato era scaduto o non era ancora valido.
Questi messaggi hanno rafforzato l'idea dell'utente che l'endpoint di fallback non fosse adatto a tutte le regioni. Una risposta relativa alle restrizioni geografiche impedisce l'utilizzo del servizio al di fuori dell'area prevista, mentre un certificato scaduto o non ancora valido impedisce di considerare affidabile la connessione TLS.
La modifica al prodotto richiesta è rimasta semplice per tutta la discussione: aggiungere un'impostazione che consenta agli utenti di disattivare i mirror regionali e obblighi le connessioni dirette ai registri ufficiali, come GitHub Container Registry e Docker Hub.
Come gelbuilding ha interpretato il problema
gelbuilding ha concordato sul fatto che il comportamento segnalato non sembrasse una semplice perdita della connettività Internet. Secondo la sua interpretazione, la richiesta Docker raggiungeva un mirror del registro il cui certificato non poteva essere convalidato, causando l'interruzione del download da parte di Docker.
Dopo che lucslav ha aggiunto i messaggi relativi alla disponibilità limitata alla Cina continentale e alla validità del certificato, gelbuilding ha considerato l'endpoint stesso il ramo responsabile del fallimento. Da questo punto di vista, i mirror non miglioravano più l'affidabilità per gli utenti europei, ma causavano un errore irreversibile durante l'installazione.
La soluzione proposta per l'interfaccia era un'opzione simile a Usa solo registri ufficiali. Nella discussione non è stata fornita né confermata alcuna opzione di questo tipo o procedura di configurazione, quindi la risposta va intesa come un suggerimento per il prodotto e non come un passaggio attualmente disponibile.
Un errore simile è stato segnalato dagli Stati Uniti
Successivamente connorb ha partecipato alla discussione dagli Stati Uniti, dopo aver ricevuto un errore simile durante il tentativo di installare un'immagine Docker. Ciò ha dimostrato che il problema descritto nella discussione non era limitato alla posizione dell'utente originale in Irlanda.
connorb ha chiesto se esistesse una soluzione alternativa. lucslav ha risposto di non averne trovata una e ha suggerito, quando possibile, di cercare un'immagine alternativa. La discussione non ha stabilito se questa immagine alternativa avrebbe utilizzato un altro registro, un altro proprietario del repository o un pacchetto applicativo diverso.
Il team ZimaOS ha chiarito l'ordine dei tentativi
raller1028 ha aggiunto, verso la fine della discussione, la precisazione più importante sul comportamento: quando ZimaOS scarica un'immagine, tenta innanzitutto di recuperarla tramite Docker Hub. Il proxy viene utilizzato solo quando il download originale fallisce.
Questo modifica il modo in cui devono essere interpretate le segnalazioni precedenti. I membri della community hanno riscontrato errori legati al proxy, ma la risposta del team indica che il proxy era un percorso di fallback, non la destinazione iniziale di ogni download.
La precisazione lascia inoltre senza risposta una domanda: perché la richiesta iniziale a Docker Hub è fallita prima che il sistema passasse al proxy? La discussione non contiene log o test successivi che permettano di stabilire se il primo errore fosse dovuto a connettività, autenticazione, limitazioni di frequenza, disponibilità dell'immagine, DNS o ad altre condizioni.
Cosa non è stato risolto nella discussione
Nessun partecipante ha fornito un metodo permanente confermato per disattivare il fallback del proxy. lucslav ha riferito che i tentativi manuali di cancellare la configurazione non persistevano, ma nel post non erano indicati il file, l'impostazione o il servizio esatti coinvolti.
La discussione non ha inoltre confermato che il certificato fosse scaduto in ogni caso. Sono stati menzionati tre messaggi differenti: autorità di certificazione sconosciuta, certificato scaduto o non ancora valido e restrizione relativa alla disponibilità nella Cina continentale. Potrebbero riguardare endpoint proxy diversi o fasi differenti del processo di fallback.
Infine, nella discussione non sono stati pubblicati una versione definitiva di ZimaOS, un'impostazione o una soluzione alternativa. Il risultato concreto è stata una richiesta per il prodotto: rendere disponibile una politica persistente che consenta esclusivamente le connessioni dirette nelle regioni in cui i mirror regionali sono inutili o inaccessibili.
Informazioni da conservare quando si segnala lo stesso problema
Il post originale era utile perché includeva la regione dell'utente, i nomi degli host proxy, il fatto che fossero interessate sia l'interfaccia utente sia il terminale e il messaggio x509 completo. Le risposte successive hanno aggiunto altre due condizioni di errore visibili e una segnalazione simile proveniente da un altro Paese.
Un rapporto di follow-up utile dovrebbe quindi conservare lo stesso tipo di prove: versione di ZimaOS, Paese o regione, riferimento originale dell'immagine, indicazione se il download è iniziato dall'interfaccia o dal terminale, errore iniziale del registro ufficiale, nome dell'host di fallback e messaggio completo relativo al certificato o alla restrizione regionale.
Queste informazioni consentirebbero al team ZimaOS di distinguere un download ufficiale non riuscito da un fallback proxy non riuscito. Gli utenti possono consultare la guida alle applicazioni Docker di ZimaOS esistente per il normale flusso di installazione.
Domande frequenti dalla discussione della community
I mirror regionali erano il primo percorso di download?
Secondo la risposta del team ZimaOS, no. ZimaOS tenta innanzitutto di scaricare l'immagine tramite Docker Hub e prova il proxy solo dopo il fallimento di quel download.
Quali errori sono stati effettivamente segnalati?
La discussione include un errore relativo a un'autorità di certificazione sconosciuta, un messaggio ricordato relativo a un certificato scaduto o non ancora valido e un messaggio che indicava la disponibilità del servizio soltanto nella Cina continentale.
La discussione ha fornito un'opzione per disattivare i proxy?
No. L'opzione “Usa solo registri ufficiali” era una richiesta di funzionalità avanzata dai membri della community, non un'impostazione esistente dimostrata nella discussione.
È stata confermata una soluzione alternativa?
No, non è stata confermata alcuna soluzione permanente. Un partecipante ha suggerito di cercare un'immagine alternativa, mentre la precisazione del team ha spiegato l'ordine dei tentativi: prima il registro ufficiale e poi il proxy.
Il problema era limitato all'Europa?
No. La segnalazione originale proveniva dall'Irlanda, ma in seguito un altro utente ha riportato un errore simile durante l'installazione di un'immagine Docker dagli Stati Uniti.
