なぜImmichはリモート接続よりLAN上のほうが速く感じるのですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Feel Faster on LAN Than on Remote Connections?

Immichは通常、ローカルクライアントがより短く低遅延な経路を通り、ゲートウェイの数も少なく、自宅のインターネット接続がボトルネックにならないため、LAN上のほうが高速に感じられます。

リモート利用では、ISPのアップロード制限、モバイル回線やホテルのネットワーク、DNS、TLS終端、リバースプロキシ、VPNやオーバーレイ、場合によってはリレーが加わります。これらの要素は、すべてのリクエストを同じように遅くするわけではありません。サムネイル、メタデータクエリ、オリジナルのダウンロード、アップロード、検索呼び出しでは経路上の異なる部分に負荷がかかるため、「リモートのImmich」を単一の性能モードと考える前に、同一の操作同士を比較してください。

LANではWAN経路の変動要因の大半がなくなる

有線LANまたは電波状態の良いWi-Fi LANでは、クライアントとサーバーの間にあるのは通常、ローカルのスイッチングやルーティングのホップ数個だけです。往復遅延が小さく、経路の大部分を家庭内で管理できるため、小さなAPI呼び出しや多数のサムネイルリクエストも、ネットワーク待ち時間をほとんど発生させずに完了できます。

NATトラバーサルにおける直接接続とリレー接続のモデルは、この違いを理解するのに役立ちます。リモートクライアントは、同じサーバーにWAN上の直接トンネル経由で接続することも、リレー経由で接続することもあります。一方、LAN上のクライアントは単にローカル経路を通ります。アプリケーションのエンドポイントが同一でも、トランスポートの条件は異なる可能性があります。

LANの低遅延が速いからといって、あらゆるワークロードでサーバーが健全だとは限りません。ローカルの遅延が小さいと、ネットワーク待ち時間が少ないため、非効率なリクエストやストレージの遅さが隠れることがあります。比較にはサーバーのメトリクスも含め、リモート経路の診断によって両方の経路に影響するバックエンドのボトルネックを見逃さないようにしてください。

自宅のアップロードがリモート側のダウンロード容量になる

自宅の外にいる人がホームサーバー上の写真を開くと、サーバーは家庭用インターネット回線のアップロード方向を通じてデータを送信します。多くの住宅向け回線では、ローカルのEthernetやWi-Fiより上り帯域幅がはるかに小さいため、LANでの閲覧は瞬時でも、リモートでオリジナル画像や大きなプレビューを扱うと帯域幅が制限要因になることがあります。

家族でのリモートアクセスに関するコミュニティスレッドは、家庭が接続性だけでなく、技術に詳しくないユーザーにとっての簡単さや信頼性も評価する理由を示しています。性能、認証、ユーザー体験は、実際のリモート経路を構成する要素です。

小さなメタデータの操作、フィルター、ログイン処理が遅い一方で、大容量転送が期待どおりの速度に達する場合、帯域幅だけでは適切な説明になりません。このパターンは、遅延、リクエストのルーティング、プロキシの動作、DNS、またはサーバーの応答時間をより強く示しています。

プロキシとトンネルは処理および設定の境界を増やす

リモートリクエストは、プロキシでTLSが終端されたり、別のコンテナネットワークを通過したり、暗号化されたオーバーレイを経由してImmichに到達したりすることがあります。適切に設定されたレイヤーのオーバーヘッドは小さい場合もありますが、レイヤーが増えるたびに、バッファリング、ヘッダー処理、タイムアウトポリシー、経路選択、MTUの問題が特定のリクエストに影響する箇所も増えます。

2026年のImmichユーザーレポートにあるリモートフィルタリングの遅延では、リレーの性能も検討された後、最終的にエンドポイント経路の設定問題が特定されました。この例が有用なのは、2つの異なる仕組みが似た「リモートだと遅い」という症状を生み出していたためです。

1回のページ読み込みだけを根拠に、リモートアクセス技術を入れ替えないでください。まず、失敗している操作が転送、APIリクエスト、認証、接続確立のいずれなのかを特定します。リバースプロキシでは飽和した自宅の上り回線を改善できず、より高速なトンネルでも遅いデータベースクエリは解決できません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

キャッシュによってLANとリモートのテスト条件が不均等になることがある

LAN上のスマートフォンには、サムネイル、セッション状態、DNSの応答、最近アクセスしたアセットがすでにキャッシュされている一方で、リモートテストはキャッシュがほとんどない状態から始まることがあります。この2回の実行を比較すると、一方のクライアントがサーバーから要求するデータ量が少ないため、ネットワーク差が実際以上に大きく見える可能性があります。

ZimaSpaceによるストレージ遅延の解説は、性能を比較する際にキャッシュとワークロードの状態をそろえる必要性を裏付けています。同じ考え方は経路のテストにも当てはまります。可能な限り、同じアカウント、アセットセット、クライアント、キャッシュ状態を使用してください。

両方のテストを同じ経路に強制した場合や、サーバー側の応答時間自体が同じように増加した場合にも差が残るなら、LANとWANの仕組みではその差を説明できません。その時点では、ネットワークトポロジーの最適化を続けるのではなく、アプリケーションやホストを調査してください。

同じ操作で経路を比較する

4つの操作を選びます。同じアルバムを読み込む、同じ大きな写真を開く、同じ既知の検索を実行する、同じテストファイルをアップロードする、の4つです。クライアントで観測した時間、可能であればサーバーのリクエスト時間、往復遅延、転送スループット、そしてリモート経路が直接接続、プロキシ経由、リレー経由のいずれであるかを記録します。

既知のキャッシュ状態からLANとリモートの実行を比較し、その後は一度に1つの経路変数だけを変更します。Tailscaleによる直接接続とリレー接続の解説は、経路を分類するための有用なモデルを示しています。大容量転送だけが改善するなら、帯域幅がより強い制限要因です。

サーバーのワークロードを変えずに、仕組みから予測した操作が変更した経路によって改善された場合、その診断を採用できます。家族のアクセス要件と性能目標を満たす、最もシンプルなリモート構成を維持してください。追加のプロキシ、トンネル、リレーのレイヤーは、明確な到達性またはセキュリティ上の理由がある場合にのみ設けるべきです。