If Network ID works from one computer but fails from another, the ZimaCube itself is probably not the only fault domain. In this July 2025 case the same server connected successfully from an office Windows Server machine, while the home Windows 11 PC timed out. IceWhale therefore suspected the ISP or local network path.
The connection eventually recovered without one clearly proven fix. That means the thread gives a strong troubleshooting sequence, not a single magic setting.
What the Server Network Looked Like
The ZimaCube Pro had a normal LAN address and a virtual remote-network interface, so the basic ZimaOS networking stack was present.
The Failing PC Timed Out Inside ZimaClient
The useful comparison was that another PC on another network could connect. That points toward client-specific, ISP-specific or local-network behavior.
Prove LAN Access Before Debugging Network ID
The user could ping the server and open the ZimaOS Web UI directly. That separated server availability from the ZimaClient connection-path problem.
The current Network ID guide also notes that resetting a leaked Network ID invalidates existing connections and shares, so do not reset it casually during troubleshooting.
Check ZimaClient and Its Networking Helper
The current ZimaClient troubleshooting guide still documents ZeroTier as part of troubleshooting and lists current log paths.
The ZimaClient recovery checklist is useful when the Web UI works but the desktop client does not.
The Source Case Recovered Without a Proven Single Fix
The user logged out of Web UI, attempted ZimaClient again, left the client trying for hours, and later found that it was working. That timing does not prove logout, waiting, IPv6 or any one step fixed it.
Bottom Line
Use comparison testing: same ZimaOS server from another PC, same PC from another network, direct LAN IP, ZimaClient, and ZeroTier/service logs. If direct LAN works but only one client/network fails, preserve that evidence before resetting IDs or reinstalling the NAS.
