Un error NXDOMAIN no siempre significa que el dispositivo ZimaOS tenga problemas de DNS. En este caso de enero de 2026, el ZimaBoard 2 del usuario funcionaba normalmente en la red local, pero ZimaOS Plus Remote Access nunca generaba una URL pública y ZimaClient permanecía en Device connection not ready.
El usuario restableció el ID de red, reinició el dispositivo, cerró y volvió a iniciar sesión, e incluso probó una versión alfa 1.5.4. Ninguno de esos pasos restableció el enlace remoto nativo.
El fallo estaba en el aprovisionamiento remoto, no en el acceso local
El caso original presentaba tres síntomas relacionados:
- no aparecía ninguna URL pública
zimaos.linkbajo el ID remoto; - al abrir el enlace remoto esperado se devolvía NXDOMAIN;
- ZimaClient permanecía en un bucle de conexión e informaba que la conexión con el dispositivo no estaba lista.
Mientras tanto, el ZimaBoard seguía siendo accesible mediante la IP local y continuaba ofreciendo otros servicios locales no relacionados.
Actualizar a la versión alfa 1.5.4 no lo solucionó
Un miembro de la comunidad sugirió probar una versión alfa. El autor original lo hizo, restableció nuevamente el ID de red y reprodujo el mismo fallo de acceso remoto. Esto constituye una evidencia negativa útil: en este caso, pasar de la versión 1.5.3 a esa versión alfa no solucionó el aprovisionamiento.
Los comandos de actualización antiguos de la comunidad mediante curl | sh no se repiten aquí intencionadamente. No fueron publicados por una cuenta del equipo de IceWhale en este hilo y hacen referencia a versiones históricas.
El DNS, la hora, el enrutamiento y HTTPS básicos funcionaban correctamente
Los resultados posteriores de diagnóstico fueron especialmente informativos. El ZimaBoard podía resolver dominios normales, hacer ping a IP públicas, usar una ruta predeterminada válida, sincronizar la hora mediante NTP y acceder a puntos de conexión HTTPS públicos. Ninguna unidad de systemd fallida ni un bloqueo evidente del cortafuegos de salida explicaba la ausencia de la URL remota.
Esto acota considerablemente el problema. Hace que la explicación genérica de «tu DNS está roto» resulte mucho menos convincente, aunque el síntoma observado en el navegador fuera NXDOMAIN.
La pista más importante fueron los errores 401 de JWT repetidos
Los registros del usuario mostraban repetidamente respuestas HTTP 401 con el mensaje invalid or expired jwt mientras el sistema intentaba comunicarse con el backend de ZimaOS.
Un miembro de la comunidad interpretó esto como un fallo de autenticación con el backend o del proceso de registro del ID remoto. La evidencia es sólida, pero el hilo no contiene la confirmación de un ingeniero de IceWhale sobre la causa en el servidor, por lo que debe considerarse un diagnóstico de la comunidad y no una declaración oficial sobre el incidente.
El usuario creó una solución alternativa independiente para Immich
Como el acceso remoto nativo seguía sin estar disponible, el usuario expuso Immich mediante el reenvío de puertos del router y DuckDNS. Esto restableció el acceso de la familia a Immich desde el navegador, pero no reparó el ID remoto de ZimaOS.
Exponer directamente una aplicación a internet cambia su modelo de seguridad. No copies esta solución sin comprender TLS, la autenticación, las actualizaciones de la aplicación, las reglas del cortafuegos y si tu ISP proporciona una dirección pública accesible.
El acceso remoto actual de ZimaOS utiliza el flujo de conexión de ZimaClient
El ZimaOS actual describe el acceso remoto como un canal cifrado de igual a igual configurado mediante ZimaClient y controlado por el ajuste de Acceso remoto. Si un sistema actual no puede establecer ese canal, compara el dispositivo con el flujo de conexión actual del acceso remoto antes de aplicar pasos de solución de problemas de un hilo de la época de la versión 1.5.3.
El ZimaOS actual también considera que el ID de red es información confidencial de conexión. Evita publicarlo en capturas de pantalla o publicaciones de soporte.
Preguntas frecuentes sobre el ID remoto de ZimaOS
¿NXDOMAIN demuestra que el solucionador DNS local está averiado?
No. En este caso de origen, la resolución DNS normal funcionaba correctamente, mientras que el propio registro remoto de ZimaOS nunca se publicó.
¿Restablecer el ID de red solucionó el problema?
No. El usuario generó nuevos ID varias veces sin obtener una URL pública.
¿Cuál fue la pista técnica más importante?
Respuestas HTTP 401 repetidas del backend que indicaban un JWT no válido o caducado, mientras el DNS, la hora, el enrutamiento y la conectividad HTTPS normales funcionaban correctamente.
¿IceWhale confirmó oficialmente un problema con el JWT del backend?
No. Esa conclusión procedía del análisis de la comunidad sobre los registros del usuario. El hilo publicado no incluía un diagnóstico oficial del lado del servidor.
