Solución de la comunidad

Cómo corregir los errores de extracción de Docker en ZimaOS causados por espejos de registro

Community reports from Ireland and the United States about Docker proxy fallback errors, followed by a ZimaOS team clarification that Docker Hub is attempted before the proxy.

Un usuario de ZimaOS en Irlanda informó que, en ocasiones, las descargas de imágenes de Docker llegaban a dominios proxy regionales como ghcr.1panel.live o daocloud.io, incluso después de intentar borrar la configuración. Las descargas afectadas fallaban con errores de certificado TLS o de acceso regional, en lugar de completarse a través del registro oficial esperado.

Las primeras respuestas describieron estos proxies como espejos forzados, pero una respuesta posterior del equipo de ZimaOS añadió una corrección importante: ZimaOS intenta primero usar Docker Hub y solo utiliza un proxy después de que esa descarga falla. Por tanto, el hilo documenta un problema en la ruta de respaldo y una solicitud de control de «solo registros oficiales», no una prueba de que todas las descargas de imágenes se envíen desde el principio a un proxy regional.

Lo que experimentó el usuario en Irlanda

lucslav informó de fallos repetidos al instalar imágenes de Docker mientras utilizaba ZimaOS en Irlanda. El comportamiento aparecía tanto a través de la interfaz gráfica como mediante descargas iniciadas desde la terminal, y los intentos manuales de borrar la configuración del espejo no parecían aplicar el cambio de forma permanente.

El error más específico copiado en el hilo fue:

tls: failed to verify certificate: x509: certificate signed by unknown authority

La solicitud fallida mencionaba dominios proxy o de espejos, en lugar de únicamente el registro oficial de imágenes esperado. Como desde la ubicación del usuario era más fiable conectarse directamente a los registros oficiales, lucslav solicitó una forma permanente de desactivar estas rutas regionales.

Los otros dos errores comunicados posteriormente

En un mensaje posterior, lucslav recordó haber visto otros dos tipos de mensajes. Uno indicaba que el servicio solo estaba disponible en China continental. El otro señalaba que el certificado había caducado o aún no era válido.

Estos mensajes reforzaron la opinión del usuario de que el punto de acceso alternativo no era adecuado para todas las regiones. Una respuesta de restricción regional impide utilizar el servicio fuera de su área prevista, mientras que un certificado caducado o aún no válido impide confiar en la conexión TLS.

La solicitud de cambio de producto se mantuvo sencilla durante todo el debate: añadir un ajuste que permita a los usuarios desactivar los espejos regionales y exigir conexiones directas a registros oficiales como GitHub Container Registry y Docker Hub.

Cómo interpretó gelbuilding el fallo

gelbuilding coincidió en que el comportamiento informado no parecía una pérdida normal de conectividad a internet. Su interpretación fue que la solicitud de Docker llegaba a un espejo del registro cuyo certificado no podía validarse, lo que provocaba que Docker detuviera la descarga.

Después de que lucslav añadiera los mensajes sobre la disponibilidad exclusiva en China continental y la validez del certificado, gelbuilding consideró que el propio punto de acceso era la rama que estaba fallando. Desde esta perspectiva, los espejos ya no mejoraban la fiabilidad para los usuarios europeos, sino que provocaban un fallo grave de instalación.

La solución de interfaz propuesta era una opción similar a Usar solo registros oficiales. En el hilo no se proporcionó ninguna opción de ese tipo ni un procedimiento de configuración confirmado, por lo que la respuesta debe entenderse como una sugerencia de producto y no como un paso disponible.

Se informó de un fallo similar desde Estados Unidos

Más tarde, connorb se unió al debate desde Estados Unidos después de recibir un error similar al intentar instalar una imagen de Docker. Esto demostró que el problema descrito en el hilo no se limitaba a la ubicación del usuario original en Irlanda.

Captura de pantalla de un error de instalación de una imagen de Docker en ZimaOS compartida por un usuario de Estados Unidos
Captura de pantalla de la comunidad: el fallo similar de instalación de una imagen de Docker compartido por connorb.

