El problema de origen de marzo de 2026 era específico: ZimaClient podía detectar la relación con el servidor, pero fuera de la red doméstica la conexión permanecía en Conectando y finalmente agotaba el tiempo de espera. Se recibieron informes similares de usuarios de varios países, y el personal de IceWhale dijo que estaba optimizando activamente el porcentaje de conexiones remotas exitosas y envió de forma privada un paquete de prueba a voluntarios.
Ese paquete de prueba es histórico y privado. Los usuarios actuales deben comenzar con el flujo de acceso remoto actual de ZimaClient y ZimaOS, en lugar de buscar la compilación de marzo de 2026.
El problema de 2026 era intermitente y dependía de la ubicación geográfica
Se recibieron informes de India, el Reino Unido, Alemania e Indonesia. Un usuario alemán dijo que el acceso remoto desde Android funcionaba, mientras que otro método de conexión agotaba el tiempo de espera; luego, dos horas más tarde, empezó a funcionar de repente.
Esta inconsistencia sugiere que el problema de origen no era simplemente que la opción «Acceso remoto» estuviera desactivada para todos los participantes.
IceWhale reconoció que estaba trabajando en mejorar el éxito de las conexiones
777-Spider dijo explícitamente que el equipo estaba optimizando el porcentaje de conexiones remotas exitosas e invitó a los usuarios a probar un nuevo paquete. Esto es más sólido que una suposición aleatoria de la comunidad, pero el hilo no publica una causa raíz técnica definitiva ni un número de versión que haya resuelto permanentemente todos los casos.
El acceso remoto actual comienza con una conexión local exitosa
La guía actual de IceWhale indica que la primera conexión de ZimaClient a través de la red local establece la relación con el dispositivo y configura el acceso remoto. Después, ZimaClient puede volver a conectarse desde fuera de la red doméstica.
Usa el flujo actual de acceso remoto de ZimaOS como referencia.
Confirma que el acceso remoto esté activado en Configuración
La guía actual señala explícitamente que, si el acceso remoto está desactivado en la configuración de ZimaOS, el cliente no puede conectarse de forma remota.
En un problema intermitente, desactivarlo y volverlo a activar puede reconstruir el estado, como informó un usuario de la comunidad, pero esto no sustituye la comprobación del cliente actual ni del estado de la red.
Verifica o restablece el ID de red con cuidado
El ZimaOS actual muestra el ID de red del dispositivo en Configuración > Red. IceWhale advierte que el ID debe mantenerse privado y que puede restablecerse si se filtra.
Restablecerlo invalida las conexiones y los recursos compartidos existentes, así que no lo hagas como paso rutinario de solución de problemas a menos que estés preparado para volver a conectar los clientes.
Consulta el comportamiento actual del ID de red y las notas de seguridad.
El ZimaClient actual utiliza conectividad P2P cifrada
IceWhale describe el canal remoto como una conexión entre pares y cifrada. ZimaClient intenta elegir una ruta adecuada sin requerir el reenvío de puertos del enrutador.
Esto significa que un tiempo de espera agotado puede estar relacionado con la traversía de NAT, el motor de red del cliente, el cortafuegos o el software VPN local, o la conectividad ascendente, y no necesariamente con un único puerto entrante del enrutador.
Comprueba el componente de red de ZimaClient/ZeroTier
La solución de problemas actual de ZimaClient recomienda específicamente instalar o reparar ZeroTier cuando la conectividad remota no funciona. IceWhale indica que su propio controlador de red sigue bajo el control del dispositivo Zima, mientras que la infraestructura pública de descubrimiento de ZeroTier ayuda a los pares a encontrarse.
Usa los pasos actuales de solución de problemas de ZimaClient antes de reemplazar todo el diseño de acceso remoto.
Recopila los registros del cliente inmediatamente después del fallo
La documentación actual de IceWhale proporciona las ubicaciones de los registros de ZimaClient en macOS y Windows y pide a los usuarios que los recopilen inmediatamente después de un error. Esto resulta más útil para diagnosticar un tiempo de espera agotado e intermitente de una conexión P2P que reiniciar repetidamente el dispositivo sin obtener evidencias.
WireGuard, NetBird y otras VPN son alternativas válidas
Los usuarios de la comunidad del hilo de origen cambiaron a WireGuard o NetBird e informaron de un acceso estable. Se trata de arquitecturas de acceso remoto independientes, no de soluciones para ZimaClient.
Pueden ser útiles si prefieres una topología VPN explícita o quieres funciones de DNS remoto, como Pi-hole a través del túnel.
Lista de comprobación para tiempos de espera agotados del acceso remoto
- Verifica que ZimaOS esté conectado y sea accesible localmente.
- Actualiza ZimaOS y ZimaClient a las versiones estables actuales.
- Confirma que el acceso remoto esté activado.
- Vuelve a conectarte localmente una vez si la relación con el dispositivo está desactualizada.
- Comprueba los componentes de red de ZimaClient/ZeroTier.
- Descarta temporalmente posibles conflictos con el software VPN o el cortafuegos.
- Recopila los registros inmediatamente después del tiempo de espera agotado.
- Restablece el ID de red solo cuando comprendas que las conexiones existentes quedarán invalidadas.
Preguntas frecuentes sobre los tiempos de espera agotados del acceso remoto
¿IceWhale reconoció los informes de tiempos de espera agotados de 2026?
Sí. El personal indicó que se estaba optimizando el porcentaje de conexiones exitosas y distribuyó de forma privada una compilación de prueba.
¿Deben los usuarios actuales instalar ese paquete de prueba privado de 2026?
No. Primero, utiliza las versiones estables actuales de ZimaOS y ZimaClient.
¿El acceso remoto de ZimaOS requiere configurar manualmente el reenvío de puertos?
La guía actual de IceWhale describe una conexión P2P cifrada gestionada por ZimaClient, en lugar de un puerto normal del panel configurado manualmente mediante reenvío.
