Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

發生 503 無法提供服務錯誤，且包含 TARGET_CONNECT_TIMEOUT (網際網路和 VPC 對等互連目標)

本頁內容適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

問題

這個問題會在 API 監控、偵錯或其他工具中，顯示為「503 - Service Unavailable」錯誤。「TARGET_CONNECT_TIMEOUT」原因表示 Apigee 執行個體與網際網路目標之間，或與可透過虛擬私有雲對等互連連線的目標之間，發生連線逾時。

請勿將此錯誤與其他逾時錯誤混淆，例如 504 閘道逾時。

錯誤訊息

這是偵錯工作階段或回應酬載中常見的錯誤。請注意原因： TARGET_CONNECT_TIMEOUT。

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

可能原因

請注意，這些原因僅適用於網際網路目標或可透過 VPC 對等互連連線的目標。請參閱「 Apigee 網路選項」。如果目標是 Private Service Connect (端點連結)，請改為參閱 Private Service Connect 劇本。

原因	說明
路徑設定有誤	目標路徑不會匯出至與 Apigee 執行個體的對等互連。
目標位置的連線問題	目標不一定能接受 TCP 連線。
在目標位置允許 IP 位址，但未新增部分或所有 Apigee NAT IP 位址	並非所有 Apigee NAT IP 都已加入目標的允許清單。
NAT IP 埠耗盡	網路位址轉譯 (NAT) 通訊埠不足，無法容納流量。
connect.timeout.millis 值設定過低	Apigee 端的連線逾時設定過低。

常見診斷步驟

偵錯是重要的工具，可擷取及評估下列問題詳細資料：

要求的總時間長度。通常需要三秒 (預設為 connect.timeout.millis) 才會發生連線逾時。如果發現時間較短，請檢查目標端點設定。
目標主機名稱和 IP 位址。如果顯示的 IP 位址有誤，可能表示 DNS 發生問題。您也可能會發現不同目標 IP 與問題之間的關聯。
頻率。視問題是間歇性還是持續性，需要採取不同的做法。

原因：路徑設定有誤

診斷

如果問題持續發生 (即使是最近才開始)，可能是因為路徑設定錯誤。

這可能會影響內部 (在對等互連的虛擬私有雲中路由) 和外部 (網際網路) 目標。

首先，請找出從 Apigee 執行個體解析的目標 IP 位址。其中一種方法是使用「偵錯」工作階段。在 Debug 中，前往「AnalyticsPublisher」(或舊版 Debug 中的「AX」)：

在畫面右側尋找 target.ip 值。

在本例中，IP 為 10.2.0.1。由於這個範圍是私人的，因此需要採取特定路由措施，確保 Apigee 可以連線至目標。

請注意，如果目標位於網際網路上，且 Apigee 已啟用 VPC Service Controls，您就必須按照這個步驟操作，因為這項功能會禁止網際網路連線。
請記下受影響 Apigee 執行個體的部署區域。在 Cloud 控制台的 Apigee UI 中，按一下「Instances」(執行個體)。在「Location」(位置) 欄位中，您可以找到例項的確切區域。
在與 Apigee 對等互連的專案中，前往 UI 中的「虛擬私有雲網路」->「虛擬私有雲網路對等互連」部分。請注意，如果您使用 Shared VPC，則必須在主專案中執行這些步驟，而不是在 Apigee 專案中執行。
點選「servicenetworking-googleapis-com」，選取「EXPORTED ROUTES」分頁，然後依步驟 2 取得的區域進行篩選。

這個範例顯示匯出的 10.2.0.0/24 路徑，並包含 10.2.0.1 範例目標 IP。如果沒有看到與目標相應的路徑，這就是問題的原因。
注意：如果目標是外部，則路徑通常不會出現在「匯出路徑」中，Apigee 要求會直接轉送至網際網路。但情況不一定如此，因此請務必釐清所需的網路拓撲。舉例來說，如果啟用 VPC Service Controls，您也需要匯出預設或其他路徑，才能連線至外部目標。

解析度

檢查網路架構，並確認路徑已匯出至與 Apigee 的虛擬私有雲對等互連。遺失的路徑很可能是靜態或動態。缺少必要的動態路徑表示對應功能 (例如 Cloud Interconnect) 有問題。

請注意，系統不支援遞移對等互連。換句話說，如果虛擬私有雲網路 N1 與 N2 和 N3 具有對等連線，但是 N2 和 N3 未直接連線，則虛擬私有雲網路 N2 無法透過虛擬私有雲網路對等互連與虛擬私有雲網路 N3 進行通訊。

詳情請參閱「南向網路模式」。

原因：目標位置發生連線問題

