コミュニティソリューション

ZimaOSのリモートIDにNXDOMAINが表示される:「デバイス接続の準備ができていません」の診断

A January 2026 ZimaBoard 2 case where local access worked but ZimaOS Remote ID never produced a public URL. Extensive community diagnostics ruled out basic DNS, time, routing, and outbound HTTPS, while logs repeatedly showed 401 invalid-or-expired-JWT errors during backend communication.

NXDOMAINエラーが発生したからといって、必ずしもZimaOSデバイス自体のDNSが壊れているとは限りません。2026年1月のこのケースでは、ユーザーのZimaBoard 2はローカルネットワーク上で正常に動作していましたが、ZimaOS PlusのリモートアクセスではパブリックURLが生成されず、ZimaClientはデバイス接続の準備ができていませんのままでした。

ユーザーはネットワークIDをリセットし、再起動し、サインアウトしてから再度サインインし、さらに1.5.4アルファ版もテストしました。しかし、これらの手順を行ってもネイティブのリモートリンクは復旧しませんでした。

障害が発生していたのはローカルアクセスではなく、リモートプロビジョニング

元のケースでは、次の3つの症状が関連して発生していました。

  • Remote IDの下にパブリックなzimaos.link URLが表示されなかった。
  • 想定されるリモートリンクを開くとNXDOMAINが返された。
  • ZimaClientは接続ループのままとなり、デバイス接続の準備ができていないと報告した。

一方、ZimaBoardはローカルIPから引き続きアクセスでき、関連のないローカルサービスも正常に提供していました。

1.5.4アルファ版への更新でも解決しなかった

コミュニティメンバーがアルファ版のテストを提案しました。元の投稿者は実際に試し、ネットワークIDを再度リセットしましたが、同じリモートアクセス障害が再現しました。これは有用な反証となります。このケースでは、1.5.3からそのアルファ版へ移行しただけではプロビジョニングの問題は解決しませんでした。

古いコミュニティのcurl | sh更新コマンドは、意図的にここでは掲載していません。このスレッドではIceWhaleチームのアカウントから投稿されたものではなく、過去のビルドを参照しているためです。

基本的なDNS、時刻、ルーティング、HTTPSはすべて正常だった

後の診断結果は非常に有益でした。ZimaBoardは通常のドメインを名前解決でき、パブリックIPにpingを送信でき、有効なデフォルトルートを使用でき、NTPで時刻を同期でき、パブリックHTTPSエンドポイントにも到達できました。失敗したsystemdユニットや、外向き通信を明らかに遮断するファイアウォール設定も確認されませんでした。

これにより、問題の範囲は大幅に絞り込まれます。ブラウザー上の症状がNXDOMAINだったとしても、単純に「DNSが壊れている」と説明するのは、かなり説得力に欠けます。

最も有力な手がかりは、繰り返し発生した401 JWTエラー

ユーザーのログには、システムがZimaOSバックエンドと通信しようとする際、invalid or expired jwtというメッセージを伴うHTTP 401レスポンスが繰り返し記録されていました。

コミュニティの回答者は、これをバックエンド認証またはRemote ID登録ハンドシェイクの失敗と解釈しました。証拠は有力ですが、スレッドにはIceWhaleのエンジニアがサーバー側の根本原因を確認した記録はありません。そのため、公式のインシデント声明ではなく、コミュニティによる診断として扱うべきです。

ユーザーはImmich用に別の回避策を構築した

ネイティブのリモートアクセスが利用できなかったため、ユーザーはルーターのポート転送とDuckDNSを使ってImmichを公開しました。これにより、家族がブラウザーからImmichへアクセスできるようになりましたが、ZimaOSのRemote ID自体が修復されたわけではありません。

アプリケーションをインターネットへ直接公開すると、セキュリティモデルが変わります。TLS、認証、アプリケーションの更新、ファイアウォールルール、ISPから到達可能なパブリックアドレスが提供されているかどうかを理解せずに、この回避策をそのまま使用しないでください。

現在のZimaOSリモートアクセスはZimaClientの接続フローを使用する

現在のZimaOSでは、リモートアクセスはZimaClientを通じて設定し、Remote Access設定で制御する暗号化されたピアツーピアチャネルとして説明されています。現在のシステムでこのチャネルを確立できない場合は、1.5.3時代のスレッドに基づくトラブルシューティングを行う前に、現在のリモートアクセス接続フローとデバイスの状態を比較してください

現在のZimaOSでは、ネットワークIDも機密性の高い接続情報として扱われます。スクリーンショットやサポート投稿で公開しないでください。

ZimaOS Remote IDに関するよくある質問

NXDOMAINは、ローカルDNSリゾルバーが壊れていることを証明しますか?

いいえ。このケースでは通常のDNS名前解決は正常に機能しており、ZimaOSのリモートレコード自体が公開されていませんでした。

ネットワークIDをリセットすれば問題は解決しましたか?

いいえ。ユーザーは複数回新しいIDを生成しましたが、パブリックURLは取得できませんでした。

最も有力な技術的手がかりは何でしたか?

通常のDNS、時刻、ルーティング、HTTPS接続が機能している一方で、無効または期限切れのJWTを報告するバックエンドHTTP 401レスポンスが繰り返し発生していたことです。

バックエンドのJWT問題はIceWhaleによって公式に確認されましたか?

いいえ。その結論は、ユーザーのログをコミュニティが分析した結果です。公開されたスレッドには、公式のサーバー側診断は含まれていませんでした。