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

您目前查看的是 Apigee 和 Apigee Hybrid 說明文件。
這個主題沒有對應的 Apigee Edge 說明文件。

問題

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

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

錯誤訊息

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

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

可能原因

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

原因	說明
路徑設定有誤	目標路徑不會匯出至與 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 中的「虛擬私有雲網路」->「虛擬私有雲網路對等互連」部分。請注意，如果您使用共用 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 進行通訊。

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

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

診斷

目標可能無法從 VPC 存取，或無法接受連線。有兩種做法可診斷問題。

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

解析度

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

如果從 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，然後前往下一個步驟：
在要求 PreFlow 中新增 ServiceCallout 政策。ServiceCallout 應呼叫「https://icanhazip.com」、「https://mocktarget.apigee.net/ip」或任何其他公開端點，這些端點會在回應中傳回呼叫者 IP 位址。將回應儲存在「response」變數中，以便在「Debug」中查看內容。以下是 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 分時，tps 成長至 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 指令輸出內容