Apigee 已知問題

在 overrides.yaml 中設定 httpProxy (在 apigee-connect-agent Pod 上設定 HTTPS_PROXY) 時，錯誤 513032450 中導入的自訂 TCP 保持運作撥號器會略過 gRPC 內建的 HTTP CONNECT Proxy 處理，並嘗試直接連線至 apigeeconnect.googleapis.com:443。在傳出流量僅限轉送 Proxy 的叢集中，連線會逾時，且管理層作業會失敗，並顯示 no connections available from the Apigee connect agent(s)。

解決方法：升級至 Apigee Hybrid 1.16.13 或 1.17.3 (請勿使用 1.16.12 或 1.17.2)。

安裝或升級至受影響的版本後，kubectl get daemonset apigee-logger -n apigee 會回報所需的 0 數量，且不會建立任何記錄器 Pod。

apigee-telemetry 圖表一律會提供 apigee.cloud.google.com/apigee-logger-enabled: "true" 的預設 logger.nodeSelector，因此您必須為應執行記錄器的節點加上標籤。受影響版本之前的版本會忽略元件層級節點選取器，因此即使節點未加上標籤，記錄器仍會排定在 Apigee 節點集區中。受影響的版本會正確套用元件層級節點選取器，因此預設值現在會生效，且 DaemonSet 不會比對任何節點。

只有設定 logger.enabled: true 的部署作業會受到影響。

解決方法：選擇下列其中一項，然後升級 apigee-telemetry 圖表。

如要在每個節點上執行記錄器 (與舊版行為相同)，請清除 overrides.yaml 檔案中的預設節點選取器：

logger:
  enabled: true
  nodeSelector:
    key: ""
    value: ""

如要將記錄器限制在特定一組節點，請保留預設節點選取器，並為每個節點加上標籤：

kubectl label nodes NODE_NAME apigee.cloud.google.com/apigee-logger-enabled=true

ExtractVariables 政策會使用 JSONPath，並透過最後勝出語意解析重複的 JSON 鍵。部分後端 (尤其是接受 proto3 JSON 的 Google Cloud API) 則會合併重複的鍵 (例如串連重複的陣列欄位)。如果 Apigee Proxy 依賴 ExtractVariables + JSONPath + RaiseFault 檢查及封鎖特殊權限要求主體，攻擊者就能將惡意內容隱藏在重複的金鑰中，讓 Apigee 政策無法偵測，但後端仍會處理。

解決方法：請勿單獨使用 ExtractVariables 搭配 JSONPath，做為接受 proto3 JSON 的後端安全性邊界。在 ExtractVariables 之前，將 JSONThreatProtection 政策新增至要求流程，並設定 <ObjectEntryCount> 和其他限制，以符合 API 合約。如要強化防護，請使用 JavaScript 政策，透過 JSON.parse() 剖析要求主體，並在執行擷取作業前拒絕含有重複索引鍵的酬載。

在 Apigee UI 中查看偵錯工作階段時，交易對應和追蹤記錄詳細資料可能會反覆出現及消失 (閃爍)，或需要很長時間才能顯示。如果偵錯工作階段包含大量事件，且在效能較低的機器上執行，這種行為會特別明顯，而且可能難以檢查 API 要求的流程。

解決方法：在偵錯追蹤記錄檢視畫面的「View options」窗格中，清除所有核取方塊，減少轉譯元素的數量。您也可以嘗試在其他瀏覽器中查看偵錯工作階段。

apigee-connect-agent Pod 無法偵測到停滯的連線。根本原因仍在調查中，但可能與測試叢集使用的 Cloud NAT 有關。

解決方法：使用多個 apigee-connect-agent Pod。第二個 Pod 會恢復健康狀態，第一個 Pod 則會在 2 小時後重設連線，並在之後恢復健康狀態。

當 apigee-pull-push.sh (或任何手動 docker pull) 要求 1.16.3 標記的受影響映像檔時，登錄檔會傳回 image not known 錯誤，指令碼也會中止。透過 Apigee hybrid Helm 圖表執行的升級作業不受影響，因為圖表會直接參照正確的映像檔摘要。

解決方法：針對每個受影響的映像檔，提取 1.16.2 標記而非 1.16.3，或直接升級至 1.16.4，這樣就會重新發布所有具有相符標記的映像檔。

解決方法：請勿在 Apigee Hybrid 1.16.2 上為 apigee-redis 設定外部 Secret 儲存庫 (ESS) 整合。在修正程式推出前，請使用預設密鑰設定。

混合式客戶可能會在控制器記錄中看到重複出現的「object has been modified; please apply your changes to the latest version and try again.」訊息。這些訊息是 Apigee 和 Apigee Hybrid 內建安全機制的無害副作用，不代表 Apigee 或 Apigee Hybrid 環境有任何風險。為確保完全可靠，系統會每分鐘多次檢查並重新驗證內部設定，確保設定與所需配置完全一致。這些錯誤表示兩個子控制器嘗試同時更新內部「規格」；第一個更新成功，第二個更新則會產生訊息，並在稍後執行全新更新。由於這些只是內部管理更新，不會改變 API 實際處理流量的方式，因此服務應保持穩定，完全不受影響。

我們正在轉換 Apigee Drupal 入口網站 Marketplace 解決方案，改用 Infrastructure Manager，而非 Cloud Deployment Manager。在這段轉換期間，部分部署和管理功能可能無法使用。

影響：

• 新部署作業：2026 年 4 月 1 日起，如果嘗試使用 Cloud Marketplace 的「部署」按鈕部署新的 Apigee Drupal 入口網站執行個體，可能會失敗。
• 現有部署作業：基礎資源 (例如 VM 和 Cloud SQL 資料庫) 不受影響，會繼續正常運作。不過，如果使用 Deployment Manager 相關功能，透過 Cloud Marketplace UI 或 gcloud deployment-manager 工具管理部署作業，可能會失敗。

解決方法：直接在個別 Google Cloud 資源 (Compute Engine、Cloud SQL 等) 執行任何設定變更或管理工作而非透過 Cloud Marketplace UI。

MCP 基礎架構部署作業在下列區域可能受到容量限制：

• asia-east2
• asia-northeast3
• asia-southeast2
• australia-southeast1
• europe-central2
• europe-west12
• europe-west9
• me-central2
• us-central2

