リバースプロキシの再起動後にImmichへログインできない
リバースプロキシの再起動後にのみImmichへのログインが失敗する場合は、まずImmichアプリケーションとアカウントが直接アクセスでは引き続き機能し、プロキシ経路だけが壊れているかを確認します。
再起動によって、古いアップストリームアドレス、共有ネットワークへの参加漏れ、ヘッダーの変更、Cookieの動作、または依存先に接続できる前に起動したプロキシプロセスが表面化することがあります。同じアカウントで、ローカルのImmichエンドポイントと通常の公開ホスト名の両方をテストし、2つの経路が最初に分岐する層を確認してください。
直接アクセスで認証とプロキシ障害を切り分ける
既知のアカウントを使い、リバースプロキシを経由しない、信頼できるローカル経路からImmichサーバーへのログインをテストします。直接ログインが成功し、公開ホスト名では読み込みが続いたり、リダイレクトされたり、アップストリームエラーが返ったりする場合、ユーザーレコードと認証の中核経路はおそらく正常です。調査対象をプロキシ、TLS、ルーティング、ブラウザーの状態に絞ってください。
直接アクセスは機能した一方で、プロキシ経由のログインが失敗した事例は、この切り分け方法を示しています。この報告は特定バージョンに関するものなので、同じ根本原因だと決めつけず、経路を比較する根拠として利用してください。
直接アクセスとプロキシ経由の両方でログインに失敗する場合は、プロキシ設定の変更を止めてください。代わりに、Immichサービスの健全性、データベース接続、アカウント状態、サーバーログを確認します。障害の直前にプロキシが再起動したことは偶然かもしれません。バイパステストによって、そのタイミングだけを根拠にした不確かな診断を避けられます。
プロキシが現在のImmichアップストリームに接続できることを確認する
プロキシの再起動後、プロキシ自身のネットワーク名前空間からImmichアップストリームを解決し、接続できることを確認します。Dockerでは、コンテナの再作成時に変わる手動コピーのコンテナIPよりも、共有ユーザー定義ネットワーク上のサービス名をアップストリームに指定する方が一般的に安定します。
プロキシからImmichへの接続に関する障害の議論は、アカウント復旧を試す前に、アップストリームへの到達性とWebSocketに対応したプロキシ設定を確認すべき理由を示しています。具体的な設定はあくまで事例であり、すべてのプロキシ向けのテンプレートとして扱わないでください。
プロキシだけを2回再起動し、そのたびにアップストリームが同じサービスとして解決されるかを確認します。アドレスを編集せず、直ちに接続に成功すれば合格です。コンテナの再作成後に名前解決、ネットワークへの参加、または接続先ポートが変わる場合は、スタックを何度も再起動するのではなく、Composeのネットワーク定義を修正してください。
転送ヘッダー、TLS、Cookieの動作を確認する
プロキシがImmichのページを返していても、認証は完全なHTTP経路に依存するため、ログインに失敗することがあります。再起動前後のプロキシ設定を比較し、ホストとスキームの転送、HTTPSの終端、リダイレクト、Cookieの書き換え、さらに別のプロキシやトンネルがレスポンスを変更していないかを確認します。
Immichコミュニティのある議論では、重複Cookieによるログイン事例が報告されており、プロキシのCookie処理によってログインがハングしました。これは限定的な事例ですが、正しい認証情報ならプロキシ経由のセッションも必ず成功すると考えず、ブラウザーのレスポンスとCookieを確認する重要性を示しています。
ブラウザーのセッションが停止したように見えるからといって、すべてのアカウントを削除したり、データベースをリセットしたりしないでください。元のCookieとレスポンスを記録したうえで、プライベートウィンドウまたは別のブラウザーを使用します。クリーンなクライアントで機能する場合は、影響を受けたサイトの状態だけを消去し、不正なCookieやリダイレクトを作成したプロキシルールを修正してください。
失敗したリクエストの時刻にプロキシのアクセスログとエラーログを読む
ログインを1回再現し、正確な時刻、公開ホスト名、クライアント、返されたステータスを記録します。次に、そのリクエスト前後のプロキシアクセスログとエラーログを確認します。リクエストがプロキシに到達しなかったのか、プロキシが生成した4xxまたは5xxなのか、アップストリームへの接続失敗なのか、それともImmichまで到達してアプリケーションレスポンスを受け取ったのかを区別してください。
NGINXのログトラブルシューティング手順は、ステータス、アップストリームエラー、リクエスト時間、対象を絞ったログ記録が、ログインページを何度も更新するよりはるかに強い手掛かりになることを示しています。同じ原則をCaddy、Traefik、その他のプロキシにも適用してください。
プロキシログにアップストリームからの正常なレスポンスが記録されているのにブラウザーがログインを完了できない場合は、リダイレクト、Cookie、TLS、クライアントの状態を確認します。プロキシがアップストリームに接続できない場合は、ルーティングまたはサービスの準備状態を修正します。Immich自体がエラーを返している場合は、プロキシが原因だと決めつけず、対応するサーバーログを調査してください。
最初に障害を起こした再起動後も修正が有効か確認する
原因を特定して修正したら、最初に障害を引き起こした操作をそのまま繰り返します。リバースプロキシだけを再起動し、ヘルスチェックを待ってから、公開ホスト名でログインします。続いて既存のアセットを開き、小さなファイルをアップロードし、通常のAPI通信を確認できる時間だけセッションを維持します。
ZimaSpaceの管理されたリモートアクセス経路に関するガイドは、より広い境界を示しています。リモートアクセスではプロキシは1つの層にすぎないため、DNS、TLS、認証、プライベートなアップストリームを意図的に構成し、監視可能な状態に保つ必要があります。
プロキシを2回再起動してもログインが維持され、スタック全体の再起動後も同じ設定で正常に起動できた場合にのみ合格とします。新しいヘッダーやCookieのルールが障害を引き起こした場合は、最近のプロキシ変更をロールバックしてください。プロキシ設定の差分、リクエストステータス、アップストリームエラー、サーバーログの時刻、直接アクセスとプロキシ経由のテスト結果を添えてエスカレーションします。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
