あるコンピューターでは Network ID が機能するのに、別のコンピューターでは機能しない場合、ZimaCube 自体だけが原因である可能性は低いでしょう。 2025 年 7 月のこの事例では、同じサーバーにオフィスの Windows Server マシンからは正常に接続できた一方、自宅の Windows 11 PC ではタイムアウトしました。そのため IceWhale は ISP またはローカルネットワーク経路を疑いました。
接続は、明確に特定できる一つの修正を行わないまま、最終的に復旧しました。つまり、このスレッドは単一の決定打となる設定ではなく、強力なトラブルシューティング手順を示しています。
サーバーのネットワーク構成

ZimaCube Pro には通常の LAN アドレスと仮想リモートネットワークインターフェースがあり、基本的な ZimaOS ネットワークスタックが存在していました。
問題の PC は ZimaClient 内部でタイムアウトしました


有用な比較材料は、別のネットワーク上にある別の PC から接続できたことでした。これは、クライアント固有、ISP 固有、またはローカルネットワークに起因する動作を示しています。
ネットワーク ID のデバッグ前に LAN アクセスを確認する


ユーザーはサーバーに ping を実行でき、ZimaOS の Web UI を直接開くこともできました。これにより、サーバーの可用性と ZimaClient の接続経路の問題を切り分けられました。
現在のネットワークIDガイドにも、漏洩したネットワークIDをリセットすると既存の接続と共有が無効になると記載されています。そのため、トラブルシューティング中に安易にリセットしないでください。
ZimaClientとそのネットワークヘルパーを確認する

現在のZimaClientトラブルシューティングガイドでも、トラブルシューティングの一環としてZeroTierを引き続き案内し、現在のログパスを掲載しています。
Web UIは機能するもののデスクトップクライアントが機能しない場合は、ZimaClient復旧チェックリストが役立ちます。
単一の確実な解決策が判明しないまま、事例の問題は復旧した
ユーザーはWeb UIからログアウトして再度ZimaClientを試し、クライアントを何時間も接続試行中のままにしていました。その後、動作していることに気づきました。この経過だけでは、ログアウト、待機、IPv6、またはいずれか1つの手順が解決の原因だったとは証明できません。

結論
比較テストを行います。別のPCから同じZimaOSサーバーに接続し、同じPCから別のネットワークを使用し、LANの直接IP、ZimaClient、ZeroTier/サービスログを確認してください。LANへの直接接続は機能する一方で、1台のクライアントまたは1つのネットワークだけで失敗する場合は、IDをリセットしたりNASを再インストールしたりする前に、その証拠を保存してください。
