本頁面由 Cloud Translation API 翻譯而成。

排解 Cloud Run 問題

本頁面說明如何排解您在使用 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 進行編譯。

注意： 如果您在 ARM 架構的機器上建構容器映像檔，則在與 Cloud Run 搭配使用時，可能無法正常運作。如要解決這個問題，請使用 Cloud Build 建構映像檔。
使用 Cloud Logging 在 stdout 或 stderr 記錄檔中尋找應用程式錯誤。您也可以查看 Error Reporting 擷取的當機事件。

您可能需要更新程式碼或修訂版本設定，才能修正錯誤或當機事件。您也可以在本機排解服務問題。

容器匯入錯誤

嘗試部署時會發生下列錯誤：

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

如要解決這個問題，請按照下列步驟操作：

請確認容器的檔案系統不含非 UTF-8 字元。
部分 Windows 版 Docker 映像檔會使用外部層。Cloud Run 的控制層不支援外部層。如要解決這個問題，請嘗試在 Docker 守護程序中設定 --allow-nondistributable-artifacts 標記。

不支援這項功能

呼叫 Cloud Run Admin API 時會發生以下錯誤：

The feature is not supported in the declared launch stage

直接呼叫 Cloud Run 管理員 API 並使用 Beta 版功能時，如果未指定發布階段註解或欄位，就會發生這個錯誤。

如要解決這個問題，請在要求中加入「啟動階段」欄位。

如要使用 v1 或 v2 REST API 新增啟動階段參照，請參考下列範例：

使用 JSON 和 v1 REST API 為用戶端要求新增啟動階段註解：

  "annotations": {
    "run.googleapis.com/launch-stage": "BETA"
  }