如果看到與負載平衡器佈建失敗相關的錯誤，或佈建狀態一直未變更為「已部署」，可能是因為所選區域的暫時性基礎架構容量限制。請嘗試將 Proxy 部署至其他區域的環境。

使用 httpProxy.username 和 httpProxy.password 設定經過驗證的外送 Proxy 時，Apigee Hybrid Helm 圖表會產生格式錯誤的 http_proxy 和 https_proxy 字串。範本會錯誤地在網址中間插入雙引號，導致護欄驗證 Pod 等元件當機，並出現 net/url: invalid userinfo 錯誤。

解決方法：手動編輯 Helm 範本檔案，從 Proxy 網址建構的使用者名稱和密碼欄位中移除 quote 函式。舉例來說，在 apigee-operator/templates/apigee-operators-guardrails.yaml 中，修改 Proxy 環境變數定義，確保憑證不會在網址字串中個別加上引號。

在 Apigee Hybrid 環境中，如果多個組織共用單一 Kubernetes 命名空間，Proxy 鏈結可能會間歇性失敗，並顯示 HTTP 404 route_not_found 錯誤。這是因為不同組織的內部鏈結閘道使用相同的 ingress_name 選取器，導致 Envoy 載入路由規則時不一致。

解決方法：在 overrides.yaml 檔案中，為每個組織的鏈結閘道指派不重複的名稱，確保選取器隔離：

apigeeChainingGateway:
  name: internal-chaining-UNIQUE_SUFFIX

此外，請務必更新虛擬主機選取器和任何專屬 Kubernetes 服務，參照這個不重複的名稱。

在已啟用聯合 Workload Identity (WIF) 的非 GKE 平台上，安裝或升級 Apigee Hybrid 1.16.0 中的 apigee-operator 圖表時，系統不會建立 Kubernetes ServiceAccount apigee-operator-guardrails-sa。

解決方法：手動修補 apigee-operator Helm 圖表範本：

1. 編輯 apigee-operator Helm 圖表範本檔案 apigee-operator/templates/apigee-operator-guardrails-sa.yaml。

   更新初始 if 條件，加入 federatedWorkloadIdentity 檢查：

   {{ - if or (.Values.serviceAccountSecretProviderClass) (.Values.gcp.workloadIdentity.enabled) (.Values.gcp.federatedWorkloadIdentity.enabled) } }

2. 編輯 apigee-operator Helm 圖表範本檔案 apigee-operator/templates/apigee-operator-guardrails.yaml (注意：這是 apigee-operator-guardrails.yaml 範本檔案，而非 apigee-operator-guardrails-sa 檔案)。

   在第 17 行中，緊接在 spec: 後方更新初始 if 條件，加入 federatedWorkloadIdentity 檢查：

   {{ - if or (.Values.serviceAccountSecretProviderClass) (.Values.gcp.workloadIdentity.enabled) (.Values.gcp.federatedWorkloadIdentity.enabled) } }

3. 將變更套用至 apigee-operator 圖表。

升級至 Apigee Hybrid 1.16.0 後，如果環境使用 Workload Identity Federation (WIF) 搭配 HTTP 轉送 Proxy，可能會因為 MART 中的憑證轉換迴歸，而無法載入管理實體 (API 產品、應用程式、開發人員)。

解決方法：在 overrides.yaml 檔案中更新運算子和 MART 元件的 image.url 和 image.tag 屬性，套用 1.16.0-hotfix.1 更新：

ao:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-operators"
    tag: "1.16.0-hotfix.1"
mart:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-mart-server"
    tag: "1.16.0-hotfix.1"

1.16.0 版有一個已知問題，就是混合式叢集可能無法回報 Proxy 的部署狀態。這是因為 apigee-manager-role 角色缺少權限。

解決方法：將權限新增至 apigee-operator Helm 圖表範本：

1. 編輯 apigee-operator Helm 圖表範本檔案 apigee-operator/templates/apigee-operators.yaml。
2. 在第 584 行的 - update 動詞後方，將 - watch 動詞新增至 deployments 資源。
3. 更新 apigee-operator Helm 版本。

混合版本資訊頁面不會顯示 1.16.0-hotfix.1 更新資訊。如要瞭解更新詳情，請參閱 Apigee hybrid 1.16.0-hotfix.1 版版本資訊。

Apigee Hybrid 1.16 不受這個問題影響。

解決方法：如要搭配使用 Kubernetes Gateway API 與 Apigee Hybrid 1.14 或 1.15 版，請安裝 Gateway API 1.3.x 版。例如：

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml

另請參閱：

• Kubernetes Gateway API 1.3 版
• Gateway API 1.3.0 版：要求鏡像、CORS、閘道合併和重試預算方面的進展

API 要求有時不會採用 io.timeout.millis 的更新值。如果 TargetEndpoint 的 <LoadBalancer> 下方使用多個伺服器，就會發生這種情況。

解決方法：部署 API Proxy 後，請逐一重新啟動 apigee-runtime Pod，確保變更正確套用。

在 Apigee 1-17-0-apigee-1 版本中，Netty 升級至 4.1.129.Final 後，發生迴歸問題。這可能會導致 API Proxy 呼叫失敗，並顯示 400 狀態碼和 The URI contain illegal characters 錯誤訊息。這個問題會透過外部追蹤，詳情請參閱 netty/netty#16020。

Apigee Hybrid 1.16 會在這些元件的 Pod 範本中新增磁碟區掛接。首次將運算子從 1.15.x 升級至 1.16.x 時，執行階段、同步器、MART、Envoy 轉接器和遷移 Pod 會在每個環境中重新啟動一次。無論是否啟用憑證輪替，系統都會重新啟動。

每次重新啟動都是滾動式更新，因此每個工作負載都會短暫執行額外的 (激增) Pod。在具有多個環境的叢集中，這些激增 Pod 會同時啟動。

Mint 工作排程器不會重新啟動。並在下次排定的執行時間套用變更。

只有在從 1.15.x 升級至 1.16.x 時，才會重新啟動一次。後續升級 (例如從 1.16.x 升級至 1.17.x) 則不會造成這種情況。後續的 Apigee hybrid 版本需要掛接磁碟區，因此不打算修正。

解決方法：升級運算子前，請確認叢集有足夠容量，可同時為所有環境提供激增 Pod，或在流量較低時升級。

請參閱：

