このトピックでは、Application Load Balancer (ALB) に関するよくある質問（FAQ）への回答を提供します。
インスタンスと仕様
ALB には特定のインスタンス仕様がありますか？
ALB では、インスタンスタイプを選択する必要はありません。アップグレード済みの ALB インスタンスは、自動 VIP スケーリング機能を使用して、単一インスタンスで 100万 QPS を実現できます。ALB インスタンスのパフォーマンスの詳細については、「インスタンスのパフォーマンスメトリクス」をご参照ください。
アップグレード前は、ALB インスタンスのパフォーマンスが IP モード（静的または動的）によって異なり、VIP の自動スケーリングはサポートされていませんでした。単一インスタンスで 100 万 QPS を達成するには、IP アドレス数を動的にスケールアウトする必要がありました。
ALB インスタンスを IPv4 からデュアルスタック、またはデュアルスタックから IPv4 に切り替えることは可能ですか？
対応していません。
IPv4 またはデュアルスタックの新規インスタンスのみ作成可能です。
ネットワークと EIP
ALB インスタンスの VIP は Ping を無効化できますか？
アップグレード済み ALB インスタンス では、セキュリティグループ を使用したアクセストラフィックの管理が可能です。関連付けられたセキュリティグループで、インバウンド ICMP 拒否ルールを設定できます。
非アップグレード済み ALB インスタンスの場合、接続された EIP を インターネット境界ファイアウォール に追加し、インバウンド ICMP 拒否ポリシーを設定できます。
ALB インスタンスのパブリック帯域幅を増加させるにはどうすればよいですか？
ALB インスタンスが 2 つのゾーンにデプロイされ、Internet Shared Bandwidth インスタンスに関連付けていない場合、デフォルトのピークパブリック帯域幅は 400 Mbps です。
帯域幅をさらに確保する必要がある場合は、Internet Shared Bandwidth インスタンスを購入し、ALB インスタンスにアタッチされた EIP を Internet Shared Bandwidth インスタンスに関連付けます。
Internet Shared Bandwidth インスタンスの購入方法については、「Internet Shared Bandwidth の作成」をご参照ください。
Internet Shared Bandwidth インスタンスへのリソース追加方法については、「ALB インスタンスの作成と管理」および「パブリックネットワークインスタンスのピーク帯域幅の調整」をご参照ください。
Data Transfer Plan を使用して ALB のパブリックトラフィック料金を相殺できますか？
ALB インスタンスが弾性 IP アドレス（EIP）を使用してインターネットアクセスを提供する場合、EIP によって発生するインターネットトラフィックは、 汎用型 のデータ転送プランで相殺できます。
ALB インスタンスが Anycast 弾性 IP アドレス（Anycast EIP）を使用してインターネット上でサービスを提供する場合、Anycast EIP によって発生するインターネットトラフィックは、汎用型 のデータ転送プランでは相殺できません。
ALB インスタンスに関連付け可能な EIP の種類は何ですか？
ALB は、従量課金 EIP のみをサポートします。次の表では、ALB インスタンスに関連付けることができる EIP のタイプについて説明します。
課金方法 | インターネット課金方法 | 回線タイプ | セキュリティ保護 |
従量課金 | トラフィック課金 | BGP（マルチ ISP） | デフォルト |
トラフィック課金 | BGP（マルチ ISP）Pro | デフォルト | |
トラフィック課金 | BGP（マルチ ISP） | Anti-DDoS Pro / Premium |
EIP を ALB インスタンスに関連付ける際には、以下の制限にご注意ください。
同じ ALB インスタンスの異なるゾーンに割り当てられた EIP は、同じタイプである必要があります。
ALB インスタンスに関連付ける EIP は、Internet Shared Bandwidth インスタンスに追加することはできません。EIP を ALB インスタンスに関連付けた後、Server Load Balancer コンソールで EIP を Internet Shared Bandwidth インスタンスに追加できます。Internet Shared Bandwidth インスタンスは、EIP と同じ回線タイプを使用する必要があります。サブスクリプションおよび従量課金の Internet Shared Bandwidth インスタンスがサポートされています。詳細については、「最大帯域幅を変更する」をご参照ください。
サブスクリプション EIP および帯域幅課金方式の従量課金 EIP は、バインドできません。
EIP を ALB インスタンスに割り当てる際に、[EIP を購入] または [EIP を自動割り当て] を選択すると、システムはトラフィック課金方式の従量課金 EIP を作成します。この EIP は BGP(マルチ ISP) 回線を使用し、Anti-DDoS Origin Basic によって保護されます。
プライベート ALB インスタンスに EIP を関連付けることは可能ですか？
はい。
内部向け ALB に弾性 IP アドレス（EIP）を関連付けるには、インスタンスのネットワークタイプを変更して、内部向け ALB をインターネット向け ALB に変換します。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。
プライベートネットワークからパブリックネットワークへ変換すると、弾性 IP アドレス（EIP）が関連付けられ、パブリックネットワークの課金が発生します。詳細については、「EIP の課金」をご参照ください。
ALB インスタンスの EIP を BGP (マルチ ISP) Pro EIP に変更するにはどうすればよいですか？
変更は、 ALB インスタンスのネットワークタイプの変更により行えます。
ALB インスタンスのネットワークタイプをパブリックからプライベートに変更し、現在関連付けられている EIP をインスタンスから分離します。
ALB インスタンスのネットワークタイプを再度プライベートからパブリックに変更します。この操作時に、あらかじめ作成した 2 つのプレミアム BGP（マルチ ISP）EIP を選択します。
ALB にバインドされた EIP 間でトラフィック負荷が不均等になるのはなぜですか？
原因として、以下のいずれかが考えられます。
ビジネスのドメイン名が、ALB インスタンスの DNS 名ではなく、ALB インスタンスにバインドされた単一の EIP に解決されている。
ALB インスタンスの前に WAF や Anti-DDoS Proxy などのレイヤー 7 プロキシが配置されている。これらのプロキシの back-to-origin アルゴリズム（例：IP Hash）により、複数の EIP 間でトラフィックが均等に分散されない。
一部のクライアントが DNS 解決から得た A レコードをキャッシュしており、多数のリクエストが継続的に同一の EIP に送信されている。
ALB の DNS 削除についての留意点は何ですか？
アップグレード済み ALB インスタンス では、DNS 削除および DNS 復元操作がデフォルトでサポートされています。
アップグレードされていない ALB インスタンスの場合、静的 IP モードのインスタンスのみ DNS 削除および復元が可能です。動的 IP モードのインスタンスではサポートされていません。
DNS 削除操作を完了すると、該当ゾーン内の VIP に対する可用性プローブが停止します。また、該当ゾーンの VIP または EIP（IPv4 および IPv6 を含む）が ALB ドメイン名の DNS 解決から除外されます。IPv4 または IPv6 の VIP アドレスのみを削除することはできません。
リスナーと転送
ALB はトラフィックミラーリングをサポートしていますか？
詳細については、「本番環境のトラフィックをステージング環境にミラーする」をご参照ください。
ALB インスタンスがリスナーの転送ルールで指定された QPS 制限に達しないのはなぜですか？
仕組み：ロードバランシングシステムはクラスターデプロイにより SLB インスタンスにサービスを提供し、すべての外部アクセスリクエストをバックエンドサーバーに均等に分散して転送します。そのため、転送ルールで設定された最大 QPS は、各バックエンドサーバーに均等に割り当てられます。
各バックエンドサーバーの最大 QPS は、以下の式で計算されます：
各バックエンドサーバーの最大 QPS = 合計 QPS / (N - 1)。ここで N はサーバーグループ内のバックエンドサーバー数です。たとえば、コンソールの転送ルールで最大 QPS を 1,000 に設定し、バックエンドサーバー数が 8 の場合、各バックエンドサーバーの最大 QPS は以下の式で計算されます：1000 / (8 - 1) = 142。原因：永続接続数が少ないシナリオでは、サーバーグループ内のすべてのバックエンドサーバーに永続接続が割り当てられないことがあります。その結果、ALB インスタンスが最大 QPS に達しなくなることがあります。
推奨事項：サービス中断を防止するため、転送ルールにおける最大 QPS を必要に応じて適切な値に設定することを推奨します。Server Load Balancer リスナーの転送ルールにおける最大 QPS の設定方法については、「転送ルールの追加」をご参照ください。
ALB が転送するリクエストの長さ制限はどれくらいですか？調整可能ですか？
ALB へのリクエストの URI の最大長は 32 KB、リクエストヘッダーの最大長も 32 KB です。これらの制限はカスタマイズできません。アクセスログにおけるカスタムヘッダーのデフォルト長は 1 KB ですが、最大 4 KB まで拡張できます。拡張を希望される場合は、アカウントマネージャーにお問い合わせください。
クライアントリクエストのサイズが制限を超えると、HTTP 400 または 414 ステータスコードが返される場合があります。詳細については、「ALB のエラーステータスコード」をご参照ください。
データ量が大きい場合は、POST メソッドを使用してデータを送信することを推奨します。POST リクエストの本文の最大サイズは 50 GB です。
ALB 処理時間には、クライアントデータの受信および応答データの送信に要する時間が含まれますか？
ALB の処理時間には、クライアントデータの受信およびデータ送信に要する時間が含まれます。
クライアントから ALB への HTTP 持続的接続でサポートされるリクエストの最大数はいくつですか？
単一の持続的接続では、最大 100 回の連続リクエストがサポートされます。この上限を超えると、接続は自動的に閉じられます。
HTTPS リスナーを使用し、HTTP/2 を有効化した場合に限り、単一の持続的接続でサポートされるリクエストの最大数を 1,000 に増加できます。
ALB QUIC リスナーにおけるクライアントの Client Hello パケットの長さ制限はどれくらいですか？
QUIC リスナーを使用する場合、ALB はクライアントの Client Hello パケットに対して最小長制限を設定します。この長さは最低でも 1,024 バイトである必要があります。それより短い場合、ALB は「client hello too small」というメッセージを返して接続を閉じます。このチェックを通過するために、Client Hello パケットをヌル文字でパディングして 1,024 バイトにすることが可能です。
ALB イングレスを使用する際の留意点は何ですか？
通常、ALB イングレスを使用して作成された ALB インスタンスは、コンソールで手動で変更しないでください。 ALB の設定は、主に AlbConfig リソースから同期されます。 ALB イングレスの詳細については、「ALB イングレスの管理」および「ALB イングレスの操作」をご参照ください。
コンソールで手動で構成を変更した場合、AlbConfig の構成が更新されていないため、変更内容は上書きされます。これにより、アクセスログが無効化されたり、ルーティングルールが削除されたりするなどの問題が発生する可能性があります。
クロスオリジンリクエストに関する FAQ
CORS（オリジン間リソース共有）を設定した後、設定が有効にならず、ブラウザがプリフライトリクエストエラーを報告します。
「許可されたリクエストヘッダー」が「*」ではなく特定のヘッダー名にセットされている場合、テストとして「許可されたリクエストヘッダー」を「*」にセットできます。これで問題が解決した場合、プリフライトリクエストの Access-Control-Request-Headers に含まれる header_name が構成から欠落していることが、プリフライトリクエスト失敗の原因となっていないか確認できます。
プリフライトリクエストと実際のリクエストが異なる転送ルールにヒットしています。
ALB は多様な転送ルールマッチング方式をサポートしています。しかし、クロスオリジンシナリオにおけるプリフライトリクエストは、そのヘッダーおよびメソッドが実際のリクエストと異なるという特殊性があるため、CORS を使用する際には、ドメイン名を用いた転送ルールの設定を推奨します。これにより、プリフライトリクエストおよび実際のリクエストが CORS 未設定の転送ルールにヒットすることを防ぎ、不要な問題を回避できます。
CORS を設定する際、Access-Control-Allow-Headers レスポンスヘッダーはどのように生成され、返されるのでしょうか。
プリフライトリクエスト
ブラウザがクロスオリジンリクエストを開始し、以下の条件を満たす場合、最初に
OPTIONSメソッドでプリフライトリクエストを送信します。リクエストメソッドが
OPTIONSである。リクエストに
Access-Control-Request-Methodヘッダーが含まれている。
この場合、ALB はコンソールで設定したクロスオリジン転送ルールに基づき、
Access-Control-Allow-Headersレスポンスヘッダーを返却します。このレスポンスヘッダーの値は、ルールで許可されたリクエストヘッダーフィールドの一覧です。例：DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization通常のクロスオリジンリクエスト
OPTIONS 以外のリクエスト、またはプリフライト条件を満たさないシンプルなリクエストの場合、ALB は
Access-Control-Allow-Headersレスポンスヘッダーを返却しません。
ALB リスナーの転送ルールでヘッダー書き込みアクションを設定する場合、元のヘッダーの値を参照するにはどうすればよいですか？
キー には書き込むヘッダー名を、値 には選択した参照方法および値を参照する元のヘッダー名を指定します。たとえば、ヘッダー名 abc-abc を書き込み、元のヘッダー abc の値を参照する場合、転送ルールは元のヘッダー abc からフィールド値を取得し、新しいヘッダー abc-abc に割り当てます。
クライアント
サーバー側
証明書と HTTPS
ALB は相互認証をサポートしていますか？
いいえ、基本版 ALB インスタンスではサポートされていません。標準版または Web Application Firewall（WAF）対応版 ALB インスタンスの HTTPS リスナー では相互認証を有効化できます。基本版 ALB インスタンスで相互認証を使用するには、エディションの変更 を行う必要があります。
相互認証機能を使用する場合、Alibaba Cloud が発行した CA 証明書または第三者が発行した CA 証明書を選択できます。
Alibaba Cloud が発行した CA 証明書を選択する場合、既存のプライベート CA 証明書を選択するか、購入 する必要があります。
Alibaba Cloud が発行していない CA 証明書を選択する場合、既存の CA 証明書を選択するか、アップロード する必要があります。CA 証明書をアップロードするには、自己署名 CA 証明書のアップロード をクリックします。このボタンは、デフォルト CA 証明書の選択 ドロップダウンリスト内にあります。その後、証明書リポジトリ ページで、データソースを CA 証明書のアップロード に設定してリポジトリを作成し、自己署名ルート CA または自己署名サブオーディネートルート CA 証明書を証明書アプリケーションリポジトリにアップロードします。
ALB リスナーがワイルドカード証明書を使用する場合に満たす必要があるルールは何ですか？
ALB インスタンスに HTTPS リスナーを追加する場合、選択した証明書がワイルドカード証明書である場合、以下のルールに注意してください。
ワイルドカード証明書を選択すると、ALB は、単一のワイルドカード (
*) を含み、かつそのワイルドカード (*) がドメイン名の左端に配置されている証明書のみを識別できます。 たとえば、ALB は*.example.comや*test.example.comを識別できますが、test*.example.comは識別できません。ワイルドカードドメイン名のマッチングルール：
ワイルドカードドメイン名のレベル：ワイルドカードドメイン名は、ワイルドカードドメイン名と同じレベルの特定のドメイン名のみにマッチします。たとえば、
*.example.comはtest.example.comにマッチしますが、test.test.example.com（ワイルドカードドメイン名より 1 レベル下）にはマッチしません。IDNA 対応：
ワイルドカード証明書の左端ラベルにワイルドカード文字のみが存在する場合、IDNA ラベルはワイルドカードにマッチします。たとえば、
xn--fsqu00a.example.comは*.example.comにマッチします。ワイルドカード証明書の左端ラベルにワイルドカード文字以外の文字が含まれる場合、IDNA ラベルはその部分のワイルドカードにマッチしません。たとえば、
xn--fsqu00atest.example.comは*test.example.comにマッチしません。
マッチ範囲：ワイルドカード文字（
*）は、数字（0～9）、大文字および小文字の英字、ハイフン（-）のみにマッチします。たとえば、*.example.comはtest.example.comにマッチしますが、test_test.example.comにはマッチしません。
ALB コンソールから証明書をアップロードできますか？
いいえ、できません。
ALB は SSL 証明書サービスから直接証明書を使用するため、証明書は ALB コンソールではなく、SSL 証明書サービスコンソールにアップロードする必要があります。詳細については、「SSL 証明書をアップロードする」をご参照ください。
ALB 証明書を更新した後、ブラウザのドメイン名証明書の有効期限が変更されません。
この問題は、ALB インスタンスが透過型プロキシモードで WAF 2.0 と接続されており、WAF 側の証明書が更新されていないことが原因で発生することが多いです。WAF は ALB から定期的に証明書を同期します。証明書を即座に同期するには、WAF 側でトラフィックリダイレクトを無効化してから再度有効化することで、証明書ステータスの強制更新を行います。ただし、この操作により、サービスが 1～2 秒間瞬断します。
ヘルスチェック
リスナーのヘルスチェック構成を変更するにはどうすればよいですか？
ヘルスチェックが正常なのに 502 ステータスコードが返されるのはなぜですか？
これは通常、ALB インスタンスのバックエンドサーバーが過負荷状態であるためです。ALB インスタンスのバックエンドサーバーが過負荷状態になると、ヘルスチェックが正常に完了していても、アクセス要求に応答できない場合があります。詳細については、「Linux インスタンスの高負荷のトラブルシューティング」をご参照ください。
同一サーバーグループ内のすべてのバックエンドサーバーがヘルスチェックに失敗した場合、ALB はリクエストをどのように転送しますか？
ALB は、サービス可用性を維持するためにスケジューリングアルゴリズムに基づいてリクエストを分散します。この問題を解決するには、ログを確認してバックエンドサーバーにエラーが発生していないかを確認するか、ヘルスチェック構成を確認してください。詳細については、「ALB のヘルスチェック問題のトラブルシューティング」をご参照ください。
トラブルシューティング
ALB 経由でサービスにアクセスできない場合のトラブルシューティング手順を教えてください。
以下の手順に従ってください。
ドメイン名の CNAME 解決の確認：新しく作成された ALB インスタンスは、その DNS 名を直接使用してアクセスすることはできません。カスタムドメイン名から ALB インスタンスの DNS 名への CNAME 解決を設定する必要があります。
nslookupまたはdigコマンドを使用して、解決が正しく行われているかを確認できます。詳細については、「ALB インスタンスの DNS 名の概要」をご参照ください。インスタンスのネットワークタイプの確認：プライベート ALB インスタンスは、内部 VPC アクセスのみをサポートし、パブリックネットワークを介して直接アクセスすることはできません。パブリックネットワークアクセスを有効化するには、インスタンスのネットワークタイプをパブリックに変更し、EIP を関連付けます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。
リスナーおよび転送ルールの確認：ALB コンソールで、リスナーが作成されているかを確認します。リスナーのポートおよびプロトコルが正しく設定されていること、および転送ルールがリクエストのドメイン名およびパスと一致することを確認します。
ヘルスチェックステータスの確認：ALB コンソールで、バックエンドサーバーのヘルスチェックステータスを確認します。バックエンドサーバーがヘルスチェックに失敗している場合、ALB がリクエストを正常に転送できない可能性があります。
バックエンドサービスの正常動作の確認：バックエンドサーバーに直接ログインし、
curl -I http://<バックエンドサーバーのプライベートネットワーク IP アドレス>:<ポート>を使用して、バックエンドサービスが正常に応答することを確認します。セキュリティグループルールの確認：バックエンドサーバーおよび ALB インスタンスのセキュリティグループルールを確認し、リスナーポートおよびリクエストの送信元アドレス CIDR ブロックが許可されていることを確認します。
ALB 経由でアクセスした際の高遅延のトラブルシューティング手順を教えてください。
ALB はアプリケーション指向のサービスであり、リクエストをバックエンドサーバーに転送します。このため、バックエンドサーバーへの直接アクセスと比較して、わずかな（ただし正常な）遅延の増加が発生します。
遅延が著しく高い場合、以下の手順でトラブルシューティングを行ってください。
アクセスログの有効化と遅延フィールドの分析：「ALB アクセスログ」を有効化し、以下のフィールドに注目します。
request_time：Server Load Balancer が最初のリクエストメッセージを受信してから、確認応答を返すまでの時間（秒単位）。upstream_response_time：ALB がバックエンドサーバーとの接続を確立してから、すべてのデータを受信して接続を閉じるまでの時間（秒単位）。
遅延の原因の特定：
upstream_response_timeが大きい場合、遅延の原因は通常、バックエンドサーバーの処理が遅いことです。バックエンドアプリケーションのパフォーマンス、データベースクエリの効率、CPU やメモリなどのリソース使用率をトラブルシューティングするか、バックエンドサーバーを追加して負荷を分散させることを検討してください。request_timeがupstream_response_timeよりも大幅に大きい場合、遅延の原因はクライアントと ALB の間のネットワークパスである可能性が高いです。クライアントから ALB エンドポイントへの継続的なpingテストまたは MTR ルートトレースを実行して、ネットワークパスの問題をトラブルシューティングすることを推奨します。
クロスリージョンアクセスのシナリオ：クライアントと ALB インスタンスが異なるリージョンにある場合、物理的な距離によるネットワーク遅延は避けられません。クロスリージョンアクセスの体験を最適化するには、Global Accelerator（GA）の使用を推奨します。
ALB 経由でドメイン名を使用してサービスにアクセスできない場合の対処方法を教えてください。
新しく作成された ALB インスタンスは、その DNS 名を直接使用してアクセスすることはできません。サービスにアクセスするには、カスタムドメイン名を ALB インスタンスの DNS 名に CNAME レコードで解決する必要があります。CNAME レコードの設定が正しく行われているにもかかわらず、サービスにアクセスできない場合（403 が返される、または接続がリセットされる）、最も一般的な原因はドメイン名の ICP 登録が完了していないことです。
以下の手順でトラブルシューティングを行うことを推奨します。
CNAME 解決設定の確認：
nslookupまたはdigコマンドを使用して、ドメイン名が ALB インスタンスの DNS 名に正しく解決されているかを確認します。詳細については、「CNAME 解決の設定」をご参照ください。ドメイン名の ICP 登録ステータスの確認：関連する規制によると、中国本土のリージョンでパブリックネットワーク経由でサービスにアクセスする場合、ドメイン名は ICP 登録を完了している必要があります。未登録の場合、アクセスはブロックされます。Alibaba Cloud ICP 登録システム にログインして、ドメイン名の ICP 登録ステータスを確認してください。ドメイン名が登録されていない場合は、まず ICP 登録を完了してください。詳細については、「ICP 登録の流れ」をご参照ください。
ICP 登録情報に Alibaba Cloud を追加する必要があるかどうかの確認：ドメイン名が他のクラウドサービスプロバイダーで ICP 登録を完了しているが、Alibaba Cloud 上で初めて使用される場合、ICP 登録情報に Alibaba Cloud をサービスプロバイダーとして追加する必要があります。これを怠ると、アクセスがブロックされる可能性があります。
一般的なエラーステータスコードとその原因
500（内部サーバーエラー）
バックエンドサーバーで内部エラーが発生し、リクエストを実行できませんでした。
バックエンドが直接 500 を返す：アクセスログを確認します。
upstream_statusが500の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスのトラブルシューティングを行ってください。バックエンドサーバーが接続を異常終了：バックエンドサーバーが完全なレスポンスを送信する前に接続を異常終了しました。バックエンドサーバーでパケットキャプチャを行い、異常終了の原因をトラブルシューティングしてください。
502（不正なゲートウェイ）
HTTP または HTTPS リスナーがクライアントリクエストを受信した後、ALB がバックエンドサーバーにリクエストを適切に転送できなかったか、バックエンドサーバーからのレスポンスを受信できませんでした。
バックエンドが直接 502 を返す：アクセスログを確認します。
upstream_statusが502の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスのトラブルシューティングを行ってください。バックエンドが他のエラーステータスコードを返す：たとえば
504や444などですが、ALB は一律に502を返します。アクセスログのstatusおよびupstream_statusフィールドを確認し、上流のステータスコードに基づいてトラブルシューティングを行ってください。ALB とバックエンドサーバー間の TCP 通信エラー：バックエンドサービスが正常に実行中であるか、サービスポートが正しくリッスンしているか、または TCP ハンドシェイクが正常であるかをパケットキャプチャで確認してください。
バックエンドサーバーの backlog が満杯：これにより、新しい接続要求が拒否または破棄されます。バックエンドサーバーで
netstat -s | grep -i listenを実行し、dropカウンターがあるかどうかを確認してください。クライアントパケット長がバックエンドサーバーの MTU を超過：ヘルスチェックなどの短いパケットは正常ですが、長いパケットが異常になります。バックエンドサーバーでパケットキャプチャを行い、パケット長が要件を満たしているかを分析してください。
バックエンドサーバーのレスポンスパケット形式が異常または不正な HTTP ヘッダーを含む：バックエンドサーバーでパケットキャプチャを行い、レスポンスパケット形式が標準であるかを分析してください。
バックエンドサーバーがリクエストをタイムリーに処理しなかった：バックエンドサーバーのログを確認し、CPU およびメモリ使用率を確認してください。
503（サービス一時的に利用不可）
サーバーが一時的に利用不可です。通常、トラフィックの超過またはバックエンドサービスの利用不可が原因です。
バックエンドが直接 503 を返す：アクセスログを確認します。
upstream_statusが503の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスのトラブルシューティングを行ってください。クライアントリクエストが ALB の速度制限をトリガー：
CloudMonitor を使用して
1 秒あたりのリクエスト数メトリクスを確認します。CloudMonitor は分単位のデータを表示するため、秒単位の超過状況を反映しない場合があります。アクセスログを確認します。
upstream_statusフィールドの値が-の場合、リクエストはバックエンドサーバーに到達していません。レスポンスパケットヘッダーを確認します。
ALB-QPS-Limited:Limitedフィールドが含まれている場合、リクエストが ALB の速度制限をトリガーしています。
クライアントが ALB の IP に直接アクセス、またはドメイン名経由でのアクセス時に DNS 解決が異常：これにより、トラフィックが少数の IP に集中し、制限を超える可能性があります。クライアントは ALB のドメイン名経由でアクセスすることを推奨します（「ALB インスタンスの CNAME レコードの設定」を参照し、DNS 解決が正常であることを確認してください）。
リスナーにバックエンドサーバーが設定されていない、または設定されたバックエンドサーバーの重みが
0
504（ゲートウェイタイムアウト）
バックエンドサーバーのレスポンスがタイムアウトしました。
バックエンドが直接 504 を返す：アクセスログを確認します。
upstream_statusが504の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスのトラブルシューティングを行ってください。ALB とバックエンドサーバー間の接続確立がタイムアウト：デフォルトのタイムアウトは 5 秒で、変更できません。バックエンドサーバーのレスポンスがタイムアウトした理由をパケットキャプチャでトラブルシューティングしてください。
バックエンドサーバーのレスポンスがタイムアウト：接続要求タイムアウト はデフォルトで 60 秒です。CloudMonitor の
UpstreamResponseTimeメトリクスおよびアクセスログのupstream_response_timeフィールドを確認し、バックエンドサーバーのレスポンスがタイムアウトしたかどうかを判断できます。
WAF 統合
WAF 2.0 の透過型プロキシモードと WAF 3.0 の統合モードの違いは何ですか？
両者の主な違いは以下のとおりです。
WAF 2.0 の透過型プロキシモード：リクエストは、ALB または CLB に転送される前に WAF によってフィルタリングされます。透過型プロキシモードでは、リクエストが 2 つのゲートウェイを通過します。WAF および Server Load Balancer（SLB）の両方のタイムアウト期間および証明書を設定する必要があります。
WAF 3.0 の統合モード：WAF はバイパスモードで展開され、クライアントリクエストは直接 ALB に到達します。リクエストがバックエンドサーバーに転送される前に、ALB がリクエストコンテンツを抽出して WAF に送信し、フィルタリングを行います。統合モードでは、リクエストは 1 つのゲートウェイを通過するため、ゲートウェイ間での証明書および設定の同期が不要となり、同期関連の問題を回避できます。
詳細については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。
ALB と WAF を併用する際の注意事項
ALB インスタンスに WAF 3.0 の保護を有効化するには、サービスベースの接続タイプ の使用を推奨します。この方法では、WAF 機能強化型 ALB インスタンスを使用します。
対応リージョン：
エリア
リージョン
中国
中国（成都）、中国（青島）、中国（北京）、中国（広州）、中国（杭州）、中国（ウランチャブ）、中国（上海）、中国（深セン）、中国（張家口）、中国（香港）
アジア太平洋
フィリピン（マニラ）、インドネシア（ジャカルタ）、日本（東京）、マレーシア（クアラルンプール）、シンガポール、タイ（バンコク）、韓国（ソウル）
ヨーロッパおよびアメリカ
ドイツ（フランクフルト）、米国（バージニア）、米国（シリコンバレー）、メキシコ
中東
サウジアラビア（リヤド - パートナー運営）、UAE（ドバイ）
WAF のバージョン：WAF 3.0 を使用する必要があります。アカウントに WAF 2.0 インスタンスがある場合、まず WAF 2.0 インスタンスの解放 または WAF 3.0 への移行 を行う必要があります。
デフォルトでは、ALB はバックエンドサーバーグループに転送されるリクエストにおいて
X-Forwarded-Protoヘッダーを有効化していません。WAF 2.0 インスタンスを解放した後、ALB に直接アクセスすると、バックエンドサービスがプロトコル（HTTP/HTTPS）を正しく識別できないため、無限ループリダイレクトなどのサービス例外が発生する可能性があります。この問題を防ぐため、ALB リスナー構成でX-Forwarded-Protoリクエストヘッダーを手動で有効化する必要があります。機能の利用可否：ALB インスタンス向け WAF では、データ漏えい防止モジュールおよびボット管理モジュール内のウェブサイト向けアンチクローラールールの自動 Web SDK 統合機能はサポートされていません。
アカウントに既存の WAF 2.0 インスタンスを使用する場合、パブリック向けの基本版および標準版 ALB インスタンスは、WAF 2.0 の透過型プロキシモードによる保護をサポートしています。対応リージョン：中国（杭州）、中国（上海）、中国（深セン）、中国（成都）、中国（北京）、中国（張家口）。プライベート ALB インスタンスは WAF 2.0 の保護をサポートしていません。
CLB および ALB は、WAF 2.0 の透過型プロキシモードおよび WAF 3.0 の統合モードをサポートしていますか？
製品 | WAF 2.0（透過型プロキシモード） | WAF 3.0（統合モード） |
CLB | 対応しています。 WAF 2.0 を CLB に透過型プロキシモードで接続する方法の詳細については、以下のトピックをご参照ください。 | 対応していません。 |
ALB |
| 対応しています。 対応リージョンおよび関連操作の詳細については、「ALB インスタンスへの WAF 保護の有効化」をご参照ください。 |
WAF 2.0 の透過型プロキシで、タイムアウトおよび証明書の同期がうまくいかないのはなぜですか？
WAF 2.0 を透過モードで統合する場合、クライアントリクエストは ALB または CLB に転送される前に WAF によってフィルタリングされます。リクエストが 2 つのゲートウェイを通過するため、WAF と Server Load Balancer の間で構成を同期する必要があります。タイムアウト期間や証明書の変更により、この同期に遅延が発生することがあります。