リバースプロキシが、あるアプリを別のアプリのドメインにリダイレクトするのはなぜですか？
リバースプロキシは、バックエンドやミドルウェアが誤った公開ホスト名からリダイレクトを生成すると、あるアプリを別のアプリのドメインへ送ることがあります。
ZimaSpaceのセルフホスト構成では、複数のアプリが同じプロキシを共有しながら、それぞれ独自の公開ベースURLを想定している場合があります。Host、X-Forwarded-Host、スキーム、ミドルウェア、またはアプリレベルの正規URLが別のサービスを指していると、最初のページは正しく読み込まれても、次の301、302、またはログインコールバックで別のドメインへ移動することがあります。
バックエンドに送信されるHostとスキームを確認する
リダイレクトを再現しながら、プロキシとバックエンドでリクエストヘッダーを取得します。
転送されたホストとスキームがバックエンドに到達する仕組みに関する、特定の問題に焦点を当てたリバースプロキシ実装ガイドは、基礎となるプロトコルの定義だけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
アプリケーションURLを変更する前に、プロキシヘッダーを修正してください。バックエンドが別のホストでリクエストを受けたと思い込んでいる場合、正しい絶対リダイレクトを生成できません。
X-Forwarded-Hostを重点的に確認する
絶対URLの生成時に、生のHostヘッダーではなくX-Forwarded-Hostを使用するフレームワークがあります。
X-Forwarded-Hostが公開ホスト名を保持する仕組みに関する、特定の問題に焦点を当てたHTTPヘッダー解説は、基礎となるプロトコルの定義だけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
正常に動作するアプリと誤ったドメインへリダイレクトされるアプリで、このヘッダーを比較します。すべてのバックエンドを1つのドメインに強制するグローバルな上書きを削除してください。
アプリが絶対URLを生成しているか確認する
プロキシヘッダーを信頼し、正規リンクやリダイレクトを構築するフレームワーク設定を確認します。
プロキシの背後で絶対URLが誤る可能性に関する、特定の問題に焦点を当てた実例ベースのプロキシデバッグ記事は、基礎となるプロトコルの定義だけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
エッジであらゆるリダイレクトを書き換えるのではなく、フレームワークのプロキシ信頼設定または公開URL設定を修正してください。
アプリのベースURLまたは正規ドメインを確認する
多くのセルフホストアプリでは、プロキシルールとは別にサイトURLを保存しています。
アプリケーションのベースURLがプロキシのホスト名を上書きする可能性に関する、特定の問題に焦点を当てた実践的なプロキシ配下アプリの事例研究は、基礎となるプロトコルの定義だけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
移行や復元の後に保存されているアプリケーションURLの値を比較します。コピーしたデータベースに、別のアプリ環境の正規ホスト名が残っている場合があります。
バックエンドの前にリダイレクトミドルウェアを監査する
プロキシルールによっては、リクエストがアプリケーションに到達する前にスキームやホストを意図的に書き換えることがあります。
リダイレクトミドルウェアがホストを置き換える仕組みに関する、特定の問題に焦点を当てたホームラボ向けTraefik手順は、基礎となるプロトコルの定義だけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
テスト用の1つのルーターで、疑わしいリダイレクトミドルウェアだけを無効にします。HTTPSの強制とクロスドメインリダイレクトは分離してください。
OAuthとOIDCのコールバックURLを確認する
認証フローでは、プロバイダーが正確なリダイレクトURIを検証するため、誤った公開ホスト名が明らかになることがあります。
OIDCコールバックが公開プロキシURLに依存する仕組みに関する、特定の問題に焦点を当てたOIDCトラブルシューティング記事は、基礎となるプロトコルの定義だけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
issuer、コールバック、転送ヘッダー、アプリのベースURLをまとめて比較します。通常のページが読み込めても、ログインコールバックの経路が正しいとは限りません。
ホームサーバーでの正確な経路を再テストする
1つの変数を変更した後は、別の経路を使う可能性のある別のテストへ切り替えず、同じクライアントから同じNASまたはセルフホストの手順を繰り返します。
関連するホームサーバーネットワーク経路についてのZimaSpaceガイドは、最終確認を同じセルフホスト環境に結び付けるのに役立ちます。
再接続、サービスの再起動、そして2回目の制御された転送またはリクエストの後も、元の症状が解消されたままの場合にのみ、修正は完了です。
よくある質問
DNSがHTTP 301や302の原因になることはありますか？
DNSが返すのはアドレスだけです。リダイレクトを生成するのは、プロキシ、認証層、またはアプリケーションです。
ブラウザーがドメインを変更する前に、なぜ正しいアプリが読み込まれるのですか？
最初のプロキシ経路は正しくても、バックエンドが誤ったベースURLや転送ホスト名から、後続の絶対リダイレクトを生成することがあります。
プロキシですべてのLocationヘッダーを書き換えるべきですか？
いいえ。まず誤ったホスト名の発生源を修正してください。レスポンスを広範囲に書き換えると、アプリケーション設定の誤りが隠れてしまう可能性があります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