• 將 Apigee Hybrid 升級至 1.16 版：安裝 Apigee Hybrid 1.16 執行階段

新版 cert-manager (v1.18 以上版本) 現在會自動輪替私密金鑰。如果輪替 apigee-ca 憑證的這個金鑰，會導致服務中斷。

解決方法：如要避免這個問題，請選擇下列其中一個選項：

• 請勿將 cert-manager 升級至 1.17.x 以上版本。
• 編輯 cert-manager 命名空間中的 apigee-ca 憑證，並將 spec.privateKey.rotationPolicy 設為 Never。請按照下列程序編輯 apigee-ca 憑證並升級 cert-manager：
  1. 檢查 apigee-ca 憑證的內容，確認是否已設定 rotationPolicy：

     kubectl get certificate apigee-ca -n cert-manager -o yaml
     

     在輸出內容中，找出 spec.privateKey 下方的值：

     ...
     spec:
       commonName: apigee-hybrid
       duration: 87600h
       isCA: true
       issuerRef:
         group: cert-manager.io
         kind: ClusterIssuer
         name: apigee-root-certificate-issuer
       privateKey:
         algorithm: ECDSA
         # Note: rotationPolicy would appear here if it is set.
         size: 256
       secretName: apigee-ca
     ...

  2. 如果未設定 rotationPolicy，或設為 Always，請編輯 apigee-ca 憑證，將 rotationPolicy 的值設為 Never：
     1. 先執行模擬測試：

        kubectl patch Certificate \
          --dry-run=server \
          -n cert-manager \
          --type=json \
          -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
          -o=yaml \
          apigee-ca
        

     2. 修補憑證：

        kubectl patch Certificate \
          -n cert-manager \
          --type=json \
          -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
          -o=yaml \
          apigee-ca
        

  3. 確認 rotationPolicy 的值已設為 Never：

     kubectl get certificate apigee-ca -n cert-manager -o yaml
     

     輸出內容大致如下：

     ...
     spec:
       commonName: apigee-hybrid
       duration: 87600h
       isCA: true
       issuerRef:
         group: cert-manager.io
         kind: ClusterIssuer
         name: apigee-root-certificate-issuer
       privateKey:
         algorithm: ECDSA
         rotationPolicy: Never
         size: 256
       secretName: apigee-ca
     ...

  4. 升級 cert-manager。下列指令會下載並安裝 cert-manager v0.14.2：

     kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v0.14.2/cert-manager.yaml

請參閱：

• 支援的平台和版本：cert-manager
• 將 Apigee Hybrid 升級至 1.16 版：升級 cert-manager
• cert-manager 1.18 版：Certificate.Spec.PrivateKey.rotationPolicy 的預設值現為 Always

如果要求中有多個授權標頭，Apigee 輸入閘道不會將這些標頭串連成單一標頭，這會導致訊息處理器傳回 500 錯誤，並顯示 "Duplicate Header "authorization"" 訊息。

解決方法：如果要求中有多個授權標頭，請將這些標頭串連成單一標頭。例如：

curl -s https://my-hostname.net/mocktarget/echo \
          -H 'authorization: a, b'

Apigee UI 目前不提供使用 Google-owned and Google-managed encryption key佈建 Apigee 組織的選項。

佈建訂閱組織時，Apigee UI 不提供選取 Google-owned and Google-managed encryption key 的選項。

解決方法：使用 Apigee API 建立 Google-owned and Google-managed encryption key訂閱制組織。

如 Apigee API 說明文件所述，建立 Apigee 組織時，您可以不提供 runtimeDatabaseEncryptionKeyName、apiConsumerDataEncryptionKeyName 和 controlPlaneEncryptionKeyName 欄位的值，使用 Google-owned and Google-managed encryption key 建立組織。

Apigee Model Armor 政策 (包括 SanitizeUserPrompt 和 SanitizeModelResponse) 目前在處理 WebSocket 連線的 API Proxy 中使用時，無法正常運作。如要進一步瞭解 WebSocket 設定，請參閱「 搭配使用 WebSockets 與 Apigee」。

升級至 1-16-0-apigee-3 後，部分 Apigee 組織可能會遇到 HTTP 500 錯誤，這是由 Java 呼叫政策中的 java.lang.NoClassDefFoundError 引起。錯誤訊息大致如下：

{"fault":{"faultstring":"Failed to execute JavaCallout. org/apache/commons/lang/StringUtils","detail":{"errorcode":"steps.javacallout.ExecutionError"}}}

如果 Java 呼叫政策不正確地依賴 Apigee 內部使用的程式庫，而非提供自己的依附元件，就會發生這項錯誤。

敬請採取行動：為避免這個問題，開發人員必須確保所有 Java 呼叫都獨立運作，並使用專屬程式庫，避免依賴 Apigee 的內部類別路徑。

在採用 Apache Commons JAR 程式庫的 API Proxy 中，匯入 Apache Commons JAR 檔案，做為 Proxy 的資源。詳情請參閱 Java 資源指南。

即使未啟用營利功能，如果未設定 mintTaskScheduler.serviceAccountPath 屬性，apigee-org 圖表升級作業仍可能失敗：

Error: UPGRADE FAILED: execution error at (apigee-org/templates/mint-task-scheduler-gsa-secret.yaml:12:63): mintTaskScheduler.serviceAccountPath is required!

解決方法：移除 apigee-org/templates/mint-task-scheduler-gsa-secret.yaml 和 apitee-org/templates/mint-task-scheduler-sa.yaml 檔案。

您也可以選擇將檔案移至 Helm 圖表目錄以外的其他位置。或者，如果您日後想啟用營利功能，可以按照「步驟 2：下載 Apigee Helm Chart」中的操作說明，再次下載這些檔案。

例如，從 helm-charts/ 目錄：

1. ls apigee-org/templates/

   輸出內容：

   apigee-org-guardrails.yaml              mart-sa.yaml
   apigee-proxy-chaining-certificate.yaml  mint-task-scheduler-gsa-secret.yaml
   apigee-proxy-chaining-route.yaml        mint-task-scheduler-sa.yaml
   ax-hash-salt-secret.yaml                NOTES.txt
   connect-agent-gsa-secret.yaml           organization.yaml
   connect-agent-sa.yaml                   udca-gsa-secret.yaml
   data-encryption-secret.yaml             udca-sa.yaml
   encryption-keys-secret.yaml             watcher-gsa-secret.yaml
   _helpers.tpl                            watcher-sa.yaml
   mart-gsa-secret.yaml
   

