ImmichはCGNATや二重NAT環境でも安定して動作しますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Does Immich Work Reliably Behind CGNAT or Double NAT?

はい、ImmichはCGNATや二重NATの背後でも安定して動作します。これらのネットワーク層が主に影響するのは、リモートクライアントがサーバーへ接続する方法であり、Immichのローカル処理ではないためです。

問題が生じるのは、外側のアドレス変換を管理できないホームサーバーに対して、家族が予期しないインバウンドIPv4接続を到達させようとする場合です。両方のルーターを管理できるなら、二重NATでも対処できることがあります。一方、CGNATでは通常、外側の変換をISPが管理しているため、家庭用ルーターで単純にポート転送を設定しても、同じような直接のパブリック経路は作れません。

ローカルでのImmichの動作はパブリック到達性に依存しない

同じホームネットワーク上にあるスマートフォンやブラウザーは、パブリックポートのマッピングなしでプライベートアドレスを使ってImmichサーバーに接続できます。そのため、ISPから直接到達可能なパブリックIPv4アドレスが家庭に割り当てられていなくても、アップロード、閲覧、データベース処理、サムネイル生成、ローカルの機械学習は正常に維持できます。

この違いは、CGNATの背後でのImmichに関するコミュニティの質問にも表れています。ユーザーは、ローカル環境は動作しているものの、リモートアクセスを追加したときに初めて制限に直面することがよくあります。つまり、CGNATはアプリケーションやストレージの問題ではなく、到達性の問題です。

LAN上でもImmichが動作しない場合、最初に疑うべき原因はCGNATではありません。パブリック経路を再設計する前に、ローカルDNS、コンテナネットワーク、サーバーの稼働状況、ストレージ、認証を確認してください。

二重NATとCGNATでは管理境界が異なる

家庭内の二重NATでは、管理者が両方の変換層を管理できる場合があります。たとえば、ISPのゲートウェイと個人用ルーターの構成です。その場合、両方の層を通してポート転送を設定したり、トポロジーを変更したりすることで、直接のインバウンド経路を構築できることがあります。重要なのは、外側のマッピングを家庭側で管理できるかどうかです。

Tailscaleの困難なNATトラバーサルに関する記事では、複数のNAT層やキャリアグレードのゲートウェイによって、直接のピアツーピア経路を確立できる可能性が低くなる理由が説明されています。マッピングの制限が厳しいほど、トラバーサルシステムがフォールバックリレーを必要とする可能性が高くなります。

WAN側のアドレスがプライベートに見えるからといって、すべてを同じ問題として扱わないでください。IPv6、ISPが提供するパブリック接続オプション、ブリッジモード、異なる上流ネットワーク構成によって、ホームルーターの画面が似ていても利用できる経路は変わることがあります。

オーバーレイネットワークでポート転送なしに到達性を回復できる

プライベートなオーバーレイを使うと、リモートクライアントとホームサーバーの双方がアウトバウンド接続を開始し、暗号化されたピアツーピア経路の確立を試みることができます。直接のトラバーサルに成功すれば、ホームルーター上でImmichサービスを通常のパブリックポートとして公開せずに通信できます。

オーバーレイ接続についての詳しい説明では、NATトラバーサルと、直接経路を確立できない場合の暗号化リレーへのフォールバックが解説されています。これが、CGNATの背後にある家庭でも、通常のインバウンドIPv4転送が利用できない状態でImmichへのリモートアクセスを実現できる理由です。

一方で、クライアントとIDへの依存が生じます。承認済みのリモートデバイスはオーバーレイにアクセスする必要があり、ブラウザーのみを使うゲスト向けのパブリックリバースプロキシとは経路が異なる場合があります。そのため、信頼性を評価する際は、管理者のスマートフォン1台が動作するかだけでなく、家族が実際にどのように接続するかも考慮する必要があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

リレーへのフォールバックでアクセスは維持できるが、性能が変わることがある

困難なNATやファイアウォールルールによって直接のUDP接続が妨げられても、リレー経由の経路ならサービスへの到達性を維持できます。これによりアクセスできるかどうかという二択の問題は解決しますが、追加の中継によって遅延が増えたり、スループットが低下したりする可能性があります。これは、大量の写真のアップロードや高解像度画像のリモート閲覧で特に重要です。

2026年のリレー性能に関する報告では、より優れたリレー構成が使われるまで、長距離のDERP経路によって数百ミリ秒の遅延が追加された事例が示されています。具体的な遅延の大きさはその執筆者の経路に固有のものとして扱い、直接経路とリレー経路の一般的な仕組みを参考にしてください。

ここが、「TailscaleがCGNATを解決する」という単純な説明の限界です。Tailscaleによって接続性は回復できますが、直接のLAN経路や直接のピア経路と同じ性能が保証されるわけではありません。Immichの動作が遅い原因をアプリケーションに求める前に、実際の経路を確認してください。

到達性と経路を別々に検証する

まず、WANを切断した状態でローカルのImmichをテストしてください。ホームネットワーク内では引き続き利用できるはずです。次に、携帯電話回線や別の外部ネットワークから、選択したリモートアクセス方法をテストします。最後に、リモート接続が直接経路なのかリレー経路なのかを確認し、アップロード、サムネイルの表示、既知の検索結果をLAN接続時と比較してください。

ZimaSpaceによるCGNATと二重NATの解説でも、別のセルフホストサービスを例に同じネットワーク層の原則が説明されています。アプリケーションはローカルでは安定して動作し続けられますが、リモートからの入口には別途設計が必要です。

インターネット接続が失われてもローカル利用が継続でき、リモート認証が意図した設計になっており、リモート経路が家庭で求める遅延とスループットの目標を満たすなら、その構成を採用して問題ありません。予想外に遅いリレー経由でしかアクセスできない場合は、Immich自体がNATの背後で不安定だと判断するのではなく、経路品質の問題として扱ってください。