内部 HTTP(S) 負荷分散のトラブルシューティング

このガイドでは、Google Cloud 内部 HTTP(S) ロードバランサの構成に関する問題のトラブルシューティングについて説明します。このガイドに進む前に、次の内容を理解しておいてください。

トラブルシューティング

負荷分散されたトラフィックに元のクライアントのソースアドレスが含まれていない

これは想定されている動作です。内部 HTTP(S) 負荷分散は、HTTP(S) リバース プロキシ(ゲートウェイ)として機能します。クライアント プログラムが INTERNAL_MANAGED 転送ルールの IP アドレスへの接続を開くと、その接続はプロキシで終端し、接続を介して到着したリクエストはプロキシで処理されます。リクエストのたびに、プロキシは URL マップなどの要素に基づいてリクエストの受信先となるバックエンドを選択し、そのバックエンドにリクエストを送信します。その結果、バックエンドから見ると、受信パケットのソースはそのリージョンのプロキシ専用サブネットの IP アドレスになります。

リクエストがロードバランサによって拒否される

リクエストが到着するたびに、プロキシはロードバランサの URL マップのパスマッチャーに基づいて受信先となるバックエンドを選択します。リクエストのパスマッチングが定義されていない場合、URL マップはバックエンド サービスを選択できないため HTTP 404(Not Found)レスポンス コードを返します。

ロードバランサがバックエンドに接続されない

バックエンド サーバーを保護するファイアウォールは、内部 HTTP(S) ロードバランサのリージョンに割り振られたプロキシ専用サブネット範囲内にあるプロキシからの受信トラフィックを許可するように構成する必要があります。

プロキシはバックエンド サービスの構成で指定された接続設定を使用してバックエンドに接続します。これらの値がバックエンドで実行されているサーバーの構成と一致しない場合、プロキシはバックエンドにリクエストを転送できません。

ヘルスチェック プローブがバックエンドに到達できない

ヘルスチェック トラフィックがバックエンド VM に到達したことを確認するには、ヘルスチェック ロギングを有効にし、成功したログエントリを検索します。

クライアントがロードバランサに接続できない

プロキシがリッスンする接続は、転送ルールで構成されているロードバランサの IP アドレスとポート(10.1.2.3:80 など)を宛先とし、転送ルールで指定されたプロトコル(HTTP または HTTPS)を使用する接続です。クライアントが接続できない場合は、正しいアドレス、ポート、プロトコルが使用されていることを確認してください。

ファイアウォールが、クライアント インスタンスと負荷分散された IP アドレスの間のトラフィックをブロックしていないことを確認してください。

クライアントがロードバランサと同じリージョンにあることを確認してください。内部 HTTP(S) 負荷分散はリージョナル プロダクトであるため、すべてのクライアントとバックエンドはロードバランサ リソースと同じリージョンになければなりません。

共有 VPC に関する組織のポリシー制限

共有 VPC を使用していて、特定のサブネットに新しい内部 HTTP(S) ロードバランサを作成できない場合は、組織のポリシーが原因である可能性があります。組織のポリシーで、許可されたサブネットのリストに、ロードバランサを作成したいサブネットを追加するか、組織管理者にお問い合わせください。詳細については、constraints/compute.restrictSharedVpcSubnetworks をご覧ください。

制限事項

他の Google Cloud ネットワーク機能と内部 HTTP(S) 負荷分散を併用できない場合は、現在の互換性の制限事項をお確かめください。