2. (選填：)

   cp apigee-org/templates/mint-task-scheduler-gsa-secret.yaml /tmp/
   cp apigee-org/templates/mint-task-scheduler-sa.yaml /tmp/

3. rm apigee-org/templates/mint-task-scheduler-gsa-secret.yaml

4. rm apigee-org/templates/mint-task-scheduler-sa.yaml

5. ls apigee-org/templates/

   輸出內容：

   apigee-org-guardrails.yaml              mart-gsa-secret.yaml
   apigee-proxy-chaining-certificate.yaml  mart-sa.yaml
   apigee-proxy-chaining-route.yaml        NOTES.txt
   ax-hash-salt-secret.yaml                organization.yaml
   connect-agent-gsa-secret.yaml           udca-gsa-secret.yaml
   connect-agent-sa.yaml                   udca-sa.yaml
   data-encryption-secret.yaml             watcher-gsa-secret.yaml
   encryption-keys-secret.yaml             watcher-sa.yaml
   _helpers.tpl
   

apigee-pull-push.sh 指令碼可能會傳回 No such image 錯誤訊息，例如：

Error response from daemon: No such image: gcr.io/apigee-release/hybrid/apigee-stackdriver-logging-agent:latest

解決方法：編輯 HELM_CHARTS_DIR/apigee-operator/etc/tools/apigee-pull-push.sh 指令碼，將 docker_tag() 函式中的第 114 行從：

  docker tag "${source}/$i" "${dest}/$i:${TAG}"

To:

  docker tag "${source}/$i:${TAG}" "${dest}/$i:${TAG}"

如果在 overrides.yaml 檔案中指定 metrics.serviceAccountRef 或 metrics.serviceAccountSecretProviderClass，遙測角色會指定錯誤的服務帳戶。

解決方法：在 apigee-operator/ 圖表中修補 _helper.tpl，然後重新套用。

1. 編輯 apigee-operator/templates/_helpers.tpl，並移除下列粗體行：

   {{- define "metricsSA" -}}
     {{- $metricsName := "apigee-metrics" }}
     {{- $telemetryName := "apigee-telemetry" -}}
     {{- $generatedName := include "orgScopeEncodedName" (dict "name" .Values.org) -}}
     {{- if .Values.gcp.workloadIdentity.enabled -}}
     {{- printf "%s-sa" $metricsName -}}
     {{- else if .Values.serviceAccountSecretProviderClass -}}  <-- DELETE
     {{- .Values.serviceAccountSecretProviderClass -}}          <-- DELETE
     {{- else if .Values.metrics.serviceAccountRef -}}          <-- DELETE
     {{- .Values.metrics.serviceAccountRef -}}                  <-- DELETE
     {{- else if .Values.multiOrgCluster -}}
     {{- printf "%s-%s" $metricsName $generatedName -}}
     {{- else -}}
     {{- printf "%s-%s" $metricsName $telemetryName -}}
     {{- end -}}
   {{- end -}}

   完成後的區段應如下所示：

   {{- define "metricsSA" -}}
     {{- $metricsName := "apigee-metrics" }}
     {{- $telemetryName := "apigee-telemetry" -}}
     {{- $generatedName := include "orgScopeEncodedName" (dict "name" .Values.org) -}}
     {{- if .Values.gcp.workloadIdentity.enabled -}}
     {{- printf "%s-sa" $metricsName -}}
     {{- else if .Values.multiOrgCluster -}}
     {{- printf "%s-%s" $metricsName $generatedName -}}
     {{- else -}}
     {{- printf "%s-%s" $metricsName $telemetryName -}}
     {{- end -}}
   {{- end -}}

2. 重新套用apigee-operator圖表。

   helm upgrade operator apigee-operator/ \
       --namespace APIGEE_NAMESPACE \
       --atomic \
       -f overrides.yaml

如需解決方法，請按照已知問題 416634326 中的步驟操作。

在 Apigee Proxy 基本路徑中使用萬用字元 (*) 可能會與其他明確的基本路徑衝突，導致 404 錯誤。舉例來說，如果為部署在相同環境中的兩個 Proxy 使用下列基本路徑，呼叫 Proxy-2 時可能會導致 404 錯誤：

