您正在查看 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 連線，以便在 Edge 訊息處理器和後端伺服器之間啟用 TLS 通訊。
TLS/SSL 握手程序包含多個步驟。發生這項錯誤的原因通常是 訊息處理器與後端伺服器之間的 TLS/SSL 握手逾時。
診斷
本節說明如何正確診斷 TLS/SSL 握手逾時。 列出 Edge Private Cloud 和 Public Cloud 的操作說明。
調查追蹤工作階段輸出內容
下列步驟說明如何初步診斷問題 使用 Apigee Edge Trace 工具
- 在 Edge UI 中，為受影響的 API Proxy 啟用追蹤工作階段。
如果失敗 API 要求的追蹤記錄顯示以下內容，可能是因為發生 TLS/SSL 握手逾時錯誤。這項錯誤可能的原因是後端伺服器防火牆封鎖了來自 Apigee 的流量。
- 判斷在 55 秒後是否發生 502 Bad Gateway 錯誤， 是「訊息處理器」設定的預設逾時期限。如果您發現錯誤發生在 55 秒後，表示問題可能出在逾時。
- 判斷錯誤是否顯示錯誤：messaging.adaptors.http.BadGateway。同樣地，這個錯誤通常表示發生逾時。
如果您使用的是 Edge Private Cloud，請記下 追蹤記錄輸出內容中的 X-Apigee.Message-ID 欄位，如下所示。Private Cloud 使用者可以使用這個 ID 值進一步排解問題，詳情請參閱後文。
按一下追蹤記錄路徑中的「Analytics 資料記錄」圖示：
向下捲動並記下名為「X-Apigee.Message-ID」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
如果您在訊息處理器的記錄檔中看到這項錯誤，請繼續進行調查。請參閱「Edge Private 和 Public Cloud 使用者的其他診斷步驟」。
如果記錄檔中沒有握手訊息，請前往「Must Gather Diagnostic Information」。
Edge Private 和 Public Cloud 使用者的其他診斷步驟
如要進一步找出問題，您可以使用 tcpdump 工具分析 TCP/IP 封包，確認是否在 TLS/SSL 握手期間發生逾時情形。
- 如果您是私有雲使用者，可以在後端伺服器或訊息處理器上擷取 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」訊息。
由於系統不會從後端伺服器確認，因此「Message」 處理器重新傳輸「Client Hello」在封包中多次輸出訊息 5 6 和 7，直到達到預先定義的時間間隔。
如果「訊息處理器」在 3 次重試後仍未收到任何確認通知， 該伺服器會將 FIN, ACK 訊息傳送至後端伺服器，以表示正在關閉連線。
如 Wireshark 工作階段範例所示，連線至後端成功 (步驟 1)，但 SSL 握手逾時，因為後端伺服器從未回應。
如果您已執行本手冊中的疑難排解步驟，並判斷超時導致 TLS/SSL 握手錯誤，請參閱「解決方法」一節。
使用 API 監控功能找出問題
API Monitoring 可讓您 迅速診斷錯誤、效能和延遲問題，以及 來源，例如開發人員應用程式、API Proxy、後端目標或 API 平台。
逐步完成範例情境 ，示範如何使用 API Monitoring 排解 API 的 5xx 問題。 舉例來說，您可以設定快訊，在 messaging.adaptors.http.BadGateway 錯誤數量超過特定門檻時收到通知。
解析度
通常會發生 SSL 握手逾時，原因出在 封鎖來自 Apigee Edge 的流量如果您追蹤 並確認握手錯誤的原因 逾時，您必須與您的網路團隊討論，找出原因並修正 防火牆限制
請注意，防火牆限制可能會套用於不同的網路層。請務必移除所有網路層級的限制，以便確保 Apigee Edge 與後端伺服器之間的流量順暢。
如果沒有防火牆限制，且/或問題仍未解決，請參閱「必須收集診斷資訊」一節。
必須收集診斷資訊
按照上述說明操作後，如果問題仍未解決，請收集下列診斷資訊。請與 Apigee Edge 支援團隊聯絡，並提供以下資訊：
- 如果您是公有雲使用者，請提供下列資訊：
- 機構名稱
- 環境名稱
- API Proxy 名稱
- 完成 curl 指令，重現錯誤
- 顯示錯誤的追蹤記錄檔
- 在後端伺服器上擷取的 TCP/IP 封包
- 如果您是 Private Cloud 使用者，請提供下列資訊：
- 觀察到的完整錯誤訊息
- API Proxy 套裝組合
- 顯示錯誤的追蹤記錄檔
- 訊息處理器記錄檔 /opt/apigee/var/log/edge-message-processor/logs/system.log
- 在後端伺服器或訊息處理器上擷取的 TCP/IP 封包。
- 詳細說明您嘗試過這份應對手冊的哪些部分，以及任何有助於我們快速解決問題的深入分析。