レスポンス エラーのトラブルシューティング

このページでは、API に対するリクエストから返ってきたレスポンスで発生するエラーのトラブルシューティング方法について説明します。

Upstream backend unavailable

エラーコード 14 と「upstream backend unavailable」というメッセージが表示される場合は、Extensible Service Proxy（ESP）がサービスのバックエンドに到達できないことを示しています。以下をご確認ください。

  • バックエンド サービスが実行されていることを確認します。確認方法はバックエンドによって異なります。

  • バックエンド サービスの正しい IP アドレスポートが指定されていることを確認します。
    • GKE の場合は、デプロイ マニフェスト ファイル（deployment.yaml とも呼ばれます）の中にある ESP --backend フラグの値（短縮オプションは -a）を確認します。
    • Compute Engine の場合は、docker run コマンドで ESP --backend フラグの値（短縮オプションは -a）を確認します。

reset reason: connection failure

HTTP コード 503 または gRPC コード 14 が返され、「upstream connect error or disconnect/reset before headers. reset reason: connection failure」というメッセージが表示された場合、ESPv2 がサービスのバックエンドに到達できないことを示しています。

問題を解決するには、以下の項目を再確認してください。

バックエンド アドレス

ESPv2 に正しいバックエンド アドレスを構成する必要があります。一般的な問題としては、次のようなものがあります。

  • バックエンド アドレスのスキームは、バックエンド アプリケーション タイプと一致する必要があります。OpenAPI バックエンドは http://、gRPC バックエンドは grpc:// になります。
  • Cloud Run にデプロイされた ESPv2 の場合、バックエンド アドレスのスキームは https:// または grpcs:// になります。s は、バックエンドで TLS を設定するよう ESPv2 に指示します。

DNS ルックアップ

デフォルトでは、ESPv2 はドメイン名を IPv6 アドレスに解決します。IPv6 の解決に失敗した場合、ESPv2 は IPv4 アドレスにフォールバックします。

一部のネットワークでは、フォールバック メカニズムが意図したとおりに動作しないことがあります。代わりに、--backend_dns_lookup_family フラグを使用して、ESPv2 に IPv4 アドレスの使用を強制できます。

このエラーは、Cloud Run にデプロイされた ESPv2 のサーバーレス VPC コネクタを構成する場合によく発生します。VPC は IPv6 トラフィックをサポートしていません。

API is not enabled for the project

API キーをリクエストで送信したときに「API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project」のようなエラー メッセージが返された場合は、API キーが作成された Google Cloud プロジェクトと API の Google Cloud プロジェクトが異なることを示しています。この問題を解決するには、API が関連付けられているのと同じ Google Cloud プロジェクトで API キーを作成するか、API キーが作成された Google Cloud プロジェクトで API を有効にします。

Service control request failed with HTTP response code 403

エラーコード 14 が表示され、「Service control request failed with HTTP response code 403」というメッセージが表示された場合は、プロジェクトで Service Control API（servicecontrol.googleapis.com）が有効になっていないことを示しています。

  1. Endpoints と ESP に必要なすべてのサービスがプロジェクトで有効になっていることを確認するには、必要なサービスの確認をご覧ください。

  2. 必要な権限を確認するを参照して、ESP を実行しているインスタンスに関連付けられたサービス アカウントに必要なすべての権限を確認します。

Method doesn't allow unregistered callers

gRPC API 構成ファイルで allow_unregistered_calls: false が指定されている場合は、ESP がエラー「Method doesn't allow unregistered callers」で応答しますが、API へのリクエストで key という名前のクエリ パラメータに割り当てられた API キーがありません。

API を呼び出すために API キーを生成する必要がある場合は、API キーの作成をご覧ください。

Method does not exist

レスポンス「Method does not exist」は、指定された URL パス上で HTTP メソッド（GET や POST など）が見つからなかったことを示します。これをトラブルシューティングするには、デプロイしたサービス構成を比較して、リクエストで送信しているメソッド名と URL パスが一致しているか確認します。

  1. Google Cloud コンソールで、プロジェクトの [エンドポイント] の [サービス] ページに移動します。

    [Endpoints] の [サービス] ページに移動

  2. API が複数ある場合は、リクエストの送信先 API を選択します。

  3. [デプロイの履歴] タブをクリックします。

  4. 最新のデプロイを選択して、サービス構成を確認します。

Transport is closing

エラーコード 13 と「transport is closing」というメッセージが表示される場合は、ESP に到達できないことを示しています。

ESP エラーログをチェックします。確認方法はバックエンドによって異なります。詳しくは以下をご覧ください。

予期しないレスポンス

HTTP レスポンスがバイナリのように表示される場合は、HTTP1 ポートを使用しようとしたときに、リクエストが HTTP2 ポートを使用して API に到達している可能性があります。

ポート構成オプションで ESP を確認してください。短形式フラグの -p（HTTP1 用）と -P（HTTP2 用）は似ているため、代わりに長形式フラグ（HTTP1 用の --http_port、HTTP2 用の --http2_port）を使用することをおすすめします。

ESP バックエンドの構成ミスが原因で予期せぬレスポンスが発生することもあります。バックエンド フラグ（-a または --backend）が gRPC URL（--backend=grpc://127.0.0.1:8081 など）に設定されていることを確認してください。

ESP フラグの詳細については、ESP 起動オプションをご覧ください。

Cloud Logging のログを確認する

Cloud Logging のログを使用してレスポンス エラーのトラブルシューティングを行うには、

  1. Google Cloud コンソールで [Logging] ページに移動します。

    [ログ エクスプローラ] ページに移動

  2. ページの上部で、Google Cloud プロジェクトを選択します。

  3. 左側のプルダウン メニューを使用して、[生成された API] > [YOUR_SERVICE_NAME] を選択します。

  4. レスポンス エラーを示す行が表示されるまで、時間範囲を調整します。

  5. JSON ペイロードを展開し、error_cause を探します。

    • error_cause が application に設定されている場合は、コードに問題があることを示しています。

    • error cause がそれ以外であり、ご自身で問題を解決できない場合は、ログをエクスポートし、Google へのご連絡の際にご提供ください。

詳しくは以下をご覧ください。