Proxy-1: /a/v1/b
Proxy-2: /a/*/c

在這種情況下，對明確基本路徑的呼叫會成功解析，但如果萬用字元路徑評估為 /a/v1/c，對 Proxy-2 的呼叫可能會傳回 404。

已修正：這個問題已在 Apigee 和 1.14.3 以上版本的混合式環境中修正。不過，修正程式預設為停用。如要在基本路徑中啟用萬用字元，請按照下列步驟操作：

• 如果客戶有 Apigee 組織，請視需要聯絡 Apigee 支援團隊，啟用修正程式。
• 如果客戶使用 Apigee hybrid 組織，請視需要按照下列程序啟用修正程式。

程序：如要在 Apigee hybrid 的 Apigee Proxy 基本路徑中啟用萬用字元 (*)，請按照下列步驟操作：

1. 升級至 Hybrid 1.14.3 以上版本前，請在 overrides.yaml 檔案中新增下列段落：

   runtime:
     cwcAppend:
       conf_message-processor-communication_classificationV2.enabled: "true"
   

2. 將變更套用至 apigee-env 圖表。針對安裝作業中的每個環境重複執行變更。

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE
   

   • ENV_RELEASE_NAME 是用來追蹤 apigee-env 圖表安裝和升級作業的名稱。這個名稱不得與安裝作業中的其他 Helm 版本名稱重複。通常與 ENV_NAME 相同。不過，如果環境與環境群組同名，則必須為環境和環境群組使用不同的版本名稱，例如 dev-env-release 和 dev-envgroup-release。如要進一步瞭解 Helm 中的版本，請參閱 Helm 說明文件中的「Three big concepts」(三大概念)。
   • ENV_NAME 是要升級的環境名稱。
   • OVERRIDES_FILE 是覆寫檔案。
3. 升級至 Hybrid 1.14.3 以上版本。

在 SecurityPolicy 中使用 LogTimer 可能會導致記憶體流失。

在某些情況下，Apigee hybrid 的記錄器執行緒可能會耗盡所有可用記憶體。舉例來說，如果記錄項目經常記錄與 Javacallout 相關的權限錯誤，可能會導致 OOM。

Apigee 擴充功能處理器不支援超過 100 KB 的資料處理，做為要求和回應主體事件的一部分。

更新 KeyStore 或 TrustStore 時，如果未建立新的 KeyStore 或 TrustStore，執行階段更新可能會失敗，並導致下列間歇性錯誤：

  {"fault":{"faultstring":"SSL Handshake failed sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target","detail":{"errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"}}}

這項錯誤會間歇性發生，因為金鑰儲存庫或信任儲存庫更新可能會在某個執行階段 Pod 失敗，但在其他 Pod 成功。如要避免這個問題，請建立新的 KeyStore 或信任儲存庫，藉此更新 KeyStore 或信任儲存庫。按照「 憑證到期時」一節所述，將參照重新指向新的 KeyStore 或 TrustStore。

自 Apigee hybrid 1.14.0 版起，系統不會再自動新增 Zipkin 追蹤標頭 (x-b3-*)。

不適用

如果只指定 httpProxy，則必須確保 *.googleapis.com 已加入 Apigee 執行階段 Pod 的許可清單，才能連線至這些服務。

請參閱「設定 API Proxy 的轉送 Proxy」。

Apigee hybrid 叢集中存在 istio.io 自訂資源定義 (CRD)，可能會導致 apigee-ingressgateway-manager Pod 故障。

將 Apigee Hybrid 從舊版升級至 1.14.2 以上版本時，如果存在現有的 istio.io CRD，可能會導致 apigee-ingressgateway-manager Pod 的 discovery 容器中出現就緒探測失敗。

解決方法：Apigee Hybrid 1.14.2 以上版本不需要 istio.io CRD。修正這個問題的方法有兩種：

• 如果您在叢集中只使用 Istio 執行 Apigee，請刪除 istio.io CRD。
• 更新 apigee-ingressgateway-manager clusterrole，新增 istio.io 的權限。

完成上述任一選項後，您必須重新啟動 apigee-ingressgateway-manager Pod。

完成上述選項後，您必須重新啟動 apigee-ingressgateway-manager Pod。

1. 列出要重新安裝或重新建立的 ingress-manager Pod：

   kubectl get deployments -n APIGEE_NAMESPACE

   輸出內容範例：

   NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
   apigee-controller-manager       1/1     1            1           32d
   apigee-ingressgateway-manager   2/2     2            2           32d
   

2. 重新啟動 ingress-manager Pod：

   kubectl rollout restart deployment -n APIGEE_NAMESPACE apigee-ingressgateway-manager

3. 幾分鐘後，監控 apigee-ingressgateway-manager Pod：

   watch -n 10 kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-ingressgateway-manager

   輸出內容範例：

   NAME                                             READY   STATUS    RESTARTS   AGE
   apigee-ingressgateway-manager-12345abcde-678wx   3/3     Running   0          10m
   apigee-ingressgateway-manager-12345abcde-901yz   3/3     Running   0          10m
   

ApigeeTelemetry 可能會卡在 creating 狀態。

這個問題會發生在 OpenShift 安裝作業。

解決方法：修改 apigee-operator 圖表範本，建立正確的叢集角色存取權。

1. 編輯 helm-charts/apigee-operator/templates/apigee-operators.yaml 範本檔案，並找出 -apigee-manager-role- 叢集角色的定義。開頭為：

   kind: ClusterRole
   metadata:
     name: apigee-manager-role-{{ include 'namespace' }}
   rules:
     ...
                 

2. 找出 - apiGroups: apiregistration.k8s.io 區塊，並將 apiservices/finalizers 資源新增至資源清單：

   - apiGroups:
     - apiregistration.k8s.io
     resources:
     - apiservices
     - apiservices/finalizers
     verbs:
     - create
     - delete
     - get
     - patch
     - update
     

3. 找出 - apiGroups: authorization.k8s.io 區塊，並在該區塊結尾後方新增 - apiGroups: apigee.cloud.google.com 區塊，並加入以下文字：

   - apiGroups:
     - apigee.cloud.google.com
     resources:
     - apigeetelemetries/finalizers
     verbs:
     - get
     - patch
     - update
   

   例如：

   - apiGroups:
     - authorization.k8s.io
     resources:
     - subjectaccessreviews
     verbs:
     - create
     - get
     - list
   - apiGroups:
     - apigee.cloud.google.com
     resources:
     - apigeetelemetries/finalizers
     verbs:
     - get
     - patch
     - update
   

4. 將變更套用至 apigee-operator 圖表：

   模擬測試：

   helm upgrade operator apigee-operator/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f OVERRIDES_FILE \
     --dry-run=server
   

   升級圖表：

   helm upgrade operator apigee-operator/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f OVERRIDES_FILE \
   

API 產品的路徑數量上限為 50 個。如果新增其他路徑，系統會顯示錯誤訊息：Operation group limit of 51 exceeded in Operation Config

解決方法：使用萬用字元模式合併資源路徑和作業，如「 設定資源路徑」一節所述。

解決方法：建立多個 API 產品。這項解決方法已通過驗證，適用於在 API 產品中新增大量 API Proxy 的使用者。與 API 產品相關聯的應用程式必須更新，才能納入新產品，但憑證和用戶端要求詳細資料已證實不需要變更。

使用自訂報表和統計資料 API，依費用類型選取採用營利功能的安裝項目時，發生錯誤。

解決方法：在用戶端擷取所有費用類型，然後再篩選。

Istio 輸入 Pod 的資源調度可能會導致 503 錯誤。

Istio 輸入 Pod 的資源調度有時可能會導致 503 錯誤。如果發生 503 錯誤，負載平衡器的記錄會顯示下列訊息：statusDetails: backend_connection_closed_before_data_sent_to_client。

解決方法：手動調度 Istio 輸入 Pod。

ESS 和 非 ESS Cassandra 憑證輪換功能不適用於設有強化 Proxy 限制的組織。

執行階段流量不會受到影響。

使用 GCP 和 HYBRID 雲端服務供應商從多區域設定建立的備份，會包含建立快照時所有 Hybrid 區域的資訊。由於這些區域已不存在，還原工作會與 Cassandra 的目前狀態衝突，並失敗並顯示下列錯誤：Unrecognized strategy option passed to NetworkTopologyStrategy。

使用 JavaCallout 政策時，Nimbus JOSE + JWT 程式庫可能會導致 java.lang.ClassCircularityError。

如果您的組織已啟用 Apigee Hybrid，且 JavaCallout 政策使用 Nimbus JOSE + JWT 程式庫，請勿升級至 Hybrid 1.12.4、Hybrid 1.13.3、Hybrid 1.14.1。

ESS 和 非 ESS 多區域 Cassandra 憑證輪換作業在第一個區域以外的所有區域都會失敗。

執行階段流量不會受到影響。

請按照提供的解決方法解決這個問題。

套用 Cassandra 覆寫變更 (例如重新啟用備份) 後，Cassandra Pod 會重新啟動，進而觸發這個問題。處於 CrashLoopBackoff 狀態的 Cassandra Pod 記錄會顯示下列錯誤：Cannot change the number of tokens from 512 to 256。

請按照提供的解決方法解決這個問題。

在極少數情況下，Apigee 備份工作不會清除使用 HYBRID 或 GCP 雲端服務供應商進行備份時建立的 Cassandra 中繼快照。只有在基礎問題導致備份程序無法成功連線至遠端伺服器或 Cloud Storage 時，才會發生這種情況。如果連線問題持續發生，這些剩餘的 Cassandra 快照可能會隨著時間累積，並占用 Cassandra 磁碟的儲存空間。 如果受到影響，請修正基礎連線問題，然後按照 Cassandra 疑難排解指南中的步驟，手動清除 Cassandra 快照。

如果 KeyValueMapOperations 政策與 apiproxy 範圍搭配使用，且政策的 <Put> 作業是透過流程掛鉤在共用流程中呼叫，則 KVM 項目會以共用流程名稱建立。應在 API Proxy 名稱下建立。

384937220

如果有多個虛擬主機，Helm 版本建立作業可能會因 ApigeeRoute 名稱衝突而失敗。解決方法是在建立每個虛擬主機時，執行下列指令：

kubectl annotate ar apigee-ingressgateway-internal-chaining-PROJECT_ID_SUFFIX -n APIGEE_NAMESPACE meta.helm.sh/release-name=NEW_ENV_GROUP_NAME --overwrite
kubectl annotate cert apigee-ingressgateway-internal-chaining-PROJECT_ID_SUFFIX -n APIGEE_NAMESPACE meta.helm.sh/release-name=NEW_ENV_GROUP_NAME --overwrite

其中：

• PROJECT_ID_SUFFIX 是 Kubernetes 專案內部鏈結的專屬後置字串。您可以使用下列指令找出這個尾碼：

  kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining

  輸出內容應如下所示：

  kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining
  apigee-ingressgateway-internal-chaining-my-project--1234567    ClusterIP  34.118.226.140  <none>    15021/TCP,443/TCP    5d6h

  在輸出內容範例中，my-project--1234567 是 PROJECT_ID_SUFFIX。

• APIGEE_NAMESPACE 是 Apigee 命名空間。
• NEW_ENV_GROUP_NAME 是額外環境群組的名稱。請為每個虛擬主機更新這個值。

不適用

如果使用者向 UpdateControlPlaneAccess API 提供無效的服務帳戶，作業會進入重試迴圈，導致組織無法叫用 API，直到作業逾時為止。

使用 GCP 雲端服務供應商時，Apigee 備份工作無法上傳至具有資料保留政策的 Cloud Storage bucket。備份檔案可能會留在 Cloud Storage bucket 中，檔案大小為 0 個位元組。

解決方法：停用 Cloud Storage bucket 的資料保留政策。

341099433

apigee-logger 會使用 Google IAM 服務帳戶，將記錄檔傳送至 Cloud Logging。這是因為 FluentBit 不支援 Workload Identity Federation，導致 apigee-logger 無法使用這項功能。

不適用

不適用

270574696

268104619

364872027

在 Apigee 和 Apigee Hybrid 1.13 以上版本中，如果 Apigee JWS 或 JWT 政策使用的金鑰不符合必要的 PEM 格式，可能會導致剖析錯誤。舉例來說，在 "-----END" 行 (封裝後邊界) 前方緊接任何非換行字元 (/n) 都是不允許的，會導致錯誤。

為避免發生這項錯誤，請確認封裝後邊界前方沒有任何字元 (例如尾端空格或斜線)，只有換行符號。

如要進一步瞭解公開或私密金鑰使用的編碼，請參閱 IETF RFC 7468。

310191899

下列端點在每秒查詢次數 (QPS) 較高時，可能會發生逾時：

• organizations.environments.apis.revisions.
  deployments.deploy
• organizations.environments.apis.revisions.
  deployments.undeploy
• organizations.environments.sharedflows.revisions.
  deployments.deploy
• organizations.environments.sharedflows.revisions.
  deployments.undeploy

為降低逾時的可能性，建議您在使用這些端點時，將目標設為 1 QPS，或在嘗試其他部署作業前，先檢查部署作業的狀態。

329304975

Apigee 暫時限制每個環境最多只能有 1000 個基本路徑，以免部署 API Proxy 修訂版本時發生錯誤。

在這項限制下，每個環境最多可部署 1000 個 API Proxy 修訂版本 (每個版本包含一個基準路徑)。 如果 API Proxy 或修訂版本包含多個基本路徑，每個環境的基本路徑總數不得超過 1000 個。

333791378

如需安裝修補程式來解決問題的步驟，請參閱「 疑難排解」。

310384001

289583112

如果 OASValidation 政策指定 <OASResource>，且安全性需求設為全域層級，系統就不會強制執行安全性需求。

解決方法：為確保強制執行，所有安全性需求都必須在 OASValidation 政策的 <OASResource> 元素中傳遞的 OpenAPI 規格中的作業層級設定。

205666368

請參閱「關於在目標端點或目標伺服器中設定 TLS 選項」。

295929616

在 OSE 上安裝或升級至 Apigee Hybrid 1.10.0 至 1.10.2 版時，可能會因記憶體不足而失敗。已在 Apigee Hybrid 1.10.3 版中修正。

292118812

如果防火牆強制所有流量通過轉送 Proxy，apigee-udca 可能會進入當機迴圈輪詢狀態。

292558790

• 如果 JSON 內容與預期模式不符，OASValidation 政策就會失敗。舉例來說，如果標頭預期值採用 <text>@<text> 格式，但填入的文字缺少 @ 符號，政策就會失敗，並顯示 Unable to parse JSON 錯誤。
• 如果 OASValidation 政策指定的 <OASResource> 包含使用 $ref 結構定義的 path 參數，政策會失敗並顯示 Unable to parse JSON - Unrecognized token 錯誤。

  解決方法：請勿在 <OASResource> 元素指定的 OpenAPI 規格 path 參數中使用 $ref。

297012500

• 如果使用 OpenAPI 3.0.0 規格的循環參照，Apigee 部署作業會失敗，因為 OAS 驗證政策會進入無限迴圈。

解決方法：使用不含循環參照的 OpenAPI 規格 YAML。

289254725

如果發生下列情況，包含 OASValidation 政策的 Proxy 部署作業可能會失敗：

• OASValidation 政策中用於驗證的 OpenAPI 規格採用 YAML 格式，
• YAML 格式的 OpenAPI 規格包含浮點數。例如：

  schema:
  type: number
  example: 2.345

284500460

為避免用戶端回應延遲時間增加，訊息記錄政策應附加至 PostClientFlow。如要進一步瞭解如何在 PostClientFlows 中使用政策，請參閱「 使用流程控制 API Proxy」。

282997216

Cassandra Jolokia 密碼只能使用英數字元。使用特殊字元 (包括但不限於「!」、「@」、「#」、「$」、「%」、「^」、「&」和「*」) 可能會導致 Cassandra 啟動失敗。

270371160

Apigee Ingress 閘道僅支援 TLS 1.2 以上版本，不支援舊版 TLS。

269139342

Apigee 組織驗證不遵循 overrides.yaml 中設定的 HTTP 轉送 Proxy 規則集。設定 validateOrg: false 即可略過這項驗證。

266452840

在某些情況下，使用 Anthos 服務網格 1.15.3-asm.6 時，WebSocket 無法用於 Apigee X 和 Apigee hybrid。

287922301

根據目前的設計，如果交易發生在接近交易量級距門檻的時間點，系統可能會評估出不準確的營利率。這會導致系統以門檻前費率評估過多交易，而且如果特定開發人員和費率方案組合在 30 秒內發生多筆交易，就更有可能發生這種情況。這表示營利報表會高估分級費率降低時的費用，並低估分級費率提高時的費用。這個問題會發生在 Apigee X 和 Apigee Hybrid，目前沒有已知的解決方法。 我們已著手解決問題，並會在日後推出的版本中提供修正。

242213234

嘗試載入 API 產品時，可能會傳回以下錯誤： 「Products were not loaded successfully. 錯誤：Apigee Connect 代理程式沒有可用的連線。

在 Google Cloud 雲端專案中啟用 VPC Service Controls，並將 iamcredentials.googleapis.com 新增為 service perimeter 中的受限制服務後，就會發生這個問題。

解決方法：手動建立輸出規則，例如：

-egressTo:
    operations:
    -serviceName: "iamcredentials.googleapis.com"
        methodSelectors:
        -method:
    resources:
    -projects/608305225983
  egressFrom:
    identityType: ANY_IDENTITY

247540503

在某些情況下，如果處理量極高，加密金鑰查詢的競爭狀況可能會導致 KVM 查詢失敗。

258699204

如果發現 apigee-telemetry-app 或 apigee-telemetry-proxy Pod 未執行的問題，請變更 metrics 資源要求和資源限制屬性，以符合 設定屬性參考資料：指標中的下列預設值。

使用 apigeectl apply 搭配 ‑‑telemetry 旗標套用變更：

apigeectl apply --telemetry -f overrides.yaml

260324159

在某些情況下，由於同步器發生「通訊端已關閉」錯誤，API Proxy 和共用流程可能需要約 20 到 30 分鐘才能部署至執行階段層。

214447386

這項作業預計每分鐘執行一次，不會影響您的帳單費用。

260772383

在 AKS 上安裝混合式服務時，可能會看到以下錯誤：

envoy config listener '0.0.0.0_443' failed to bind or apply socket options: cannot bind '0.0.0.0:443': Permission denied

解決方法：將下列 svcAnnotations 段落新增至覆寫檔案：

ingressGateways:
- name: INGRESS_NAME
  ...
  svcAnnotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"

請參閱「 設定混合式執行階段」。另請參閱「 搭配使用內部負載平衡器與 AKS」。

241786534

使用組織範圍的 UDCA 時，MART 有時無法連線至 FluentD。在 Apigee Hybrid 1.8 版中，預設為組織範圍的 UDCA。請參閱設定屬性參考資料中的 orgScopedUDCA。

在 Apigee Hybrid 1.6.6 版中，將 apigee-logger 從 fluend 遷移至 fluent-bit 後，記錄器在搭載 CentOS 或 RHEL 的 Anthos BareMetal 上停止運作。

目前的 apigee-logger 設定 (包括有效性探測) 與 Kubernetes 執行階段不相容，導致記錄無法正常傳送至 Cloud Logging。這個問題也會導致 apigee-logger Pod 定期停止運作。這個問題會影響 AKS、Anthos 裸機和其他平台上的 Apigee Hybrid 安裝作業。請注意，在某些情況下，這個問題會導致記錄量過多。

在 Apigee UI 中，您無法查看、確認部署狀態或管理封存部署項目 (如「 部署 API Proxy」所述)，也無法使用偵錯 UI (如「 使用偵錯」所述)。如要解決這個問題，您可以使用 gcloud 或 API 列出環境中的所有封存部署項目，並使用 Debug API。

目前不支援復原封存部署作業。 如要移除封存部署作業的版本，您必須 重新部署先前的封存版本，或 刪除環境。

421402073

VS Code 中的 Apigee 不支援 ServiceCallout 和 ExternalCallout 政策中的 Google 驗證，詳情請參閱「 使用 Google 驗證」。

停用 DistributedTrace 時，無法使用 x-b3 標頭

在 Apigee 1-15-0-apigee-5 和混合式 1.15.0 版本中，如果停用分散式追蹤，Apigee 會停止將 x-b3 標頭傳送至目標端點。不過，無論是否啟用分散式追蹤，部分 Apigee 安裝作業都會依賴傳送的 x-b3 標頭。因此，自 Apigee 1-15-0-apigee-7 起，這項變更已還原。

HTTP 標頭無效錯誤：Istio 輸入會將所有傳入目標回應切換為 HTTP2 通訊協定。由於混合式訊息處理器僅支援 HTTP1，因此呼叫 API Proxy 時，您可能會看到下列錯誤：

http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1,

name: [:authority], value: [domain_name]

如果看到這則錯誤訊息，可以採取下列任一做法來修正問題：

• 修改目標服務，在回應中省略 Host 標頭。
• 如有需要，請在 API Proxy 中使用 AssignMessage 政策移除 Host 標頭。

420985360

• 當您在入口網站上使用 SmartDocs 發布 API 時，Apigee 支援 OpenAPI 規格 3.0，但部分功能尚不支援。例如，用於合併及擴充結構定義的 allOf 屬性。

  如果 OpenAPI 規格參照了不支援的功能，在某些情況下，工具會忽略該功能，但仍會轉譯 API 參考文件。在其他情況下，不支援的功能會導致錯誤，使 API 參考文件無法成功算繪。無論是哪一種情況，您都必須修改 OpenAPI 規格，避免使用不支援的功能，直到日後版本支援該功能為止。

• 「試用這個 API」功能有下列限制：
  • 無論 OpenAPI 規格中為 consumes 設定的值為何，Accept 標頭都會設為 application/json。
  • 不支援字串以外的要求標頭類型。

• 目前不支援多位使用者同時更新入口網站 (例如編輯頁面、主題、CSS 或指令碼)。
• 如果從入口網站刪除 API 參考文件頁面，就無法重新建立。您必須刪除並重新加入 API 產品，然後重新產生 API 參考文件。
• 自訂入口網站主題後，變更最多可能需要 5 分鐘才會完全生效。

在日後的版本中，搜尋功能會整合至整合式入口網站。

自訂網域不支援透過 SAML 識別資訊提供者進行單一登出 (SLO)。如要為 SAML 識別資訊提供者啟用自訂網域，請在 設定 SAML 設定時，將「登出網址」欄位留空。

• API Proxy 要求和回應數量 (Proxy 和目標) 異常飆升

  以下是這類尖峰的範例：

  (查看放大圖片)

  
• 由於系統發生錯誤，因此在短時間內記錄的計數有誤，但隨後已修正。當 API 流量減少時 (導致 API 閘道縮減)，就會發生這種情況。
• 如要區分實際要求量激增和這個問題，請參閱 API Analytics 頁面 (特別是「Proxy 效能」和「目標效能」頁面)

受影響的指標：

• apigee.googleapis.com/proxyv2/request_count
• apigee.googleapis.com/proxyv2/response_count
• apigee.googleapis.com/targetv2/request_count
• apigee.googleapis.com/targetv2/response_count

新指標

您可以使用新指標來避免這個問題。

如果是 Apigee Hybrid，請參閱「指標收集總覽」和「查看指標」。

解決方法：停用混合式 Logging 代理程式。

解決方法：如要維持啟動後不須控制的行為：

1. 將 <Response>calloutResponse</Response> 新增至 ServiceCallout。
2. 將 continueOnError 設為 true。

解決方法：請避免在 Proxy 中使用多個 SpikeArrest 政策，以免發生問題。

如果特定金鑰有持續流量，則該金鑰可能不會以更新後的頻率限制。如果特定金鑰在五分鐘內沒有流量，系統就會反映費率。

解決方法：如果費率必須立即生效，請使用新的參照變數重新部署 Proxy。或使用兩個具有不同流程變數的條件式尖峰停滯，調整頻率。

如果目標傳回非 2xx 狀態的回應，可設定 API Proxy 的 API Monitoring 可能會顯示「(not set)」錯誤代碼。

如果 Proxy 在兩個以上的流程中，使用相同的目標主機設定兩個以上的 io.timeout.millis 值，系統只會採用一個 io.timeout.millis 值。

升級至 Apigee hybrid 1.8.x 期間，執行 apigeectl init 並確認 check-ready 成功後，如果查看 Pod，可能會發現 Cassandra 結構定義驗證工作處於錯誤狀態。這種情況不會造成任何損害，您可以放心進行升級程序的下一個步驟。

您無法將路徑相同的 Proxy 部署至多個環境，而這些環境附加至相同的執行個體和環境群組。系統應會傳回基本路徑衝突的警告訊息。系統不會顯示錯誤，而是會顯示部署作業成功。

解決方法：在部署期間和部署後，確認基本路徑與已部署的 Proxy 沒有衝突，並視需要修正。

嘗試儲存先前部署的 Proxy 時，部署作業可能會失敗，並顯示修訂版本不可變更的錯誤訊息。

解決方法：按一下「Save」(儲存) 按鈕旁的下拉式箭頭，然後選取「Save as new revision」(另存為新的修訂版本)。然後重新嘗試部署。

呼叫 gRPC 目標伺服器時，系統只會傳回「grpc-status」結尾。所有其他結尾都會從回應中移除。

當後端回應包含與父項結構定義相同的區別類型時，OASValidation 政策中會發生無限遞迴。這個問題可能會導致StackOverflowError。

請為 SSE (伺服器傳送事件) 目標使用不同的目標端點定義。混合 SSE 和非 SSE 目標端點可能會導致不一致的行為，例如空白的 response.content 流程變數。

先前未偵測到的 DNS 設定問題，現在可能會導致 DNS 錯誤。Apigee 移除了 1-16-0-apigee-2 中的自動 DNS 備用功能。移除後，平台將無法彈性因應 DNS 設定錯誤，現在可能會導致 DNS 錯誤。

查看執行階段記錄，找出 DNS 解析錯誤，並找出相關錯誤。

所有 Proxy 部署作業都會在本機失敗，並顯示包含 Error parsing deployment report as JSON 的錯誤訊息：

06/13/2025 6:45 PM EMULATOR INFO Deploying environment testenv, to Container apigee-1.14.2 (1.14.2)
06/13/2025 6:45 PM EMULATOR ERROR Error parsing deployment report as JSON
06/13/2025 6:45 PM EMULATOR ERROR null
06/13/2025 6:45 PM EMULATOR ERROR Environment testenv deployment, to Container apigee-1.14.2 (1.14.2) failed with Error: 500
06/13/2025 6:45 PM EMULATOR ERROR Deploy to Container apigee-1.14.2 (1.14.2), failed with Error: Environment testenv deployment, to Container apigee-1.14.2 (1.14.2) failed with Error: 500