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

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

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

問題

這個問題會在 API 監控、偵錯或其他工具中顯示為「503 - 服務無法使用」錯誤。「TARGET_CONNECT_TIMEOUT」原因表示 Apigee 執行個體與網際網路目標之間的連線逾時，或透過 VPC 互連可到達的目標。

請勿將這項錯誤與其他逾時錯誤 (例如 504 閘道逾時) 混淆。

錯誤訊息

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

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

可能的原因

請注意，這些原因僅適用於網際網路目標或可透過虛擬私有雲對等互連連線的目標。請參閱 Apigee 網路選項。如果目標是 PSC (端點連結)，請改為參閱 PSC 操作手冊。

原因	說明
路徑設定不當	目標路徑不會匯出至與 Apigee 執行個體對等的互連。
目標連線問題	目標不一定能接受 TCP 連線。
在目標中設定 IP 許可清單，但未加入部分或所有 Apigee NAT IP	並非所有 Apigee NAT IP 都會列入目標的許可清單。
NAT IP 通訊埠用盡	NAT 連接埠不足，無法容納流量。
connect.timeout.millis 值設定得太低	Apigee 端的連線逾時設定過低。

常見的診斷步驟

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

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

原因：路徑設定有誤

診斷

如果問題持續發生，即使問題是最近才開始發生，也可能是路徑設定錯誤所致。

這可能會影響內部 (在已建立連線的虛擬私有雲內部路由) 和外部 (網際網路) 目標。

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

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

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

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

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

解決方法

請查看網路架構，並確保路徑已匯出至 Apigee 的 VPC 對等互連網路。缺少的路線很可能是靜態或動態路線。缺少必要的動態路徑，表示對應功能 (例如 Cloud Interconnect) 有問題。

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

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

原因：目標的連線問題

診斷

目標可能無法從 VPC 存取，或無法接受連線。您可以透過兩種方式診斷問題。

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

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

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

在「Debug」中，前往「AnalyticsPublisher」AnalyticsPublisher (或在「傳統 Debug」中前往「AX」)。在畫面右側找出 target.ip 值。

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

原因：在目標中建立 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 政策新增至 Request PreFlow。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 (位於內容中)。或者，如果您將 ServiceCallout 回應儲存在其他位置，應會在該位置看到該回應。

請注意，在流程後續階段，Proxy 會呼叫目標，並將 Response 內容覆寫為目標的錯誤或回應。
嘗試將 NAT IP 與問題建立關聯。如果您發現只有特定 IP 無法運作，表示目標中只有部分 IP 位於許可清單中。
如果您發現 NAT IP 與錯誤之間並無關聯 (例如，同一個 IP 在某個要求中失敗，但在另一個要求中成功)，則很可能是其他問題，而非許可清單問題。這可能是 NAT 用盡的情況。請參閱「原因：網路位址轉譯 (NAT) IP 通訊埠用盡」。

解決方法

請確認您已配置及啟用 NAT IP，並確保所有 NAT IP 都已新增至目標端。

原因：NAT IP 通訊埠用盡

診斷

如果問題只會在 Apigee 中重現，且您的機構已配置 NAT IP，同時您發現問題同時發生在不同目標上，則可能表示 NAT 來源連接埠已用盡：

請記下問題發生的時間範圍。例如：每天下午 5 點 58 分至 6 點 8 分。
確認是否有其他目標在同一時間範圍內受到問題影響。該其他目標必須可透過網際網路存取，且不得與原始受影響的目標位於相同位置。
確認錯誤是否只會在 TPS 的特定流量量以上發生。如要這麼做，請記下問題發生的時間範圍，然後前往Proxy Performance 資訊主頁。
嘗試將錯誤時間視窗與每秒平均交易次數 (tps) 的上升趨勢連結。

在這個範例中，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 毫秒。詳情請參閱「Endpoints 屬性參考資料」。

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

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

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

發生 503 無法提供服務錯誤，且包含 TARGET_CONNECT_TIMEOUT (網際網路和 VPC 對等互連目標) 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

問題

錯誤訊息

可能的原因

常見的診斷步驟

原因：路徑設定有誤

診斷

解決方法

原因：目標的連線問題

診斷

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

VM 連線測試 (所有目標)

解決方法

原因：在目標中建立 IP 許可清單，但未加入部分或所有 Apigee NAT IP

診斷

解決方法

原因：NAT IP 通訊埠用盡

診斷

解決方法

原因：connect.timeout.millis 值設定得太低

診斷

解決方法

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

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