診斷

目標可能無法從虛擬私有雲連線，或無法接受連線。有兩種方法可診斷問題。

連線測試 (私人目標 IP 位址)

如果目標位於私人網路，您可以使用連線測試功能診斷常見原因。

找出從 Apigee 執行個體解析的目標 IP 位址。其中一種方法是使用「偵錯」工作階段。

在 Debug 中，前往「AnalyticsPublisher」AnalyticsPublisher (或舊版 Debug 中的「AX」AX)。在畫面右側尋找 target.ip 值。

在本範例中，IP 為 10.2.0.1。這是私人 IP 位址，因此可以使用連線測試。
記下無法連線至目標的 Apigee 執行個體 IP 位址。在 Apigee 控制台的「Instances」(執行個體) 中，找出「IP Address」(IP 位址) 欄位中的 Apigee 執行個體 IP 位址。
前往「Connectivity Tests」，然後點選「建立連線能力測試」。請提供下列詳細資料：
1. 來源 IP 位址：使用上述步驟 2 中取得的 Apigee 執行個體 IP。請注意，這並非 Apigee 用來將要求傳送至目標的確切來源 IP，但由於位於相同子網路中，因此足以進行測試。
2. 這是用於 Google Cloud 的 IP 位址：除非該位址位於您的任何 Google Cloud 專案中，否則請取消勾選。如要檢查這個值，請一併提供專案和網路。
3. 將目標地址 (步驟 1) 和通訊埠分別設為「目的地 IP 位址」和「目的地通訊埠」。
按一下「建立」，然後等待測試完成第一次執行。
在連線能力測試清單中，按一下「查看」即可查看執行結果。
如果結果為「無法連線」，表示設定有問題。工具應會將您導向Connectivity Tests 狀態說明文件，以繼續進行後續步驟。如果狀態為「可連線」，表示許多設定問題都已排除。不過，這不保證目標可達成。系統尚未實際嘗試與目標建立 TCP 連線。只有下方的診斷方式才能測試這點。

VM 連線測試 (所有目標)

在與 Apigee 對等互連的相同虛擬私有雲中，建立 Linux 上的 VM 執行個體。
從 VM 執行連線測試，最好是在 Apigee 可重現問題時進行。您可以使用 telnet、curl 和其他公用程式建立連線。這個 curl 範例會在迴圈中執行，逾時時間為三秒。如果 curl 無法在三秒內建立 TCP 連線，就會失敗。
```
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
```
檢查完整輸出內容，找出下列錯誤：
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
如果出現這項錯誤，表示問題可在 Apigee 以外的環境重現。

請注意，如果看到其他錯誤，例如 TLS 相關錯誤、錯誤的狀態碼等，這些錯誤不會確認連線逾時，且與這個問題無關。
如果目標需要 IP 許可清單，您可能無法從 VM 測試目標，除非您也將 VM 執行個體的來源 IP 加入許可清單。

解析度

如果根據 Connectivity Tests 結果發現問題，請按照說明文件中的解決步驟操作。

如果 VM 重現逾時問題，則無法提供明確的指引，說明如何解決目標端的相關問題。如果連線逾時問題可在 Apigee 以外重現，請從虛擬私有雲進一步追蹤問題。請盡可能在靠近目標的位置測試連線。

如果目標位於 VPN 連線後方，您或許也能從區域網路進行測試。

如果目標位於網際網路上，您可以嘗試在 Google Cloud 控制台外部重現問題。

如果問題發生在尖峰時段，目標可能因連線過多而無法負荷。

如果您需要在該階段提出 Google Cloud 支援服務案件，就不必再選取 Apigee 元件，因為現在可以直接從虛擬私有雲重現問題。

原因：目標的 IP 許可清單未加入部分或所有 Apigee NAT IP

診斷

這類目標是啟用 IP 允許清單的外部目標 (網際網路)。請確認所有 Apigee NAT IP 都已新增至受影響的目標端。如果目標沒有許可清單，可以略過這個部分。

如果錯誤是間歇性發生，就比較容易發現問題，因為在這種情況下，您或許可以找出特定 NAT IP 與錯誤之間的關聯。

如果問題持續發生 (所有呼叫都失敗)，請確保 Apigee 已啟用 NAT IP，並按照下列步驟擷取這些 IP：

列出執行個體的 NAT IP：

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

回覆範例：

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

如果輸出內容中沒有任何地址，表示 Apigee 端未新增 NAT IP。如果取得位址，但沒有一個是 ACTIVE，表示使用的位址都無法存取網際網路，這也是問題。

如果至少有一個有效位址，則可以在目標位置加入允許清單，因此 Apigee 端不會有設定錯誤。在這種情況下，目標的許可清單可能缺少該地址。