connorb preguntó si existía alguna solución alternativa. lucslav respondió que no había encontrado ninguna y sugirió buscar otra imagen cuando fuera posible. El debate no determinó si esa imagen alternativa utilizaría otro registro, otro propietario del repositorio o un paquete de aplicación diferente.

El equipo de ZimaOS aclaró el orden de las descargas

raller1028 añadió la aclaración más importante sobre el funcionamiento cerca del final del hilo: cuando ZimaOS descarga una imagen, primero intenta obtenerla a través de Docker Hub. El proxy solo se prueba cuando la descarga original falla.

Esto cambia la forma en que deben interpretarse los informes anteriores. Los miembros de la comunidad experimentaron fallos relacionados con el proxy, pero la respuesta del equipo indica que el proxy era una ruta de respaldo y no el destino inicial de todas las descargas.

La aclaración también deja una pregunta sin respuesta: ¿por qué falló la solicitud original a Docker Hub antes de que el sistema pasara al proxy? El hilo no contiene registros ni pruebas posteriores que permitan determinar si el primer fallo se debió a conectividad, autenticación, limitación de solicitudes, disponibilidad de la imagen, DNS u otra condición.

Lo que el debate no resolvió

Ningún participante proporcionó un método permanente confirmado para desactivar el respaldo mediante proxy. lucslav informó de que los intentos manuales de borrar la configuración no persistían, pero la publicación no incluía el archivo, ajuste o servicio exacto implicado.

El hilo tampoco confirmó que el certificado hubiera caducado en todos los casos. Se debatieron tres mensajes diferentes: autoridad certificadora desconocida, certificado caducado o aún no válido y restricción de disponibilidad exclusiva en China continental. Es posible que correspondan a distintos puntos de acceso proxy o a diferentes etapas del proceso de respaldo.

Por último, en este debate no se publicó ninguna versión final de ZimaOS, ajuste ni solución alternativa. El resultado concreto fue una solicitud de producto: ofrecer una política persistente de conexión directa para las regiones donde los espejos regionales sean innecesarios o inaccesibles.

Información que conviene conservar al informar del mismo problema

La publicación original fue útil porque incluía la región del usuario, los nombres de host del proxy, el hecho de que tanto la interfaz como la terminal estaban afectadas y el mensaje exacto de x509. Las respuestas posteriores añadieron otras dos condiciones de error visibles y un informe similar desde otro país.

Por ello, un informe de seguimiento útil debería conservar el mismo tipo de pruebas: versión de ZimaOS, país o región, referencia original de la imagen, si la descarga comenzó en la interfaz o en la terminal, el fallo inicial del registro oficial, el nombre de host de respaldo y el mensaje completo del certificado o de la restricción regional.

Esa información permitiría al equipo de ZimaOS distinguir entre una descarga fallida del registro oficial y un fallo del respaldo mediante proxy. Los usuarios pueden consultar la guía de aplicaciones Docker de ZimaOS existente para conocer el flujo normal de instalación.

Preguntas frecuentes del debate de la comunidad

¿Eran los espejos regionales la primera ruta de descarga?

Según la respuesta del equipo de ZimaOS, no. ZimaOS intenta primero descargar la imagen a través de Docker Hub y solo prueba el proxy después de que esa descarga falla.

¿Qué errores se comunicaron realmente?

El hilo incluye un error de autoridad certificadora desconocida, un mensaje recordado sobre un certificado caducado o aún no válido y un mensaje que indicaba que el servicio solo estaba disponible en China continental.

¿El debate proporcionó un interruptor para desactivar los proxies?

No. El interruptor «Usar solo registros oficiales» fue una solicitud de funcionalidad de los miembros de la comunidad, no un ajuste existente demostrado en el hilo.

¿Se confirmó alguna solución alternativa?

No se confirmó ninguna solución permanente. Un participante sugirió buscar una imagen alternativa, mientras que la aclaración del equipo explicó el orden de descarga: primero el registro oficial y después el proxy.

¿El problema se limitaba a Europa?

No. El informe original procedía de Irlanda, pero posteriormente otro usuario comunicó un error similar de instalación de una imagen de Docker desde Estados Unidos.