Conclusión: comprueba la ruta predeterminada antes de reinstalar contenedores
En el caso real de la versión 1.6.2, Jellyfin, Vaultwarden y otras aplicaciones parecían no iniciarse, no se podía abrir la configuración, los servicios que dependían de DNS fallaban y algunos contenedores solo aparecían después de mucho tiempo. La evidencia decisiva no apuntaba a una corrupción de Docker: la ruta predeterminada con la métrica más baja apuntaba a 192.168.1.0 en lugar de a la puerta de enlace real, 192.168.1.1. Una vez corregida la puerta de enlace en la interfaz gráfica, se recuperaron la conectividad externa y la pila de aplicaciones.
Primero comprueba si los contenedores realmente están detenidos
docker ps -a
docker info | grep -iE 'Docker Root Dir|Storage Driver'
docker stats --no-streamSi los contenedores están en estado Created, Restarting o Exited, revisa sus registros. Si están ejecutándose, pero sus interfaces web dependen de DNS, Cloudflare o API remotas, el fallo puede deberse a la accesibilidad de la red y no al inicio del contenedor.
Después comprueba las rutas predeterminadas del host
ip route show default
ip route
El caso de origen mostró varias rutas predeterminadas, y la incorrecta tenía la métrica más baja, por lo que Linux la prefería. Las métricas de rutas de Linux explican esta regla de enrutamiento.
Prueba por separado la IP directa y el DNS
ping -c 3 1.1.1.1
getent hosts cloudflare.com
curl -I https://example.comSi 1.1.1.1 falla, corrige el enrutamiento antes que el DNS. Si la IP directa funciona, pero fallan los nombres, revisa el DNS. Así evitarás diagnosticar erróneamente una puerta de enlace defectuosa como un problema de Pi-hole, Cloudflare o el DNS de Docker.
Corrige la interfaz de red en ZimaOS
Abre Ajustes → Red, selecciona la interfaz que transporta la ruta predeterminada y verifica la IP estática, la subred, la puerta de enlace y el DNS. Las versiones actuales de ZimaOS muestran cada puerto Ethernet físico por separado. Los ajustes de red de ZimaOS representan el modelo de configuración actual.
La red de aplicaciones de ZimaOS cubre la capa de aplicaciones.
Por qué una puerta de enlace incorrecta puede hacer parecer que falló la mitad de las aplicaciones
Las aplicaciones que solo tienen dependencias locales pueden iniciarse de inmediato. Otras esperan a los registros de imágenes, el DNS, bases de datos remotas, servicios de certificados o API en la nube. Por tanto, un host con conectividad de red parcial genera un conjunto de síntomas mixtos que parece aleatorio. Corregir cada contenedor por separado hace perder tiempo cuando la dependencia compartida es la ruta del host.
La versión 1.6.2 fue una actualización de seguridad y compatibilidad
Las notas oficiales de la versión 1.6.2 se centran en la seguridad de cuentas, archivos y mensajería, el refuerzo de SSH, cambios en el kernel y los controladores, correcciones de USB y correcciones de RAID; no documentan ningún cambio intencionado en la puerta de enlace. El caso de origen debe tratarse como una posible regresión de migración de la configuración de red, no como un comportamiento diseñado. Los cambios de ZimaOS 1.6.2 proporcionan la referencia oficial.
Actualiza a la versión estable actual antes de investigar errores antiguos de la 1.6.2
Más adelante, ZimaOS 1.7.1 mejoró la eficiencia del inicio de Docker, la red de Docker durante la instalación, la gestión dinámica de URL y el comportamiento de la tienda de aplicaciones. Si el sistema todavía usa la versión 1.6.2, haz una copia de seguridad de los datos importantes y cambia a la rama estable actual antes de asumir que el mismo error antiguo sigue presente.
La copia de seguridad de ZimaOS es la capa de seguridad.
Revertir significa iniciar desde la ranura A/B alternativa, no degradar arbitrariamente
La documentación pública de recuperación actual describe el inicio desde la ranura del sistema alternativa cuando falla la ranura actual. No promete una degradación compatible con un solo clic a cualquier versión histórica. La recuperación del sistema de ZimaOS es la vía de recuperación actual similar a una reversión.
Si el enrutamiento está corregido, pero la resolución de nombres sigue fallando, compara el servidor DNS configurado con un resolvedor independiente. Las pruebas de DNS de Cloudflare pueden ayudar a demostrar si el fallo restante es específico del resolvedor y no un problema de inicio de Docker.
Preguntas frecuentes
¿Por qué fallaron solo algunas aplicaciones después de la versión 1.6.2?
Las aplicaciones con dependencias de DNS o de red externas pueden fallar mientras los contenedores completamente locales siguen ejecutándose.
¿Cómo sé si la puerta de enlace predeterminada es incorrecta?
Usa ip route y confirma que la ruta predeterminada con la métrica más baja apunta a la dirección real del router.
¿Debería reinstalar primero Jellyfin o Vaultwarden?
No, hasta verificar el enrutamiento del host, el DNS y el estado de los contenedores.
¿Puedo revertir ZimaOS a cualquier versión anterior?
La recuperación pública actual se centra en iniciar desde la ranura A/B alternativa, en lugar de degradar arbitrariamente a una versión histórica.
¿Debería mantenerme en la versión 1.6.2?
Si es posible, haz una copia de seguridad y cambia a la versión estable actual; después, vuelve a probar cualquier problema restante.
