Um utilizador de ZimaOS na Irlanda relatou que as transferências de imagens Docker, por vezes, acediam a domínios proxy regionais como ghcr.1panel.live ou daocloud.io, mesmo depois de tentar limpar a configuração. As transferências afetadas falhavam com erros de certificado TLS ou de acesso regional, em vez de serem concluídas através do registo oficial esperado.
As respostas iniciais descreveram estes proxies como mirrors impostos, mas uma resposta posterior da equipa do ZimaOS acrescentou uma correção importante: o ZimaOS tenta primeiro utilizar o Docker Hub e só recorre a um proxy depois de essa transferência falhar. Assim, o tópico documenta um problema no percurso de fallback e um pedido de controlo “apenas registos oficiais”, não uma prova de que todas as transferências de imagens sejam enviadas desde o início para um proxy regional.
O que o utilizador na Irlanda experienciou
lucslav relatou falhas repetidas na instalação de imagens Docker ao utilizar o ZimaOS na Irlanda. O comportamento ocorria tanto através da interface gráfica como através de transferências iniciadas no terminal, e as tentativas manuais de limpar a configuração do mirror não pareciam tornar a alteração permanente.
O erro mais específico copiado para o tópico foi:
tls: failed to verify certificate: x509: certificate signed by unknown authorityO pedido que falhou mencionava domínios proxy ou mirror, em vez de apenas o registo oficial de imagens esperado. Como uma ligação direta aos registos oficiais era mais fiável na localização do utilizador, lucslav pediu uma forma permanente de desativar estes percursos regionais.
Os dois erros adicionais relatados mais tarde
Numa mensagem de seguimento, lucslav recordou ter visto dois outros tipos de mensagens. Uma indicava que o serviço estava disponível apenas na China continental. A outra informava que o certificado tinha expirado ou ainda não era válido.
Estas mensagens reforçaram a opinião do utilizador de que o endpoint de fallback não era adequado para todas as regiões. Uma resposta de restrição regional impede a utilização do serviço fora da área pretendida, enquanto um certificado expirado ou ainda não válido impede que a ligação TLS seja considerada fidedigna.
A alteração de produto solicitada manteve-se simples ao longo da discussão: adicionar uma definição que permita aos utilizadores desativar os mirrors regionais e exigir ligações diretas a registos oficiais, como o GitHub Container Registry e o Docker Hub.
Como gelbuilding interpretou a falha
gelbuilding concordou que o comportamento relatado não parecia resultar de uma simples perda de conectividade à Internet. A sua interpretação foi que o pedido Docker chegava a um mirror de registo cujo certificado não podia ser validado, fazendo com que o Docker interrompesse a transferência.
Depois de lucslav acrescentar as mensagens relativas à disponibilidade apenas na China continental e à validade do certificado, gelbuilding considerou o próprio endpoint como o ramo que estava a falhar. Nesta perspetiva, os mirrors já não melhoravam a fiabilidade para os utilizadores europeus; estavam a provocar uma falha total na instalação.
A solução de interface proposta consistia numa opção semelhante a Utilizar apenas registos oficiais. Nenhuma opção desse tipo, nem um procedimento de configuração confirmado, foi apresentado no tópico, pelo que a resposta deve ser entendida como uma sugestão de produto e não como um passo disponível.
Foi relatada uma falha semelhante nos Estados Unidos
Mais tarde, connorb participou na discussão a partir dos Estados Unidos, depois de receber um erro semelhante ao tentar instalar uma imagem Docker. Isto mostrou que o problema descrito no tópico não se limitava à localização do utilizador original, na Irlanda.
connorb perguntou se existia alguma solução alternativa. lucslav respondeu que não tinha encontrado nenhuma e sugeriu procurar uma imagem alternativa, quando possível. A discussão não esclareceu se essa imagem alternativa utilizaria outro registo, outro proprietário do repositório ou um pacote de aplicação diferente.
A equipa do ZimaOS esclareceu a ordem das transferências
raller1028 acrescentou, perto do final do tópico, o esclarecimento mais importante sobre o comportamento: quando o ZimaOS transfere uma imagem, tenta primeiro obtê-la através do Docker Hub. O proxy só é utilizado quando a transferência original falha.
Isto altera a forma como os relatos anteriores devem ser interpretados. Os membros da comunidade experienciaram falhas relacionadas com o proxy, mas a resposta da equipa indica que o proxy era um percurso de fallback, e não o destino inicial de todas as transferências.
O esclarecimento também deixa uma questão sem resposta: por que razão falhou o pedido original ao Docker Hub antes de o sistema passar para o proxy? O tópico não contém registos nem testes de seguimento que identifiquem se a primeira falha resultou de conectividade, autenticação, limitação de pedidos, disponibilidade da imagem, DNS ou outra condição.
O que a discussão não resolveu
Nenhum participante apresentou um método permanente confirmado para desativar o fallback através do proxy. lucslav indicou que as tentativas manuais de limpar a configuração não persistiam, mas o ficheiro, a definição ou o serviço exato envolvidos não foram incluídos na publicação.
O tópico também não confirmou que o certificado tivesse expirado em todos os casos. Foram discutidas três mensagens diferentes: autoridade de certificação desconhecida, certificado expirado ou ainda não válido, e restrição de disponibilidade apenas na China continental. Estas mensagens podem envolver endpoints proxy diferentes ou fases diferentes do processo de fallback.
Por fim, não foi publicada nesta discussão nenhuma versão final do ZimaOS, definição ou solução alternativa. O resultado concreto foi um pedido de produto: disponibilizar uma política persistente de ligação direta, apenas a registos oficiais, para regiões onde os mirrors regionais sejam desnecessários ou inacessíveis.
Informação que vale a pena preservar ao comunicar o mesmo problema
A publicação original foi útil porque incluía a região do utilizador, os nomes dos hosts proxy, o facto de tanto a interface como o terminal serem afetados e a mensagem x509 exata. As respostas posteriores acrescentaram mais duas condições de erro visíveis e um relato semelhante de outro país.
Assim, um relatório de seguimento útil deve preservar o mesmo tipo de dados: versão do ZimaOS, país ou região, referência original da imagem, indicação sobre se a transferência foi iniciada na interface ou no terminal, a primeira falha no registo oficial, o hostname de fallback e a mensagem completa relativa ao certificado ou à restrição regional.
Estas informações permitiriam à equipa do ZimaOS distinguir uma transferência oficial que falhou de um fallback através de um proxy que falhou. Os utilizadores podem consultar o guia de aplicações Docker do ZimaOS existente para obter o procedimento normal de instalação.
Perguntas frequentes da discussão da comunidade
Os mirrors regionais eram o primeiro percurso de transferência?
Segundo a resposta da equipa do ZimaOS, não. O ZimaOS tenta primeiro transferir a imagem através do Docker Hub e só utiliza o proxy depois de essa transferência falhar.
Que erros foram efetivamente relatados?
O tópico inclui um erro relativo a uma autoridade de certificação desconhecida, uma mensagem recordada sobre um certificado expirado ou ainda não válido e uma mensagem indicando que o serviço estava disponível apenas na China continental.
A discussão apresentou uma opção para desativar os proxies?
Não. A opção “Utilizar apenas registos oficiais” foi um pedido de funcionalidade dos membros da comunidade, não uma definição existente demonstrada no tópico.
Foi confirmada alguma solução alternativa?
Não foi confirmada nenhuma solução alternativa permanente. Um participante sugeriu encontrar uma imagem alternativa, enquanto o esclarecimento da equipa explicou a ordem de transferência: primeiro o registo oficial e depois o proxy.
O problema estava limitado à Europa?
Não. O relato original veio da Irlanda, mas outro utilizador relatou posteriormente um erro semelhante na instalação de uma imagem Docker a partir dos Estados Unidos.
