您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info
問題
用戶端應用程式收到 502 Bad Gateway 錯誤。如果訊息處理器未收到後端伺服器的回應，就會將這項錯誤傳回給用戶端應用程式。
錯誤訊息
用戶端應用程式會收到下列回應代碼：
HTTP/1.1 502 Bad Gateway
此外，您可能會看到下列錯誤訊息：
{
"fault": {
"faultstring":"Bad Gateway",
"detail":{
"errorcode":"messaging.adaptors.http.flow.BadGateway"
}
}
}
可能原因
下表列出這個問題的可能原因：
| 原因 | 說明 | 請按照下列疑難排解步驟操作： |
| TLS/SSL 握手程序逾時 | 在訊息處理器與後端伺服器之間的 TLS/SSL 交握期間發生逾時。 | Edge 私有雲和公有雲使用者 |
原因：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 的流量。
- 判斷「502 Bad Gateway」錯誤是否在 55 秒後發生，這是訊息處理器上設定的預設逾時時間。如果錯誤發生在 55 秒後，表示問題很可能是逾時所致。
- 判斷錯誤是否顯示故障：messaging.adaptors.http.BadGateway。 同樣地，這項錯誤通常表示發生逾時。
如果您使用 Edge Private Cloud，請記下追蹤輸出內容中「X-Apigee.Message-ID」欄位的值，如下所示。Private Cloud 使用者可以利用這個 ID 值進一步排解問題，詳情請參閱後續說明。
按一下追蹤路徑中的「記錄的 Analytics 資料」圖示：
向下捲動，並記下名為「X-Apigee.Message-ID」的欄位值。
如要確認 TLS/SSL 交握逾時是造成錯誤的原因，請按照下列章節中的步驟操作，具體取決於您使用的是公有雲或私有雲。
僅適用於 Edge Private Cloud 使用者的其他診斷步驟
如果您使用 Apigee Edge Private Cloud，可以按照下列步驟驗證交握錯誤的原因。在這個步驟中，您會檢查訊息處理器記錄檔，找出相關資訊。如果您使用 Edge Public Cloud，可以略過這個部分，直接前往「Private 和 Public Cloud 使用者的進一步診斷步驟」。
使用
telnet指令，檢查是否能從每個 Message Processor 直接連線至特定後端伺服器：如果後端伺服器解析為單一 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 使用者的進階診斷步驟」。
如果記錄檔中未顯示信號交換訊息，請參閱「必須收集的診斷資訊」
Edge 私有雲和公有雲使用者的進階診斷步驟
如要進一步找出問題，可以使用 tcpdump 工具分析 TCP/IP 封包，確認 TLS/SSL 交握期間是否發生逾時。
- 如果您是私有雲使用者，可以在後端伺服器或訊息處理器上擷取 TCP/IP 封包。最好在後端伺服器上擷取封包，因為封包會在後端伺服器上解密。
- 如果您是公有雲使用者，則無法存取 Message Processor，但擷取後端伺服器上的 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 輸出內容中，前 3 個封包會成功完成三向 TCP 握手。
訊息處理器接著會在封包 #4 中傳送「Client Hello」訊息。
由於後端伺服器未確認，訊息處理器會在等待預先定義的時間間隔後，在封包 5、6 和 7 中多次重新傳輸「Client Hello」訊息。
如果訊息處理器在 3 次重試後仍未收到任何確認訊息，就會將 FIN, ACK 訊息傳送至後端伺服器，表示要關閉連線。
如 Wireshark 工作階段範例所示，後端連線成功 (步驟 #1)，但 SSL 握手程序逾時，因為後端伺服器從未回應。
如果您已按照本應對手冊中的疑難排解步驟操作，並判斷 TLS/SSL 交握錯誤是由逾時所致，請前往「解決方案」一節。
使用 API Monitoring 找出問題
API Monitoring 可讓您快速找出問題區域，診斷錯誤、效能和延遲問題及其來源，例如開發人員應用程式、API Proxy、後端目標或 API 平台。
逐步瞭解範例情境，瞭解如何使用 API 監控功能排解 API 的 5xx 問題。舉例來說，您可能會想設定快訊，在 messaging.adaptors.http.BadGateway 錯誤數超過特定門檻時接收通知。
解析度
通常 SSL 交握逾時是因為後端伺服器的防火牆限制，導致 Apigee Edge 的流量遭到封鎖。如果您按照診斷步驟操作，並確定交握錯誤的原因是逾時，請與網路團隊合作找出原因，並修正防火牆限制。
請注意，防火牆限制可能會在不同網路層級強制執行。 請務必移除所有網路層級的限制，確保訊息處理器 IP 相關流量在 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 封包。
- 您已嘗試使用本 Playbook 中的哪些章節，以及任何其他有助於我們加快解決這個問題的洞察資訊。