如果問題是間歇性發生，可能表示目標只將部分 NAT IP 加入許可清單。如要找出這類問題，請按照下列步驟操作：

建立新的反向 Proxy，並在 TargetEndpoint 中指定受影響的目標。您也可以改用現有 Proxy，然後繼續下一個步驟：
在要求預先流程中新增 ServiceCallout 政策。ServiceCallout 應呼叫「https://icanhazip.com」、「https://mocktarget.apigee.net/ip」或任何其他公開端點，在回應中傳回呼叫端 IP 位址。將回應儲存在「response」變數中，以便在「偵錯」中查看內容。以下是 ServiceCallout 政策設定範例：
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>
```
您也可以將回覆儲存在自訂變數中，但需要使用 AssignMessage 政策讀取該變數的「.content」，才能在偵錯工具中顯示回覆。

請確認目標的設定方式與受影響的 Proxy 完全相同。

注意：ServiceCallout 要求和 Target 要求都應在單一交易中發生。這是為了確保要求由同一部伺服器處理，因此受影響要求的 NAT IP 會與從 ServiceCallout 取得的 NAT IP 相符。
執行偵錯工作階段，然後按一下 ServiceCallout 步驟：
在右下角，您應該會看到「Response content」部分，其中包含發出要求的 Apigee 執行個體的 NAT IP (位於 Body 中)。或者，如果您將 ServiceCallout 回應儲存在其他位置，應該會看到該位置。

請注意，在流程的後續步驟中，Proxy 會呼叫目標，且回應內容會遭到錯誤或目標回應覆寫。
嘗試將 NAT IP 與問題建立關聯。如果發現只有特定 IP 位址失敗，表示目標只將部分 IP 位址加入許可清單。
如果 NAT IP 與錯誤之間沒有關聯性 (例如，同一個 IP 在某個要求中失敗，但在另一個要求中成功)，則這很可能不是許可清單問題。這可能是 NAT 耗盡。請參閱「原因：NAT IP 通訊埠耗盡」。

解析度

確認您已佈建並啟用 NAT IP，且所有 NAT IP 都已新增至目標端。

原因：NAT IP 通訊埠用盡

診斷

如果問題只能從 Apigee 重現，且已為貴機構佈建 NAT IP，而且您發現多個目標同時發生問題，則可能是 NAT 來源連接埠不足：

請記下問題發生的時間範圍。例如：每天下午 5:58 至 6:08。
確認是否有其他目標在同一時間範圍內受到問題影響。該其他目標必須可透過網際網路存取，且不得與原始受影響目標位於相同位置。
判斷錯誤是否只會在 TPS 流量超過特定量時發生。如要這麼做，請記下問題的時間範圍，然後前往「Proxy Performance」(Proxy 效能) 資訊主頁。
嘗試將錯誤時間範圍與每秒平均交易次數 (tps) 的增加量建立關聯。

在本範例中，下午 5 點 58 分時，每秒交易數增加至 1000。假設在這個範例中，下午 5:58 發生問題，且問題影響兩個以上不相關的目標，這就是 NAT 耗盡問題的信號。

解析度

請按照「計算靜態 NAT IP 需求」一文中的說明，重新計算 NAT IP 需求。

您也可以新增更多 NAT IP，看看是否能解決問題。請注意，新增更多 IP 位址可能需要先在所有目標中將這些 IP 位址加入允許清單。

原因：connect.timeout.millis 值設定過低

診斷

您可能在 Proxy 中設定了錯誤的逾時值。

如要檢查，請前往受影響的 Proxy，並檢查相關的 TargetEndpoint。請注意「connect.timeout.millis」屬性及其值。在本例中，值為 50，也就是 50 毫秒，通常太低而無法保證建立 TCP 連線。如果看到的值低於 1000，這很可能就是問題的原因。如果沒有看到「connect.timeout.millis」屬性，表示系統已設定預設值，但原因不明。

Proxy (含逾時)

解析度

修正 connect.timeout.millis 值，請務必注意時間單位為毫秒。預設值為 3000，也就是 3000 毫秒。詳情請參閱「端點屬性參考資料」。

如需進一步協助，請與支援團隊聯絡

如果按照上述指示操作後問題仍未解決，請收集下列診斷資訊，並提供給 Google Cloud 支援團隊：

專案 ID 和 Apigee 機構名稱
Proxy 名稱和環境
問題發生時間
問題發生的頻率
目標主機名稱
發生問題的偵錯工作階段
針對上述可能原因執行的檢查結果。例如，從 VM 執行的 curl 指令輸出內容