コンテナを再構築した後、リバースプロキシが502を返すのはなぜですか？
リバースプロキシは、再構築されたアップストリームへの有効な接続を確立できなくなると、コンテナの再構築後に502を返します。
再構築によってコンテナが置き換えられ、新しいアドレスが割り当てられたり、Dockerネットワークが切断または名前変更されたり、公開ポートが変更されたり、不完全な設定が復元されたり、アプリケーションの準備が整う前にプロキシが起動したりすることがあります。正しい診断は、プロキシのエラーログから始め、エラーが一時的に消えるまで両方のサービスを再起動するのではなく、プロキシからコンテナまで実際のアップストリームアドレスを追跡します。
502がアップストリーム接続障害によるものか確認する
影響を受けているドメインに一度リクエストを送り、タイムスタンプ、プロキシのステータス、アップストリームアドレス、完全なエラーメッセージを記録します。接続拒否、ホストが見つからない、タイムアウト、接続リセット、TLSハンドシェイク失敗、無効なレスポンスを区別してください。
502は、プロキシが使用可能なアップストリームレスポンスを受け取れなかったことを意味しますが、エラーの詳細によって、対象が存在しないのか、到達できないのか、リッスンしていないのか、間違ったプロトコルを使用しているのかが分かります。現在のNGINXトラブルシューティングガイドでは、再構築されたコンテナによって、名前解決または設定が更新されるまで、プロキシが古いバックエンドアドレスを使い続ける場合があると説明されています。
ログに記録されたアップストリームの名前、アドレス、ポート、プロトコルを使用して、プロキシホストまたはプロキシコンテナからアプリケーションに直接接続してテストします。その直接リクエストも同じように失敗する場合は、パブリックDNSや証明書を変更せず、プロキシとコンテナの間に絞って調査を続けてください。
再構築前後でアップストリームの宛先を比較する
再構築されたコンテナ名、サービス名、内部IP、公開ポート、ホストに公開されたポート、ネットワークエイリアス、ネットワーク接続を確認します。それらをプロキシ設定および最後に動作していた宛先と比較してください。
nginx-proxyの問題事例では、再構築によってアプリケーションコンテナのIPが変更され、プロキシが到達不能なコンテナのアップストリームへリクエストを送り続けていました。パブリックドメインは正しいままで、変更されたのはプライベートなアップストリームの識別情報だけでした。
コンテナIPよりも、安定したComposeのサービス名またはネットワークエイリアスを優先してください。IPを意図的に固定している場合は、再構築されたサービスに実際にそのIPが割り当てられ、別のコンテナがそのアドレスを使用していないことを確認します。
プロキシとアプリが同じDockerネットワークを共有しているか確認する
プロキシとアプリケーションに接続されているネットワークを一覧表示し、少なくとも1つのユーザー定義ネットワークを共有していることを確認します。ホストポートを公開しても、別の分離されたDockerネットワークからコンテナ名に自動的に到達できるようになるわけではありません。
あるDockerネットワークの事例では、依存するサービスを適切なネットワークに移動したところ、繰り返し発生していた502レスポンスが直ちに解消されました。これは、すべてのコンテナが稼働している場合でも、到達不能なアップストリーム経路が発生する可能性を示しています。
サービス間の関係が再構築後も維持されるよう、ワンオフのコマンドではなくComposeを使って接続してください。スタックを再作成した後、プロキシコンテナ内からDNS解決とアップストリームポートをテストします。
内部リスニングポートとバインドアドレスを確認する
アプリケーションがプロキシの使用するポートでリッスンし、コンテナネットワークから到達可能なアドレスにバインドされていることを確認します。ホストに公開されたポートと、コンテナ内部のリスニングポートを混同しないでください。
プロキシが接続できるのは、アプリがループバック以外のアドレスにバインドされている場合だけです。コンテナ内部で127.0.0.1をリッスンしているサービスは、ローカルのヘルスチェックコマンドが成功しても、プロキシからは利用できません。
アプリケーションログ、ソケット一覧、プロキシコンテナからの直接リクエストを確認します。ポートが接続を拒否する場合は、リトライやプロキシのタイムアウト延長を追加する前に、アプリのリスナーまたは設定を修正してください。
コンテナの起動ではなく、アプリケーションの準備完了を待つ
再構築されたコンテナは稼働中でも、マイグレーション、データベースの復旧、キャッシュのウォームアップ、設定の生成などが原因で、アプリケーションがリクエストを受け付けられない場合があります。最初の502のタイムスタンプを、ヘルスチェックと起動ログと比較してください。
Gristのトラブルシューティングの議論では、Dockerのアーキテクチャ、環境設定、アップストリームの準備状態が組み合わさり、再構築後もコンテナ側の502障害が継続するケースが示されています。
意味のあるヘルスチェックを追加し、単にプロセスが存在することではなく、クライアントが必要とする処理の準備が整うまで、プロキシまたは依存サービスが待機するようにします。失敗したアプリが起動に時間がかかっているだけに見えないよう、リトライ回数には上限を設けてください。
プロキシの名前解決を更新し、安定した経路を再構築する
サービス名、ネットワーク、ポート、ヘルス状態が正しいことを確認したら、プロキシをリロードまたは再作成します。プロキシが起動時にしか名前解決を行わない場合は、サポートされている実行時名前解決、または予測可能な再起動順序を設定してください。
ZimaSpaceの失敗しているコンテナ依存関係を切り分ける手順は、アップストリームが健全な状態を維持せず、繰り返し終了する場合に役立つ関連診断を提供しています。
再度の再構築後もプロキシがサービス名を解決し、意図した内部ポートに到達し、起動中の待機を経て、手動でIPを編集することなくドメインを提供できて初めて、修復は完了です。検証後は、一時的な直接IPの宛先や文書化されていないネットワーク接続を削除してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