LaunchStage 參照使用 JSON 和 v2 REST API 的用戶端要求：
```
"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 0，而非 USER root。

已刪除預設的 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

確認您指定的服務帳戶具備部署所需的權限。

如要確認 Google Cloud 專案中是否有預設的 Compute Engine 服務代理，請按照下列步驟操作：

在 Google Cloud 控制台中，前往「Identity and Access Management」(身分和存取權管理) 的「Permissions」(權限) 頁面：

前往「權限」
選取「包含 Google 提供的角色授予項目」核取方塊。
在「Principals」清單中，找出 Compute Engine 服務代理人的 ID，其格式為 PROJECT_NUMBER-compute@developer.gserviceaccount.com。

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 Build 預設服務帳戶異動」。因此，首次從原始碼部署至 Cloud Run 的新專案可能會使用預設 Cloud Build 服務帳戶，但該帳戶的權限不足以從原始碼部署。

如要解決這個問題，請按照下列步驟操作：

請參閱 Cloud Build 的相關指南，瞭解預設服務帳戶異動情形，並選擇不採用這些異動。
將 Cloud Run 建構工具 (roles/run.builder) 角色授予建構服務帳戶。

Cloud Run 服務代理人缺少讀取圖片的權限

當您嘗試從專案中部署使用 Artifact Registry 中儲存的映像檔時，會發生下列錯誤，這會使用不同專案中的 gcr.io 網域：

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 Storage API 受到限制，禁止 Cloud Run 服務代理提出要求，也可能會發生這個問題。修正方法如下：
1. 在 Google Cloud 控制台中開啟「Logs Explorer」(記錄檔探索工具)。(請勿使用 Cloud Run 頁面中的「Logs」頁面)：
  
  前往「Logs Explorer」
2. 在查詢欄位中輸入下列文字：
```
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"
```
3. 如果您在使用這項查詢後看到任何記錄項目，請檢查記錄項目，判斷是否需要更新 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
permission iam.serviceAccounts.getAccessToken on 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 role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

每個 Cloud Run 服務都會與服務帳戶建立關聯，當服務存取其他資源時，服務帳戶會做為身分識別服務。這個服務帳戶可能是預設服務帳戶 (PROJECT_NUMBER-compute@developer.gserviceaccount.com) 或使用者管理的服務帳戶。

在有多項服務存取不同資源的環境中，您可以使用個別服務身分搭配不同的使用者管理服務帳戶，而非預設服務帳戶。

如要解決這個問題，請在用作服務身分的服務帳戶上，將「服務帳戶使用者」角色 (roles/iam.serviceAccountUser) 授予部署者帳戶。這個預先定義的角色包含 iam.serviceAccounts.actAs 權限，這是在服務或修訂版本上附加服務帳戶所需的權限。建立使用者管理服務帳戶的使用者會自動獲得 iam.serviceAccounts.actAs 權限，但其他部署者必須由建立使用者管理服務帳戶的使用者授予這項權限。

如要進一步瞭解您建立的任何新服務帳戶的存取權要求，請參閱「取得建立專屬服務帳戶的最佳化建議」。

使用者權限不足，無法完成來源部署作業

如果部署者帳戶缺少專案的必要權限，就會發生下列錯誤：

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

如要解決這項錯誤，請要求管理員授予您下列身分與存取權管理 (IAM) 角色：

在專案中使用 Cloud Run 原始碼開發人員 (roles/run.sourceDeveloper)。
專案中的服務使用情形消費者 (roles/serviceusage.serviceUsageConsumer)。
Cloud Run 服務身分中的服務帳戶使用者 (roles/iam.serviceAccountUser)。詳情請參閱「部署權限」。

從其他專案部署 Cloud Run 服務時發生錯誤 Google Cloud

從來源專案部署 Cloud Run 服務至目標專案時，會發生下列錯誤：

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on 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 role roles/run.serviceAgent.

如要解決這個問題，請按照下列步驟操作：

在您用於目標專案中服務身分的服務帳戶上，授予「服務帳戶使用者」 (roles/iam.serviceAccountUser) 角色。
將服務帳戶憑證建立者 (roles/iam.serviceAccountTokenCreator) 角色授予目標專案中的 Cloud Run 服務帳戶。將 Cloud Run 服務代理人電子郵件地址 (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) 新增為來源專案中的使用者主體。
關閉 iam.disableCrossProjectServiceAccountUsage 機構政策。

如需詳細操作說明，請參閱「為服務設定服務身分」。

放送錯誤

本節列出您在放送時可能會遇到的問題，並提供修正每個問題的建議。

HTTP 404：找不到

放送期間發生下列問題：

`HTTP 404`:Not found

您可能會在下列情況中遇到 HTTP 404 錯誤：

錯誤的要求網址或應用程式代碼會傳回 404 錯誤。如要解決這個問題，請按照下列步驟操作：
1. 請確認要求的網址是否正確。您可以在 Google Cloud 控制台的服務詳細資料頁面中驗證網址，也可以執行下列指令：
```
gcloud run services describe SERVICE_NAME | grep URL
```
2. 檢查應用程式傳回 404 錯誤代碼的位置。如果應用程式傳回 404，您可以在 Cloud Logging 中找到該項目。此外，請確認在本機執行應用程式時，應用程式不會傳回 404 錯誤代碼。
3. 請確認應用程式在準備好接收要求之前，不會開始在所設定的通訊埠上聽取。
在下列情況下，要求無法傳送至容器，導致 404 錯誤：
- 要求不符合指定的網路限制，尤其是當 Cloud Run 服務的Ingress 設定設為「Internal」或「Internal and Cloud Load Balancing」時。
- Cloud Run 服務的預設 run.app 網址已停用，而用戶端嘗試透過該 run.app 網址存取服務。
在上述兩種情況下，即使您套用下列篩選器，也無法在 Cloud Logging 中找到 404 錯誤：
```
resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404
```
在相同的入口設定下，VPC Service Controls 可能會根據呼叫端的內容 (包括專案和 IP 位址)封鎖要求。如要檢查是否違反 VPC Service Controls 政策，請按照下列步驟操作：
1. 在 Google Cloud 控制台中開啟 Logs Explorer：
  
  前往「Logs Explorer」
2. 在查詢欄位中輸入下列文字：
```
resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"
```
3. 如果您在使用這項查詢後看到任何記錄項目，請檢查記錄項目，判斷是否需要更新 VPC Service Controls 政策。
使用 Python 執行階段，透過負載平衡器存取服務端點。如要解決這個問題，請驗證負載平衡器的網址遮罩，並確保您為負載平衡器指定的網址路徑與 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.

如要解決這個問題，請檢查服務的 Container instance count 指標，如果用量接近上限，請考慮提高這個限制。詳情請參閱「為服務設定最大執行個體數」，如需更多執行個體，請要求提高配額。

Cloud Run 無法管理流量頻率

在放送期間或服務未達容器執行個體上限時，會發生下列錯誤：

HTTP 500
The request was aborted because there was no available instance

如要解決這個問題，請按照下列步驟操作：

解決下列可能的根本原因：
- 流量突然大幅增加。
- 冷啟動時間過長。
- 要求處理時間過長，或要求處理時間突然增加。
- 服務已達容器執行個體數量上限 (HTTP 429)。
- 與 Cloud Run 服務相關的暫時性因素。
針對用戶端不得捨棄的要求，實作指數輪詢和重試機制。流量或要求處理時間短暫且突然增加的情況，只有在放大至 10 秒解析度時，才可能會顯示在 Cloud Monitoring 中。
如果問題的根本原因是 Cloud Run 發生大量暫時性錯誤，請與支援團隊聯絡。

未實作作業

在叫用 Cloud Run 工作時，如果您指定的 REGION 不正確 (例如在 asia-southeast1 地區部署工作，並使用 southeast1-asia 或 asia-southeast 叫用工作)，就會發生下列錯誤：

HTTP 501
Operation is not implemented, or supported, or enabled.

如需支援的區域清單，請參閱 Cloud Run 位置。

找不到預設憑證

如果應用程式因缺少檔案、憑證路徑無效或環境變數指派錯誤而無法正確驗證，就會發生下列錯誤：

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

如何解決這個問題：

安裝並初始化 gcloud CLI。
使用與 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 the max-instances limit you set
during configuration.

severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

如要解決這個問題，請按照下列步驟操作：

解決可能導致擴充失敗的根本原因，例如：
- 流量突然大幅增加。
- 冷啟動時間過長。
- 要求處理時間過長。
- 原始碼錯誤率偏高。
- 達到執行個體數量上限，導致系統無法進行縮放。
- 與 Cloud Run 服務相關的暫時性因素。
如要進一步瞭解如何解決資源調度問題及最佳化效能，請參閱一般開發提示。
針對以 HTTP 觸發為基礎的服務或函式，請讓用戶端針對不得捨棄的要求實作指數型回退和重試機制。如果您要透過工作流程觸發服務，可以使用 try/retry 語法來達成這項目標。
針對背景或事件驅動服務或函式，Cloud Run 支援至少一次傳送。即使未明確啟用重試功能，Cloud Run 也會自動重新提交事件並重試執行。詳情請參閱「重試事件驅動函式」。
針對冷啟動相關問題，請設定執行個體數量下限，以減少冷啟動次數，進而降低帳單金額。
如果問題的根本原因是 Cloud Run 發生大量暫時性錯誤，或是您需要協助解決問題，請與支援團隊聯絡。

Google 遮蓋的 ID 權杖簽名

開發和測試階段發生下列錯誤：

SIGNATURE_REMOVED_BY_GOOGLE

這個錯誤可能會在下列情況下發生：

使用者透過 Google Cloud CLI 或 Cloud Shell 登入。
使用者會使用 gcloud 指令產生 ID 權杖。
使用者嘗試使用 ID 權杖來叫用非公開的 Cloud Run 服務。

這是預期的預設行為。基於安全考量，Google 會移除憑證簽名，以免任何非公開的 Cloud Run 服務重播以這種方式產生的 ID 權杖。

如要解決這個問題，請使用新的 ID 權杖叫用私人服務。詳情請參閱「測試私人服務」。

記錄檔中的 OpenBLAS 警告

如果您使用 OpenBLAS 程式庫 (例如 NumPy) 搭配第一代執行環境，可能會在記錄檔中看到以下警告：

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

如果第一代執行環境使用的容器沙箱未公開低階硬體功能，就會發生 OpenBLAS 警告。這項警告不會影響您的服務。如要避免 OpenBLAS 警告記錄項目，請切換至第二代執行環境。

取得要繫結的機器 IP 位址時，Spark 會失敗

如果 Spark 在取得繫結機器的 IP 位址時失敗，就會發生下列其中一個錯誤：

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 環境變數，系統會預設為使用 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 疑難排解指南。

CPU 使用率偏低時的延遲時間偏高

即使 Cloud Monitoring 顯示平均 CPU 使用率遠低於一般 60% 的調整目標，您的服務仍可能會發生高要求延遲，或無法在負載下調整為更大的規模。

可能的原因：

如果應用程式是為 CPU 受限工作單執行緒，但部署在具有多個 vCPU 的執行個體上，就可能發生這種情況。應用程式可能會將一個 vCPU 核心用盡，而其他核心則大多處於閒置狀態。Cloud Run 自動配置器會使用所有 vCPU 的平均 CPU 使用率，在這種情況下，這個平均值可能偏低，因此無法以 CPU 為依據進行調整。

解決方法：

如果是單執行緒應用程式：
- 如果服務的記憶體需求可滿足，建議您設定 1 個 vCPU (請參閱「記憶體限制和 CPU 最低值」)。這有助於 CPU 使用率指標準確反映負載。
- 如果記憶體需求超過 1 個 vCPU 限制，就需要使用多個 vCPU，以 CPU 為基礎的自動調整大小功能可能就會失效。在這種情況下，請降低並行數量上限，以便根據要求總處理量提早進行調整。請參閱「並行設定」。
針對多 vCPU 設定：請確保應用程式架構可有效運用所有已分配的 vCPU (例如，使用多個 worker 程序或執行緒)。

連線和安全性錯誤

本節說明 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，則您的服務必須要求驗證。使用 Cloud Run 網址或負載平衡器網址叫用 Cloud Run 服務。如需傳送已驗證要求的範例，請參閱「透過 HTTPS 要求叫用」。
- 如果您將 aud 設為 OAuth 2.0 用戶端 ID 的用戶端 ID，且該 ID 的類型為 網頁應用程式，並使用 nnn-xyz.apps.googleusercontent.com 格式，您就可以透過由 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 服務驗證要求或透過 HTTP Proxy 轉送資料流量來驗證工作身分，但卻收到無效的權杖，請將下列主機新增至 HTTP Proxy 例外狀況：
- 169.254.*或169.254.0.0/16
- *.google.internal
當 Cloud 用戶端程式庫使用中繼資料伺服器擷取應用程式預設憑證，以驗證 REST 或 gRPC 叫用時，通常會發生 401 錯誤。如果您未定義 HTTP Proxy 例外狀況，系統會產生以下行為：
- 如果不同的 Google Cloud 工作負載代管 Cloud Run 服務或工作和 HTTP Proxy，即使 Cloud 用戶端程式庫擷取憑證，指派給 HTTP Proxy 工作負載的服務帳戶也會產生權杖。權杖可能沒有執行預期 Google Cloud API 作業所需的權限。這是因為服務帳戶會從 HTTP Proxy 工作負載的中繼資料伺服器檢索符記，而不是 Cloud Run 服務或工作。
- 如果 HTTP Proxy 未在 Google Cloud中代管，且您使用 Proxy 轉送中繼資料伺服器要求，則權杖要求會失敗，且 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 設定，並公開服務。
如要讓只有擁有特定身分的人才能叫用服務，請使用適當的授權憑證叫用服務：
- 如果開發人員或最終使用者叫用您的服務，請授予 run.routes.invoke 權限。您可以透過 Cloud Run 管理員 (roles/run.admin) 和 Cloud Run 調用者 (roles/run.invoker) 角色提供這項權限。
- 如果服務帳戶叫用您的服務，請確認服務帳戶是 Cloud Run 服務的成員，並授予 Cloud Run 叫用者 (roles/run.invoker) 角色。
- 缺少授權權杖的呼叫可能會導致 403 錯誤。如果使用有效的驗證權杖進行呼叫仍導致 403 錯誤，請將 run.routes.invoke 權限授予產生權杖的 IAM 成員。

如果您遇到 403 錯誤，但找不到記錄項目 resource.type = "cloud_run_revision"，可能是因為 VPC Service Controls 封鎖了輸入設定已設為 All 的 Cloud Run 服務。如要進一步瞭解如何排解 VPC Service Controls 拒絕問題，請參閱「404 錯誤」。

透過網路瀏覽器存取服務時發生錯誤

透過網路瀏覽器存取 Cloud Run 服務時，會發生下列問題：

403 Forbidden
Your client does not have permission to get URL from this server.

當您透過網路瀏覽器叫用 Cloud Run 服務時，瀏覽器會向服務傳送 GET 要求。不過，要求中不含呼叫使用者的授權權杖。如要解決這個問題，請按照下列步驟操作：

搭配使用 Identity-Aware Proxy (IAP) 和 Cloud Run。透過 IAP，您可以為透過 HTTPS 存取的應用程式建立中央授權層。透過 IAP，您可以使用應用程式層級存取權控管模型，而非網路層級防火牆。如要進一步瞭解如何使用 IAP 設定 Cloud Run，請參閱「為 Cloud Run 啟用 Identity-Aware Proxy」。
暫時性的解決方法是，使用 Google Cloud CLI 中的 Cloud Run proxy，透過網路瀏覽器存取服務。如要在本機設定服務 Proxy，請執行下列指令：
```
gcloud run services proxy SERVICE --project PROJECT-ID
```
Cloud 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 Proxy 來路由 Cloud Run 服務或工作外流流量，且 Proxy 強制執行連線的最大時間長度，Proxy 可能會悄悄捨棄長時間執行的 TCP 連線，例如使用連線資源池建立的連線。這會導致 HTTP 用戶端在重複使用已關閉的連線時失敗。如果您想透過 HTTP Proxy 將流量傳送至外部，就必須實作連線驗證、重試和指數輪詢。針對連線集區，設定連線年齡、閒置連線和連線閒置逾時的上限值。

連線逾時

當應用程式嘗試建立與遠端主機的新 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 網路對等互連或混合雲端連線轉送出站流量時，這一點非常重要，因為封包會在抵達遠端主機前穿越多個網路。
如果您使用 HTTP Proxy 將 Cloud Run 服務或工作中的所有傳出流量轉送，則遠端主機必須可透過 Proxy 存取。

根據 Proxy 的資源使用率，透過 HTTP Proxy 轉送的流量可能會延遲。如果您使用 Proxy 轉送 HTTP 出站流量，請實作重試、指數輪詢或斷路器。

設定 HTTP Proxy 例外狀況

使用 HTTP Proxy 轉送 Cloud Run 服務或工作外連流量時，請為 Cloud API 和其他未經 Proxy 的主機和子網路新增例外狀況，以防範延遲、連線逾時、連線重設和驗證錯誤。

不經由 Proxy 的主機和子網路至少必須包含下列項目：

127.0.0.1
169.254.*或169.254.0.0/16
localhost
*.google.internal
*.googleapis.com

視需要，不經由 Proxy 的主機可能包括：

*.appspot.com
*.run.app
*.cloudfunctions.net
*.gateway.dev
*.googleusercontent.com
*.pkg.dev
*.gcr.io

如要為外送網路設定 HTTP Proxy 例外狀況，請設定下列項目：

環境變數：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 錯誤代碼。舉例來說，如果您的服務會透過無伺服器虛擬私人雲端存取連接器轉送流量，請按照下列步驟操作，確保連接器不會超過傳輸量門檻：
1. 在 Google Cloud 主控台中開啟無伺服器虛擬私有雲存取：
  
  前往「Serverless VPC Access」(無伺服器虛擬私人雲端存取) 頁面
2. 請檢查吞吐量圖表直方圖中的任何紅色長條。如果有紅色長條，請考慮增加連接器使用的最大執行個體數量或執行個體類型。或者，您也可以壓縮透過無伺服器虛擬私有雲存取連接器傳送的流量。
如果容器執行個體每秒收到超過 800 個要求，可用的 TCP 通訊端可能會用盡。如要解決這個問題，請為服務啟用 HTTP/2，並對服務進行必要變更，以支援 HTTP/2。

閘道逾時錯誤

如果服務未在指定時間內傳回回應，且要求結束，就會發生下列錯誤：

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

如要進一步瞭解這項錯誤，請參閱容器執行階段合約。

如要排解這個問題，請按照下列步驟操作：

如果您的服務正在處理要求而耗用時間過長，請增加要求的逾時時間。
使用記錄和追蹤工具，瞭解應用程式在超過所設定要求逾時前，花費時間在哪些地方。
由於基礎架構更新，傳出連線會不時重設。如果應用程式重複使用長效連線，建議您將應用程式設為重新建立連線，以免重複使用已中斷的連線。

視應用程式邏輯或錯誤處理方式而定，504 錯誤可能表示應用程式嘗試重複使用已中斷的連線，且要求會在設定的逾時時間前阻斷。使用Liveness Probe 終止會持續傳回錯誤的執行個體。
應用程式程式碼中發生的記憶體不足錯誤 (例如 java.lang.OutOfMemoryError) 不一定會終止容器執行個體。如果記憶體用量未超過容器記憶體限制，Cloud Run 就不會終止執行個體。視應用程式處理應用程式層級記憶體不足錯誤的方式而定，要求可能會在超過所設定的要求逾時時間之前就傳送。

如要終止容器執行個體，請按照下列步驟操作：
- 將應用程式層級記憶體限制設為大於容器記憶體限制。
- 使用 liveness 探測功能，協助終止傳回持續性錯誤的執行個體。

自訂網域在佈建憑證時卡住

對應自訂網域時發生下列其中一項錯誤：

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 Admin Toolbox 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 容器。

如要解決這個問題，請使用 Websockets 或 HTTP/2.0，這兩者都會傳播用戶端中斷連線的訊息。

網路檔案系統問題

進一步瞭解如何使用 NBD、9P、CIFS/Samba 和 Ceph 網路檔案系統。

排解 Cloud Run 問題 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

部署錯誤

容器無法啟動

容器匯入錯誤

不支援這項功能

找不到使用者 root

已刪除預設的 Compute Engine 服務帳戶

Cloud Build 服務帳戶相關問題

Cloud Run 服務代理人缺少讀取圖片的權限

缺少來源部署的權限

使用者權限不足，無法完成來源部署作業

從其他專案部署 Cloud Run 服務時發生錯誤 Google Cloud

放送錯誤

HTTP 404：找不到

沒有可用的容器執行個體

Cloud Run 無法管理流量頻率

未實作作業

找不到預設憑證

容器執行個體超出記憶體限制

由於並行處理設定過高，無法處理部分要求

與待處理佇列要求中止相關的 Cloud Logging 錯誤

Google 遮蓋的 ID 權杖簽名

記錄檔中的 OpenBLAS 警告

取得要繫結的機器 IP 位址時，Spark 會失敗

無法使用 NFS 存取檔案

無法使用 Cloud Storage FUSE 存取檔案

CPU 使用率偏低時的延遲時間偏高

可能的原因：

解決方法：

連線和安全性錯誤

未正確驗證用戶端

用戶端未獲准叫用服務

透過網路瀏覽器存取服務時發生錯誤

連線已遭對等方重設

連線逾時

設定 HTTP Proxy 例外狀況

回應格式錯誤或容器執行個體連線問題

閘道逾時錯誤

自訂網域在佈建憑證時卡住

用戶端中斷連線不會傳播至 Cloud Run

網路檔案系統問題

排解 Cloud Run 問題

找不到使用者 `root`