您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊
問題
用戶端應用程式收到 502 Bad Gateway 錯誤。如果訊息處理器沒有收到後端伺服器的回應，就會將此錯誤傳回用戶端應用程式。
錯誤訊息
用戶端應用程式接收下列回應代碼：
HTTP/1.1 502 Bad Gateway
此外，您可能會遇到以下錯誤訊息：
{
"fault": {
"faultstring":"Bad Gateway",
"detail":{
"errorcode":"messaging.adaptors.http.flow.BadGateway"
}
}
}
可能原因
可能的原因如下：
| 原因 | 說明 | 疑難排解步驟： |
| TLS/SSL 握手逾時 | 訊息處理器與後端伺服器之間的 TLS/SSL 握手期間，會發生逾時。 | 邊緣私有雲和公有雲使用者 |
原因：TLS/SSL 握手逾時
在 Apigee Edge 中，您可以設定對後端伺服器的傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 連線，以啟用邊緣訊息處理器與後端伺服器之間的傳輸層安全標準 (TLS) 通訊。
TLS/SSL 握手程序需要完成多個步驟。此錯誤通常會在訊息處理器與後端伺服器之間的 TLS/SSL 握手逾時時發生。
診斷
本節說明如何正確診斷 TLS/SSL 握手逾時。 畫面上會列出 Edge Private Cloud 和公用雲端的操作說明。
調查 Trace 工作階段輸出內容
下列步驟說明如何使用 Apigee Edge Trace 工具進行初步診斷。
- 在 Edge UI 中，為受影響的 API Proxy 啟用「Trace 工作階段」。
如果 API 要求失敗的追蹤記錄顯示以下內容，可能表示發生了 TLS/SSL 握手逾時錯誤。這個錯誤可能的原因是後端伺服器防火牆封鎖了來自 Apigee 的流量。
- 判斷是否在 55 秒之後發生「502 Bad Gateway」錯誤 (這是訊息處理器上設定的預設逾時期限)。如果您在 55 秒後看見這項錯誤，則表示逾時是問題可能的原因。
- 判斷錯誤是否顯示錯誤：messaging.adaptors.http.BadGateway。 再次提醒，這項錯誤通常表示發生逾時。
若您使用的是 Edge Private Cloud，請記下追蹤記錄輸出中 X-Apigee.Message-ID 欄位的值，如下所示。私人 Cloud 使用者可以使用此 ID 值執行進一步的疑難排解，如後文所述。
按一下追蹤記錄路徑中的「Analytics Data Recorded」圖示：
向下捲動，並記下「X-Apigee.Message-ID」欄位的值。
如要確認 TLS/SSL 握手逾時是否為錯誤原因，請根據您使用的採用公有雲或私有雲，按照以下各節的步驟操作。
僅適用於 Edge Private Cloud 使用者的其他診斷步驟
如果您使用的是 Apigee Edge Private Cloud，可以執行下列步驟，驗證握手錯誤的原因。在這個步驟中，您將檢查郵件處理器記錄檔來取得相關資訊。如果您使用的是 Edge Public Cloud，可以略過這一節，並參閱適用於私人和公有雲使用者的其他診斷步驟。
使用
telnet指令確認是否能從各個訊息處理器直接連線至特定後端伺服器：如果後端伺服器會解析為單一 IP 位址，請使用下列指令：
telnet BackendServer-IPaddress 443
如果後端伺服器會解析多個 IP 位址，請在 telnet 指令中使用後端伺服器的主機名稱，如下所示：
telnet BackendServer-HostName 443
如果可以順利連上後端伺服器，請進行下一個步驟。
如果
telnet指令失敗，您必須與網路團隊合作，檢查訊息處理工具與後端伺服器之間的連線能力。查看「訊息處理者」記錄檔，瞭解握手失敗的原因。開啟檔案：
/opt/apigee/var/log/edge-message-processor/system.log並搜尋專屬訊息 ID (您在追蹤檔中找到的 X-Apigee.Message-ID 值)。請確認您是否看到與訊息 ID 相關的握手錯誤訊息，如下所示：
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443 Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms isOpen=true handshake timeout
如果郵件處理工具的記錄檔中顯示這個錯誤，請繼續進一步調查。請參閱「適用於邊緣私人和公有雲使用者的其他診斷步驟」。
如果記錄檔中未顯示握手訊息，請參閱「收集診斷資訊」
適用於邊緣私有雲和公有雲使用者的其他診斷步驟
如要進一步找出問題所在，您可以使用 tcpdump 工具分析 TCP/IP 封包，確認 TLS/SSL 握手期間是否發生逾時。
- 如果您是私人 Cloud 使用者，可以在後端伺服器或訊息處理器中擷取 TCP/IP 封包。建議在後端伺服器擷取這些封包，因為封包已在後端伺服器上解密。
- 如果您是公開雲端使用者，就無法存取訊息處理器，但是在後端伺服器上擷取 TCP/IP 封包可能有助於找出問題。
決定擷取 TCP/IP 封包的位置後，請使用以下 tcpdump 指令擷取 TCP/IP 封包。
tcpdump -i any -s 0 host <IP address> -w <File name>使用 Wireshark 工具或類似工具分析 TCP/IP 封包。以下螢幕截圖顯示 Wireshark 中的 TCP/IP 封包。
請注意，在 Wireshark 輸出中，三向 TCP 握手已在前 3 個封包中成功完成。
接著，訊息處理器會傳送封包 #4 中的「Client Hello」訊息。
由於沒有來自後端伺服器的確認，訊息處理器會在等待預先定義的時間間隔後，在 5、6 和 7 封包中重新傳送「Client Hello」訊息多次。
重試 3 次後，如果訊息處理者未收到任何確認，訊息處理者會傳送 FIN, ACK 訊息到後端伺服器，以表示正在關閉連線。
如 Wireshark 工作階段範例所示，後端連線成功 (步驟 #1)，但後端伺服器從未回應，因此 SSL 握手逾時。
如果您已執行本應對手冊中的疑難排解步驟，且確定逾時會導致 TLS/SSL 握手錯誤，請參閱「Resolution」一節。
使用 API Monitoring 找出問題
API 監控功能可讓您快速隔離問題區域，以診斷錯誤、效能與延遲問題及其來源 (例如開發人員應用程式、API Proxy、後端目標或 API 平台)。
逐步操作範例情境，示範如何使用 API Monitoring 排解 API 的 5xx 問題。例如，您可以設定快訊，讓系統在 messaging.adaptors.http.BadGateway 錯誤數量超過特定門檻時收到通知。
解析度
之所以發生 SSL 握手逾時，通常是因為後端伺服器設有防火牆限制，導致來自 Apigee Edge 的流量。如果您已按照診斷步驟操作，並確定握手錯誤導致是逾時，您需要與網路團隊聯絡，找出原因並修正防火牆限制。
請注意，防火牆限制可能會在不同的網路層套用。請務必確認所有網路層的限制都已移除與訊息處理器 IP 有關的限制，以確保 Apigee Edge 和後端伺服器之間的流量順暢。
如果沒有任何防火牆限制且/或問題仍未解決，請參閱「收集診斷資訊」。
收集診斷資訊的必要性
如果按照上述指示操作後仍無法解決問題，請收集以下診斷資訊。請與 Apigee Edge 支援團隊聯絡並分享相關資訊：
- 如果您是公有雲使用者，請提供下列資訊：
- 機構名稱
- 環境名稱
- API Proxy 名稱
- 完成 curl 指令即可重現錯誤
- 顯示錯誤的追蹤檔
- 後端伺服器擷取的 TCP/IP 封包
- 如果您是私有 Cloud 使用者，請提供下列資訊：
- 發現完整錯誤訊息
- API Proxy 套裝組合
- 顯示錯誤的追蹤檔
- 訊息處理器記錄檔 /opt/apigee/var/log/edge-message-processor/logs/system.log
- 後端伺服器或訊息處理器上擷取的 TCP/IP 封包。
- 詳細說明您曾在本教戰手冊中嘗試的章節，以及任何有助我們快速解決問題的深入分析。