このページでは、Cloud Run の使用中に発生する可能性のあるエラーのトラブルシューティング方法について説明します。Personalized Service Health は、基盤となる Google Cloud インフラストラクチャに起因するすべての Cloud Run インシデントを公開し、プロジェクトに影響する Google Cloud サービスの中断を特定します。また、Personalized Service Health イベントにアラートを設定することも検討してください。すべての Google Cloud サービスに影響するインシデントについては、Google Cloud Service Health ダッシュボードを確認してください。
公開 Issue Tracker では、既存の問題を確認したり、新しい問題を報告します。
このページに記載されていないエラー メッセージについては、Cloud Run の既知の問題をご覧ください。このガイドの手順でエラーが解決しない場合は、サポートにお問い合わせください。
Cloud Run の問題を解決する方法については、次のセクションをご覧ください。
デプロイエラー
このセクションでは、Cloud Run で発生する一般的なデプロイエラーと、そのトラブルシューティング方法について説明します。
コンテナを起動できない
デプロイしようとすると、次のエラーが発生します。
Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.
この問題の解決方法は次のとおりです。
コンテナ イメージをローカルで実行できることを確認します。コンテナ イメージをローカルで実行できない場合は、問題をローカルで診断して修正する必要があります。
コンテナが正しいポートでリクエストをリッスンしているかどうかを確認します。コンテナは、Cloud Run によって定義され、
PORT環境変数で指定されているポートで受信リクエストをリッスンする必要があります。ポートを指定する方法については、サービスのコンテナを構成するをご覧ください。コンテナが、すべてのネットワーク インターフェース（通常
0.0.0.0で表記）でリッスンしているかどうかを確認します。特に、コンテナは127.0.0.1でリッスンする必要はありません。コンテナ ランタイムの契約に従って、コンテナ イメージを 64 ビット Linux 用にコンパイルされていることを確認します。
Cloud Logging を使用して、
stdoutログまたはstderrログでアプリケーション エラーを探します。また、キャプチャされたクラッシュを Stackdriver Error Reporting で確認することもできます。エラーや障害を修正するために、コードまたはリビジョン設定の更新が必要になる場合があります。また、サービスのトラブルシューティングをローカルで行うこともできます。
コンテナのインポート エラー
デプロイしようとすると、次のエラーが発生します。
The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.
この問題の解決方法は次のとおりです。
Windows ベースの Docker イメージでは、外部レイヤが使用されます。Cloud Run のコントロール プレーンは外部レイヤをサポートしていません。この問題を解決するには、Docker デーモンで
--allow-nondistributable-artifactsフラグを設定してみてください。
この機能はサポートされていない
Cloud Run Admin API を呼び出すと、次のエラーが発生します。
The feature is not supported in the declared launch stage
このエラーは、Cloud Run Admin API を直接呼び出して、リリース ステージのアノテーションまたはフィールドを指定せずにベータ版機能を使用した場合に発生します。
この問題を解決するには、リクエストにリリース ステージ フィールドを追加します。
v1 または v2 REST API を使用するときにリリース ステージの参照を追加する方法については、次の例をご覧ください。
JSON と v1 REST API を使用して、リリース ステージのアノテーションをクライアント リクエストに追加します。
"annotations": { "run.googleapis.com/launch-stage": "BETA" }
JSON と v2 REST API を使用して、LaunchStage の参照をクライアント リクエストに追加します。
"launchStage": "BETA"
YAML と v1 REST API を使用して、サービス リクエストにリリース ステージのアノテーションを追加します。
kind: Service metadata: annotations: run.googleapis.com/launch-stage: BETA
ユーザー root が見つからない
顧客管理の暗号鍵が --key パラメータに指定されていると、次のエラーが発生します。
ERROR: "User \"root\""not found in /etc/passwd
この問題を解決するには、Dockerfile で USER root の代わりに USER 0 を指定します。
デフォルトの Compute Engine サービス アカウントが削除されている
デプロイ中に次のエラーが発生します。
ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).
この問題は、次のいずれかのシナリオで発生します。
デフォルトの Compute Engine サービス アカウントがプロジェクトに存在せず、デプロイ時に
--service-accountフラグでサービス アカウントが指定されていない。サービスをデプロイするデベロッパーまたはプリンシパルに、デフォルトの Compute Engine サービス アカウントをデプロイするために必要な権限がない。
この問題を解決するには:
--service-accountフラグを使用してサービス アカウントを指定します。gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT指定したサービス アカウントに、デプロイに必要な権限があることを確認します。
デフォルトの Compute Engine サービス エージェントが Google Cloud プロジェクトに存在するかどうかを確認する手順は次のとおりです。
Google Cloud コンソールで、Identity and Access Management の [権限] ページに移動します。
[Google 提供のロール付与を含める] チェックボックスをオンにします。
[プリンシパル] リストで、
PROJECT_NUMBER-compute@developer.gserviceaccount.com形式の Compute Engine サービス エージェントの ID を見つけます。
Cloud Build サービス アカウントに関する問題
Cloud Build サービス アカウントに必要な権限が付与されていないか、無効になっている場合、ソースのデプロイ中に次のエラーが発生します。
ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.
Cloud Build が新しいプロジェクトでサービス アカウントを使用する際のデフォルトの動作が変更されました。この変更の詳細については、デフォルトの Cloud Build サービス アカウントの変更をご覧ください。この変更により、ソースコードから Cloud Run に初めてデプロイする新しいプロジェクトで、ソースからデプロイするための権限が不足しているデフォルトの Cloud Build サービス アカウントが使用される可能性があります。
この問題の解決方法は次のとおりです。
デフォルトのサービス アカウントの変更に関する Cloud Build のガイダンスを確認し、これらの変更を無効にする。
ビルドサービス アカウントに Cloud Run ビルダー（
roles/run.builder）ロールを付与する。
Cloud Run サービス エージェントにイメージの読み取り権限がない
別のプロジェクトの gcr.io ドメインを使用し、Artifact Registry に保存されているイメージを使用してプロジェクトからデプロイしようとすると、次のエラーが発生します。
Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.
別のプロジェクトの Artifact Registry に保存されているイメージを使用してプロジェクトからデプロイしようとすると、次のエラーが表示されることもあります。
ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct and that the above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that the image is from project PROJECT_ID, which is not the same as this project PROJECT_ID.
この問題を解決するには、次のトラブルシューティングの推奨事項を行います。
他の Google Cloud プロジェクトからコンテナ イメージをデプロイする手順に沿って、プリンシパルに必要な権限があることを確認します。
この問題は、プロジェクトが VPC Service Controls 境界にあり、Cloud Run サービス エージェントからのリクエストを禁止する制限が Cloud Storage API にある場合にも発生することがあります。この問題を解決する方法は以下のとおりです。
Google Cloud コンソールでログ エクスプローラを開きます（Cloud Run ページの [ログ] ページは使用しないでください）。
クエリ フィールドに次のテキストを入力します。
protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog" severity=ERROR protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS" protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"このクエリを使用した後にログエントリが表示された場合は、そのログエントリを調べて、VPC Service Controls ポリシーを更新する必要があるかどうかを判断します。既存のアクセス ポリシーに
service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.comの追加が必要になることもあります。
ソースのデプロイの権限がない
ソースからデプロイすると、次のエラーが発生することがあります。
ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission to access namespaces instance PROJECT_ID (or it may not exist): Google Cloud Run Service Agent does not have permission to get access tokens for the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT permissioniam.serviceAccounts.getAccessTokenon the service account. Alternatively, if the service account is unspecified or in the same project you are deploying in, ensure that the Service Agent is assigned the Google Cloud Run Service Agent roleroles/run.serviceAgent. This command is authenticated as EMAIL_ADDRESS, which is the active account specified by the [core/account] property.
すべての Cloud Run サービスは、サービスが他のリソースにアクセスするときに ID として機能するサービス アカウントに関連付けられています。このサービス アカウントは、デフォルトのサービス アカウント（PROJECT_NUMBER-compute@developer.gserviceaccount.com）またはユーザー管理のサービス アカウントのいずれかです。
複数のサービスが異なるリソースにアクセスする環境では、デフォルトのサービス アカウントではなく、異なるユーザー管理サービス アカウントを持つサービスごとの ID を使用できます。
この問題を解決するには、サービス ID として使用されるサービス アカウントに対するサービス アカウント ユーザーのロール（roles/iam.serviceAccountUser）をデプロイ担当者アカウントに付与します。この事前定義ロールには、サービスまたはリビジョンにサービス アカウントを関連付けるために必要な iam.serviceAccounts.actAs 権限が含まれています。ユーザー管理のサービス アカウントを作成するユーザーには iam.serviceAccounts.actAs 権限が自動的に付与されますが、他のデプロイ担当者は、ユーザー管理のサービス アカウントを作成するユーザーからこの権限を付与してもらう必要があります。
作成する新しいサービス アカウントのアクセス要件の詳細については、専用のサービス アカウントの作成に関する推奨事項を取得するをご覧ください。
ソースのデプロイを完了するための十分な権限がユーザーに付与されていない
デプロイ担当者アカウントにプロジェクトに対する必要な権限がない場合は、次のエラーが発生します。
ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does not havestorage.objects.createaccess to the Google Cloud Storage object. Permissionstorage.objects.createdenied on resource (or it may not exist). This command is authenticated as EMAIL_ADDRESS which is the active account.
このエラーを解決するには、次の Identity and Access Management ロールを付与するよう管理者に依頼してください。
- プロジェクトに対する Cloud Run ソース デベロッパー（
roles/run.sourceDeveloper）。 - プロジェクトに対する Service Usage ユーザー（
roles/serviceusage.serviceUsageConsumer）。 - Cloud Run サービス ID に対するサービス アカウント ユーザー（
roles/iam.serviceAccountUser）。詳細については、デプロイ権限をご覧ください。
配信エラー
このセクションでは、配信で発生する可能性がある問題と、その修正方法について説明します。
HTTP 404: 未検出
配信中に次の問題が発生します。
`HTTP 404`:Not found
次のシナリオでは、HTTP 404 エラーが発生することがあります。
リクエスト URL またはアプリケーション コードが正しくないと、
404エラーが返されます。この問題の解決方法は次のとおりです。リクエストした URL が正しいことを確認します。URL は、Google Cloud コンソールのサービスの詳細ページか、次のコマンドで確認できます。
gcloud run services describe SERVICE_NAME | grep URLアプリが
404エラーコードを返す場所を調べます。アプリから404が返された場合は、Cloud Logging で確認できます。また、ローカルで実行するときに、アプリが404エラーコードを返さないことを確認します。構成したポートで、リクエストを受信する準備が整う前にアプリのリッスンを開始しないようにしてください。
次のシナリオでは、リクエストがコンテナに到達せず、
404エラーが発生します。特に、Cloud Run サービスの上り（内向き）設定が「内部」または「内部と Cloud Load Balancing」に設定されている場合、リクエストが指定されたネットワークの制限を満たしてない。
Cloud Run サービスのデフォルトの
run.appの URL が無効になっていて、クライアントがそのrun.appの URL でサービスにアクセスしようとした。
どちらのシナリオでも、Cloud Logging で
404エラーは見つかりません。次のフィルタを適用しても見つかりません。resource.type="cloud_run_revision" log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests" httpRequest.status=404同じ上り（内向き）設定の場合、プロジェクトと IP アドレスを含む呼び出し元のコンテキストに基づいて、VPC Service Controls がリクエストをブロックする可能性があります。VPC Service Controls のポリシー違反を確認するには:
Google Cloud コンソールでログ エクスプローラを開きます。
クエリ フィールドに次のテキストを入力します。
resource.type="audited_resource" log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy" resource.labels.method="run.googleapis.com/HttpIngress"このクエリを使用した後にログエントリが表示された場合は、そのログエントリを調べて、VPC Service Controls ポリシーを更新する必要があるかどうかを判断します。
Python ランタイムを使用するロードバランサでサービス エンドポイントにアクセスします。この問題を解決するには、ロードバランサの URL マスクを確認し、ロードバランサに指定した URL パスが Python ソースコードのパスと一致していることを確認します。
使用可能なコンテナ インスタンスがない
配信中に次のエラーが発生します。
HTTP 429 The request was aborted because there was no available instance. The Cloud Run service might have reached its maximum container instance limit or the service was otherwise not able to scale to incoming requests. This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.
この問題を解決するには、サービスのコンテナ インスタンス数の指標を確認します。使用量が上限に近づいている場合は、この上限の引き上げを検討してください。詳細については、サービスの最大インスタンス数を設定するをご覧ください。より多くのインスタンスが必要な場合は、割り当ての増加をリクエストします。
Cloud Run がトラフィック レートを管理できない
次のエラーは、配信中またはサービスがコンテナ インスタンスの上限に達していない場合に発生します。
HTTP 500 The request was aborted because there was no available instance
この問題の解決方法は次のとおりです。
考えられる根本原因を解決します。
- トラフィックが急増している。
- コールド スタート時間が長い。
- リクエスト処理時間が長い、またはリクエスト処理時間が急増している。
- サービスがコンテナ インスタンスの上限（
HTTP 429）に達した。 - Cloud Run サービスに起因する一時的な要因。
指数バックオフを実装し、ドロップできないリクエストの再試行を試みます。10 秒の解像度にズームインすると、トラフィックまたはリクエストの処理時間の急激な増加が Cloud Monitoring にのみ表示される可能性があります。
この問題の根本原因が、Cloud Run のみに起因する一時的なエラーの増加にある場合は、サポートにお問い合わせください。
オペレーションが実装されていない
リージョン asia-southeast1 にジョブをデプロイし、southeast1-asia または asia-southeast を使用してジョブを呼び出すなど、Cloud Run ジョブを呼び出すときに間違った REGION を指定すると、次のエラーが発生します。
HTTP 501 Operation is not implemented, or supported, or enabled.
サポートされているリージョンのリストについては、Cloud Run のロケーションをご覧ください。
デフォルトの認証情報が見つからない
ファイルの欠落、無効な認証情報パス、環境変数の割り当ての誤りなどにより、アプリケーションが正しく認証されない場合に、次のエラーが発生します。
HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default credentials were not found.
この問題を解決するには:
Google アカウントに関連付けられている認証情報を使用して、アプリケーションのデフォルト認証情報（ADC）を設定します。次を使用して ADC を構成します。
gcloud auth application-default loginログイン画面が表示されます。ログインすると、ADC で使用されるローカル認証情報ファイルに認証情報が保存されます。
GOOGLE_APPLICATION_CREDENTIALS環境変数を使用して、 Google Cloud プロジェクトでの認証情報の JSON ファイルの保存先を指定します。詳細については、アプリケーションのデフォルト認証情報を設定するをご覧ください。
コンテナ インスタンスがメモリ上限を超えている
Cloud Logging での配信中に、次の HTTP 500 または HTTP 503 エラーが発生します。
While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.
この問題を解決するには:
- コンテナ インスタンスが使用可能なメモリを超えているかどうかを判断します。
varlog/systemログで、関連するエラーを探します。 - インスタンスがメモリ制限を超えている場合は、メモリ上限を上げることを検討してください。
Cloud Run では、ローカル ファイル システムに書き込まれるファイルは使用可能なメモリにカウントされます。これには、/var/log/* と /dev/log 以外の場所に書き込まれるログファイルも含まれます。
同時実行の設定が高いため、一部のリクエストを処理できない
次のエラーは、コンテナ インスタンスによるリクエストの処理で CPU の負荷が高くなり、その結果、すべてのリクエストを処理できない場合に発生します。
HTTP 503 The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.
この問題の解決方法は次のとおりです。
サービスのコンテナ インスタンスの最大数を増やす。
サービスの同時実行を減らす。詳細については、インスタンスあたりの最大同時リクエスト数を設定するをご覧ください。
保留中のキュー リクエストに関連する Cloud Logging エラー
Cloud Run がトラフィックを管理するのに十分な速度でスケールアップできない場合、次のいずれかのエラーが発生します。
-
The request was aborted because there was no available instance:
severity=WARNING( Response code: 429 ) Cloud Run cannot scale due to themax-instanceslimit you set during configuration. -
severity=ERROR( Response code: 500 ) Cloud Run intrinsically cannot manage the rate of traffic.
この問題の解決方法は次のとおりです。
スケーリング失敗の原因となる可能性がある根本原因に対処します。たとえば、次のような原因があります。
- トラフィックが急増している。
- コールド スタート時間が長い。
- リクエスト処理時間が長い。
- ソースコードのエラー率が高い。
- 最大インスタンス数の上限に達し、システムのスケーリングが阻止される
- Cloud Run サービスに起因する一時的な要因。
スケーリングの問題の解決とパフォーマンスの最適化の詳細については、一般的な開発のヒントをご覧ください。
HTTP トリガーベースのサービスまたは関数の場合、クライアントに指数バックオフを実装し、ドロップできないリクエストの再試行を試みます。Workflows からサービスをトリガーする場合は、
try/retry構文を使用します。バックグラウンドまたはイベント ドリブンのサービスまたは関数の場合、Cloud Run は 1 回以上の配信をサポートします。再試行を明示的に有効にしなくても、Cloud Run はイベントを自動的に再配信し、実行を再試行します。詳細については、イベント ドリブン関数の再試行をご覧ください。
コールド スタートに関連する問題がある場合は、最小インスタンス数を構成して、コールド スタートの回数を減らし、請求額の増加を抑えます。
問題の根本原因が Cloud Run に起因する一時的なエラーである場合、または問題についてサポートが必要な場合は、サポートにお問い合わせください
ID トークンの署名が Google によって編集された
開発フェーズとテストフェーズで次のエラーが発生します。
SIGNATURE_REMOVED_BY_GOOGLE
このエラーは、次のようなシナリオで発生する可能性があります。
ユーザーが Google Cloud CLI または Cloud Shell を使用してログインする。
ユーザーが
gcloudコマンドを使用して ID トークンを生成する。ユーザーが、ID トークンを使用して非公開の Cloud Run サービスを呼び出そうとしている。
これはデフォルトの動作です。Google では、このように生成された ID トークンが非公開の Cloud Run サービスを再生しないように、セキュリティの懸念からトークン署名を削除します。
この問題を解決するには、新しい ID トークンで限定公開サービスを呼び出します。詳細については、限定公開サービスをテストするをご覧ください。
ログでの OpenBLAS 警告
NumPy などの OpenBLAS ベースのライブラリを第 1 世代の実行環境で使用している場合、次の警告がログに記録されることがあります。
OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k`
OpenBLAS の警告は、第 1 世代の実行環境で使用されるコンテナ サンドボックスで低レベルのハードウェア機能が公開されていない場合に発生します。この警告はサービスに影響しません。OpenBLAS 警告がログに記録されないようにするには、第 2 世代の実行環境に切り替えます。
バインドするマシンの IP アドレスを取得する際に Spark が失敗する
バインディング マシンの IP アドレスの取得中に Spark が失敗すると、次のいずれかのエラーが発生します。
assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>
この問題を解決するには、Dockerfile で SPARK_LOCAL_IP 環境変数を 127.0.0.1 に設定します（例: ENV SPARK_LOCAL_IP="127.0.0.1"）。SPARK_LOCAL_IP 環境変数を設定しないと、デフォルトは localhost ではなく IPv6 になります。また、Spark は RUN export SPARK_LOCAL_IP="127.0.0.1" として設定された環境変数を認識しません。
NFS を使用してファイルにアクセスできない
| エラー | 推奨される対処方法 |
|---|---|
mount.nfs: Protocol not supported |
debian や adoptopenjdk/openjdk11 などの一部のベースイメージで、nfs-kernel-server の依存関係がありません。 |
mount.nfs: Connection timed out |
接続がタイムアウトした場合は、filestore インスタンスの正しい IP アドレスを指定していることを確認します。 |
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE |
アクセスがサーバーから拒否された場合は、ファイル共有名が正しいことを確認します。 |
Cloud Storage FUSE を使用してファイルにアクセスできない
Cloud Storage FUSE のトラブルシューティング ガイドをご覧ください。
接続とセキュリティに関するエラー
このセクションでは、Cloud Run の一般的な接続エラーとセキュリティ エラー、およびそのトラブルシューティング方法について説明します。
クライアントが適切に認証されていない
配信中に次のエラーが発生します。
HTTP 401: The request was not authorized to invoke this service
この問題を解決するには:
サービス アカウントが Cloud Run サービスを呼び出す場合は、Google によって署名された ID トークンのオーディエンス クレーム（
aud）を次のように設定します。audをhttps://SERVICE.run.appまたはhttps://REGION-PROJECT_ID.cloudfunctions.net/FUNCTIONの形式で受信側のサービスの URL に設定する場合は、サービスで認証が必要になります。Cloud Run URL またはロードバランサの URL を使用して Cloud Run サービスを呼び出します。認証済みリクエストの送信例については、HTTPS リクエストで呼び出すをご覧ください。audをnnn-xyz.apps.googleusercontent.comの形式で、ウェブ アプリケーション タイプの OAuth 2.0 クライアント ID のクライアント ID に設定すると、IAP で保護された HTTPS ロードバランサ経由で Cloud Run サービスを呼び出すことができます。このアプローチは、異なるリージョンの複数の Cloud Run サービスをバックエンドとするアプリケーション ロードバランサにおすすめします。audを構成済みのカスタム オーディエンスに設定する場合は、指定された値をそのまま使用します。たとえば、カスタム オーディエンスがhttps://service.example.comの場合、オーディエンス クレームの値もhttps://service.example.comにする必要があります。
リクエストに
Authorization: Bearer ID_TOKENヘッダーまたはカスタム認可用のX-Serverless-Authorization: Bearer ID_TOKENヘッダーが含まれていることと、トークンがアクセス トークンや更新トークンではなく、ID トークンであることを確認してください。次のシナリオでは、認可形式が正しくないため401エラーが発生する可能性があります。認可トークンの形式が無効。
認可ヘッダーが有効な署名付きの JSON Web Token（JWT）ではない。
認可ヘッダーに複数の JWT が含まれている。
リクエストに複数の認可ヘッダーが存在する。
JWT のクレームを確認するには、jwt.io ツールを使用します。
メタデータ サーバーから ID とアクセス トークンを取得して、Cloud Run サービスまたはジョブの ID でリクエストの認証を行い、HTTP プロキシによって下り（外向き）トラフィックをルーティングするときに、無効なトークンが取得された場合は、次のホストを HTTP プロキシ例外に追加します。
169.254.*または169.254.0.0/16*.google.internal
401エラーは通常、Cloud クライアント ライブラリがメタデータ サーバーからアプリケーションのデフォルト認証情報を取得し、REST または gRPC 呼び出しを認証するときに発生します。HTTP プロキシ例外を定義しない場合、次の動作が発生します。異なる Google Cloud ワークロードが Cloud Run サービスまたはジョブと HTTP プロキシをホストしている場合、Cloud クライアント ライブラリが認証情報を取得しても、HTTP プロキシ ワークロードに割り当てられたサービス アカウントがトークンを生成します。トークンに、目的の Google Cloud API オペレーションの実行に必要な権限がない可能性があります。これは、サービス アカウントがトークンを Cloud Run サービスまたはジョブではなく、HTTP プロキシ ワークロードのメタデータ サーバーのビューから取得するためです。
HTTP プロキシが Google Cloudでホストされておらず、プロキシを使用してメタデータ サーバー リクエストをルーティングする場合、トークン リクエストは失敗し、Google Cloud API オペレーションは認証されません。
未認証の呼び出しを許可するために、サービスを再デプロイします（組織でサポートされている場合）。これはテストに便利です。
クライアントにサービスの起動権限がない
サービスの呼び出し中に次のいずれかのエラーが発生します。
HTTP 403: The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.
認可トークンの生成に使用された IAM メンバーに run.routes.invoke 権限がない場合、403 エラーが発生することがあります。この権限は、トークンを生成するユーザーに付与します。
また、Cloud Logging に resource.type = "cloud_run_revision" 形式のエラーのエントリがある場合は、次の手順でエラーを解決します。
誰でもサービスを呼び出せるようにするには、IAM の設定を更新してサービスを公開します。
特定の ID のみがサービスを呼び出せるようにするには、適切な認可トークンを使用してサービスを呼び出します。
デベロッパーまたはエンドユーザーがサービスを呼び出す場合は、
run.routes.invoke権限を付与します。この権限は、Cloud Run 管理者（roles/run.admin）ロールと Cloud Run 起動元（roles/run.invoker）ロールで付与できます。サービス アカウントがサービスを呼び出す場合は、サービス アカウントが Cloud Run サービスのメンバーであることを確認して、Cloud Run 起動元（
roles/run.invoker）のロールを付与します。認可トークンが指定されていない呼び出しで、
403エラーが発生することがあります。有効な認可トークンを使用して呼び出ししても403エラーが発生する場合は、トークンを生成する IAM メンバーにrun.routes.invoke権限を付与します。
403 エラーが発生し、ログエントリ resource.type = "cloud_run_revision" が見つからない場合は、上り（内向き）設定が All に構成されている Cloud Run サービスが VPC Service Controls によってブロックされている可能性があります。VPC Service Controls の拒否に関するトラブルシューティングの詳細については、404 エラーをご覧ください。
ウェブブラウザからサービスにアクセスするとエラーが発生する
ウェブブラウザから Cloud Run サービスにアクセスすると、次の問題が発生します。
403 Forbidden
Your client does not have permission to get URL from this server.
ウェブブラウザから Cloud Run サービスを呼び出すと、ブラウザはサービスに GET リクエストを送信します。ただし、リクエストには呼び出し元のユーザーの認可トークンが含まれていません。この問題の解決方法は次のとおりです。
Cloud Run で Identity-Aware Proxy（IAP）を使用します。IAP を使用すると、HTTPS 経由でアクセスされるアプリケーションの一元的な認可レイヤを確立できます。IAP を使用すると、ネットワーク レベルのファイアウォールの代わりに、アプリケーション レベルのアクセス制御モデルを使用できます。IAP を使用して Cloud Run を構成する方法の詳細については、Cloud Run 用に Identity-Aware Proxy を有効にするをご覧ください。
一時的な回避策として、Google Cloud CLI で Cloud Run プロキシを使用して、ウェブブラウザからサービスにアクセスします。ローカルでサービスをプロキシするには、次のコマンドを実行します。
gcloud run services proxy SERVICE --project PROJECT-IDCloud Run は限定公開サービスを
http://localhost:8080（または--portで指定したポート）にプロキシして、アクティブなアカウントのトークンを提供するか、指定した別のトークンを提供します。これは、ブラウザでウェブサイトや API を非公開でテストする場合におすすめの方法です。詳細については、限定公開サービスのテストをご覧ください。サービスに対する未認証の呼び出しを許可します。これは、テストを行う場合や、サービスが公開 API またはウェブサイトである場合に便利です。
ピアによって接続がリセットされた
ネットワーク上のピアが、アプリケーションによって確立された TCP 接続を予期せず閉じると、次のいずれかのエラーが発生します。
Connection reset by peer
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
grpc.StatusRuntimeException: UNAVAILABLE: io exception
psycopg.OperationalError: the connection is closed
ECONNRESET
この問題の解決方法は次のとおりです。
CPU スロットリングを使用してバックグラウンド処理を実行する場合は、インスタンスベースの課金設定を使用します。
アウトバウンド リクエストのタイムアウト内であることを確認してください。アプリケーションの接続がこのしきい値を超えてアイドル状態を持続する場合、ゲートウェイで接続を終了する必要があります。
デフォルトでは、Cloud Run の TCP ソケット オプション
keepaliveは無効になっています。サービスレベルでkeepaliveオプションを直接構成する方法はありません。各ソケット接続でkeepaliveオプションを有効にするには、アプリケーションでこの接続に使用しているクライアント ライブラリに応じて、新しい TCP ソケット接続を開くときに必要なソケット オプションを指定します。インフラストラクチャの更新により、アウトバウンド接続がリセットされる場合があります。アプリケーションで長期間の接続を再利用する場合は、切断された接続の再利用を避けるため、接続を再確立してアプリケーションを構成することをおすすめします。
HTTP プロキシを使用して Cloud Run サービスまたはジョブの下り（外向き）トラフィックをルーティングし、プロキシが接続の最大期間を適用している場合、接続プールを使用して確立された TCP 接続など、長時間実行される接続がプロキシによって自動的に切断されることがあります。これにより、すでに閉じられた接続を再利用するときに、HTTP クライアントでエラーが発生します。下り（外向き）トラフィックを HTTP プロキシ経由でルーティングする場合は、接続の検証、再試行、指数バックオフを実装する必要があります。接続プールの場合、接続の有効期間、アイドル状態の接続、接続のアイドル タイムアウトの最大値を構成します。
接続タイムアウト
次のエラーは、アプリケーションがリモートホストとの新しい TCP 接続の作成を試みて、接続の確立に時間がかかりすぎる場合に発生します。
java.io.IOException: Connection timed out
ConnectionError: HTTPSConnectionPool
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded
接続タイムアウトの問題を解決する手順は次のとおりです。
VPC コネクタまたはダイレクト VPC 下り（外向き）を使用してすべての下り（外向き）トラフィックを VPC ネットワーク経由で転送する場合は、次の操作を行います。
VPC コネクタの上り（内向き）トラフィックを許可するために必要なファイアウォール ルールをすべて定義します。
VPC ファイアウォール ルールで、VPC コネクタまたはダイレクト VPC 下り（外向き）サブネットからの上り（内向き）トラフィックが宛先ホストまたはサブネットに到達できるようにする必要があります。
宛先ホストに正しいトラフィックがルーティングされ、その逆のルーティングも正しく行われるように必要なルートすべてが存在している必要があります。これは、VPC ネットワーク ピアリングまたはハイブリッド クラウド接続を介して下り（外向き）トラフィックをルーティングする場合に重要です。この場合、パケットはリモートホストに到達する前に複数のネットワークを通過します。
HTTP プロキシを使用して Cloud Run サービスまたはジョブからのすべての下り（外向き）トラフィックをルーティングする場合は、プロキシを使用してリモートホストに到達できるようにする必要があります。
HTTP プロキシ経由で転送されるトラフィックは、プロキシのリソース使用状況に応じて遅延する可能性があります。プロキシを使用して HTTP 下り（外向き）トラフィックをルーティングする場合は、再試行、指数バックオフ、またはサーキット ブレーカーを実装します。
HTTP プロキシの例外を構成する
HTTP プロキシを使用して Cloud Run サービスまたはジョブの下り（外向き）トラフィックをルーティングする場合は、レイテンシ、接続タイムアウト、接続リセット、認証エラーを防ぐため、Cloud APIs の例外と、プロキシされないホストとサブネットの例外を追加してください。
プロキシされないホストとサブネットには、少なくとも次のものが含まれている必要があります。
127.0.0.1169.254.*または169.254.0.0/16localhost*.google.internal*.googleapis.com
プロキシされないホストには、必要に応じて次のものが含まれている場合があります。
*.appspot.com*.run.app*.cloudfunctions.net*.gateway.dev*.googleusercontent.com*.pkg.dev*.gcr.io
下り（外向き）ネットワークの HTTP プロキシ例外を設定するには、次の構成を行います。
- 環境変数:
NO_PROXYまたはno_proxy。 Java 仮想マシンのフラグ:
http.nonProxyHosts:システム プロパティ
https.nonProxyHostsが定義されていません。このシステム プロパティは、HTTP と HTTPS の両方に適用されます。システム プロパティ
http.nonProxyHostsは CIDR 表記をサポートしていません。パターン マッチング式を使用する必要があります。
不正なレスポンスまたはコンテナ インスタンスの接続の問題
コンテナ インスタンスの接続に問題があると、次のエラーが発生します。
HTTP 503 The request failed because either the HTTP response was malformed or connection to the instance had an error.
この問題の解決方法は次のとおりです。
Cloud Logging で次のエラーを確認します。
メモリ不足エラー。コンテナ インスタンスがメモリ制限を超えているというエラー メッセージがログに記録されている場合は、コンテナ インスタンスがメモリ制限を超えているセクションの推奨事項をご覧ください。
ライブネス プローブの失敗。ログに次のエラーが記録されます。
LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.
インスタンスがタイムアウト期間内にプローブに応答しなかった場合は、次の操作を行います。
計測のロギングとトレースを有効にして、レイテンシの増加の原因を特定します。
ライブネス プローブのタイムアウト期間を長くします。
リクエストが Cloud Run で設定されたリクエスト タイムアウトに達する前にエラーコード
503で終了している場合は、言語フレームワークのリクエスト タイムアウトの設定を更新します。Node.js デベロッパーは、使用しているバージョンに応じて
server.setTimeoutによるserver.timeoutプロパティの更新が必要になります（server.setTimeout(0)を使用して無制限のタイムアウトを設定します）。Python デベロッパーは Gunicorn のデフォルトのタイムアウト（
[CRITICAL] WORKER TIMEOUT）を更新する必要があります。
負荷テスト中など、ダウンストリーム ネットワークのボトルネックにより
503エラーが発生することがあります。たとえば、サービスがサーバーレス VPC アクセス コネクタ経由でトラフィックをルーティングする場合、次の操作を行い、コネクタがスループットのしきい値を超えていないことを確認します。Google Cloud コンソールでサーバーレス VPC アクセスを開きます。
スループット グラフのヒストグラムで赤色の棒を確認します。赤色のバーが表示されている場合は、コネクタの最大インスタンス数またはインスタンス タイプを増やすことを検討してください。あるいは、サーバーレス VPC アクセス コネクタ経由で送信されたトラフィックを圧縮します。
コンテナ インスタンスが 1 秒あたり 800 件を超えるリクエストを受信すると、使用可能な TCP ソケットが枯渇する可能性があります。この問題を解決するには、サービスで HTTP/2 を有効にして、HTTP/2 をサポートするようにサービスに必要な変更を加えます。
ゲートウェイ タイムアウト エラー
サービスが指定された時間内にレスポンスを返さず、リクエストが終了すると、次のエラーが発生します。
HTTP 504 The request has been terminated because it has reached the maximum request timeout.
このエラーの詳細については、コンテナ ランタイムの契約をご覧ください。
この問題のトラブルシューティング方法は次のとおりです。
サービスが実行時間の長いリクエストを処理する場合は、リクエストのタイムアウトを長くします。
ロギングとトレースを計測し、構成したリクエスト タイムアウトの前にアプリで処理に時間がかかっている場所を把握します。
インフラストラクチャの更新に伴い、アウトバウンド接続がリセットされる場合があります。アプリケーションで長期間の接続を再利用する場合は、切断された接続の再利用を避けるため、接続を再確立してアプリケーションを構成することをおすすめします。
アプリのロジックやエラー処理によっては、
504エラーは、アプリケーションが切断された接続を再利用しようとしている信号であり、構成したリクエスト タイムアウトに達するまでリクエストがブロックされる場合があります。ライブネス プローブを使用して、永続的なエラーを返すインスタンスを終了します。アプリのコード内で発生したメモリ不足エラー（
java.lang.OutOfMemoryErrorなど）でコンテナ インスタンスが終了するとは限りません。メモリ使用量がコンテナのメモリ上限を超えていなければ、Cloud Run はインスタンスを終了しません。アプリがアプリレベルのメモリ不足エラーを処理する方法によっては、構成したリクエスト タイムアウトになるまでリクエストが処理されない可能性があります。コンテナ インスタンスを終了する手順は次のとおりです。
アプリレベルのメモリ上限をコンテナメモリの上限よりも大きく構成します。
ライブネス プローブを使用して、永続的なエラーを返すインスタンスを終了します。
証明書のプロビジョニング中にカスタム ドメインが停止する
カスタム ドメインをマッピングすると、次のいずれかのエラーが発生します。
The domain is available over HTTP. Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.
この問題を解決するには:
24 時間以上経過するまで待ちます。SSL 証明書のプロビジョニングには通常 15 分ほどかかりますが、場合によっては最長で 24 時間ほどかかることがあります。
Google 管理者ツールボックスの Dig ツールを使用して、ドメイン登録事業者で DNS レコードが正しく更新されたことを確認します。ドメイン登録事業者の DNS レコードは、Google Cloud コンソールが追加を促すものと一致している必要があります。
次のいずれかの方法で、アカウントでドメインのルートを確認します。
検証済みドメイン所有者を追加する手順に沿って、アカウントが検証済み所有者としてリストされていることを確認します。
Search Console を使用します。
ドメインの証明書の有効期限が切れていないことを確認します。有効期限の範囲を確認するには、次のコマンドを使用します。
echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout
クライアントの接続解除が Cloud Run に反映されない
Cloud Run で HTTP/1.1 を使用すると、クライアントの接続解除イベントが Cloud Run コンテナに反映されません。
この問題を解決するには、クライアントの接続解除を伝播する WebSocket または HTTP/2.0 を使用します。
ネットワーク ファイル システムに関する問題
詳細については、NBD、9P、CIFS/Samba、Ceph ネットワーク ファイル システムの使用をご覧ください。