Este caso de origen separa dos rutas de conexión que los usuarios suelen tratar como si fueran lo mismo. ZimaClient podía conectarse correctamente cuando el usuario introducía el ID remoto, tanto en casa como fuera de ella, pero la detección automática en la red local mostraba No se encontró ningún dispositivo. Esto significa que la relación con el servidor y la ruta remota funcionaban, mientras que la detección local fallaba.
El hilo nunca llegó a una solución final confirmada. El permiso de red local de iOS ya estaba habilitado, Avahi estaba en ejecución, una reinstalación completa de ZimaOS no cambió el comportamiento y, posteriormente, el usuario instaló el cliente de Android, solo para descubrir que Android tampoco podía detectar automáticamente el servidor.
El ID remoto funcionaba, pero la detección en la LAN fallaba
Esta diferencia marca un límite de diagnóstico útil: no investigues la autenticación del ID remoto cuando el fallo se limita a la detección local.
El permiso de red local de iOS ya estaba habilitado
Una respuesta de la comunidad sugirió correctamente revisar los ajustes de iOS, ya que Apple exige un permiso explícito para las aplicaciones que detectan dispositivos de la red local o se comunican con ellos.
Reinstalar la aplicación y ZimaOS no lo solucionó
El usuario reinstaló repetidamente la aplicación de iOS, reinició y apagó el NAS y, finalmente, formateó y reinstaló ZimaOS. Ninguno de estos pasos restableció la detección automática.
Estas pruebas negativas apuntan en contra de una simple caché obsoleta de la aplicación o de una única instalación dañada de ZimaOS.
La comunidad sospechó de mDNS/Bonjour
La detección automática de dispositivos en muchas aplicaciones locales depende del DNS multidifusión o de difusiones relacionadas de detección en la LAN. Los miembros de la comunidad sospecharon que el cliente no estaba recibiendo esos anuncios y sugirieron comprobar el aislamiento de puntos de acceso o clientes y el reenvío de multidifusión.
El usuario objetó que AirPrint, AirPlay, la detección de QNAP y otros servicios locales de iOS funcionaban a través de la misma red TP-Link Deco.
Avahi estaba en ejecución en ZimaOS
Avahi en puentes virtuales solo fue una hipótesis de la comunidad
Una respuesta posterior observó actividad de Avahi en interfaces de Docker o virtuales y sugirió que quizá estuviera anunciando en el puente equivocado en lugar de hacerlo en la LAN principal. El autor de la respuesta solicitó más registros del journal.
El hilo público termina antes de que esa hipótesis pudiera validarse. No presentes «Avahi está vinculado a Docker» como la causa raíz confirmada.
El fallo también en Android cambió el diagnóstico
El usuario del caso original instaló el cliente de Android e informó que tampoco podía detectar automáticamente el servidor. Esto debilitó las explicaciones relacionadas específicamente con Enhanced Privacy de iOS, los ajustes de VPN o el permiso de red local de Apple.
Las variables restantes eran el host de ZimaOS, la ruta de detección de la LAN o una interacción entre ambos.
IceWhale solicitó detalles sobre la topología y la privacidad
Zima-Giorgio preguntó por las VLAN, los firewalls, el filtrado de protocolos, las funciones Enhanced Privacy/VPN de iOS, IP Restriction Tracking y las pruebas con otro dispositivo Apple. Esta fue una solicitud oficial de diagnóstico, no una afirmación de que alguno de esos ajustes provocara el fallo.
El ZimaClient actual ha seguido evolucionando
El ZimaClient actual está muy por delante de la versión de octubre de 2025 e incluye mejoras continuas en la fiabilidad de la conexión y el cambio entre dispositivos. En un caso moderno, actualiza ZimaOS y ZimaClient antes de repetir los antiguos experimentos de reinstalación.
Usa el procedimiento actual de instalación y conexión de ZimaClient como referencia.
Preguntas frecuentes sobre la detección de ZimaClient en la LAN
¿Funcionaba el ID remoto en el caso original?
Sí. El usuario podía conectarse mediante el ID remoto tanto dentro como fuera de la red doméstica.
¿Estaba deshabilitado el acceso a la red local de iOS?
No. El usuario publicó una captura de pantalla que mostraba que estaba habilitado.
¿Avahi estaba detenido?
No. La captura de pantalla original mostraba avahi-daemon en ejecución.
¿Se confirmó la causa raíz final?
No. El hilo público terminó mientras todavía se debatían pruebas adicionales de la topología y de las interfaces de Avahi.
