502 閘道錯誤意外 EOF

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。 資訊

問題

用戶端應用程式取得 502 的 HTTP 狀態碼和相關訊息， Bad Gateway 做為 API 呼叫的回應。

HTTP 狀態碼 502 表示用戶端未收到 應實際執行要求的後端伺服器

錯誤訊息

用戶端應用程式會取得下列回應代碼：

HTTP/1.1 502 Bad Gateway

此外，您也可能會看到下列錯誤訊息：

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

可能原因

Unexpected EOF是 502 Bad Gateway Error 的常見原因之一 錯誤的可能原因如下：

原因 詳細資料 步數
目標伺服器設定有誤 目標伺服器設定有誤，因此無法支援 TLS/SSL 連線。 邊緣公有雲和私有雲使用者
後端伺服器的 EOFException 後端伺服器可能會突然傳送 EOF。 僅限 Edge Private Cloud 使用者
設定不正確，保持運作逾時 保持 Apigee 和後端伺服器的存留逾時設定不正確。 邊緣公有雲和私有雲使用者

常見的診斷步驟

如要診斷錯誤，您可以採用下列任一方法：

API Monitoring

如何使用 API Monitoring 診斷錯誤：

您可以使用 API Monitoring 進行調查 502 錯誤， 調查問題。具體說明如下：

  1. 前往「調查」資訊主頁。
  2. 在下拉式選單中選取「狀態碼」 ，確認時間正確無誤 發生 502 錯誤時，就會選取間隔。
  3. 畫面上顯示大量502錯誤時，請按一下矩陣中的方塊。
  4. 在右側按一下「查看記錄」，找出 502 錯誤， 如下所示：

    5. 即可查看下列資訊：

    • 「Fault Source」為 target
    • 「Fault Code」為 messaging.adaptors.http.UnexpectedEOFAtTarget

這表示目標因非預期的 EOF 導致 502 錯誤。

此外，請記下 502 錯誤的 Request Message ID，以便進一步查詢 並展開調查

追蹤工具

如何使用追蹤工具診斷錯誤：

  1. 啟用 追蹤工作階段，並發出 API 呼叫以重現問題502 Bad Gateway。
  2. 請選取其中一個失敗的要求，然後檢查追蹤記錄。
  3. 瀏覽追蹤記錄的各個階段，並找出失敗發生的位置。

  4. 將要求傳送到目標伺服器後，您應該會看到失敗，如下所示：

    alt_text

    alt_text

  5. 判斷 X-Apigee.fault-source 和 X-Apigee.fault-code 的值在 追蹤記錄中的 AX (記錄的數據分析資料) 階段。

    如果 X-Apigee.fault-source 和 X-Apigee.fault-code 的值符合 值，就表示 502 錯誤 來自目標伺服器：

    回應標頭 值
    X-Apigee.fault-source target
    X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget

    此外，請記下 502 錯誤的 X-Apigee.Message-ID 以展開進一步調查

NGINX 存取記錄

如何使用 NGINX 診斷錯誤：

您也可以參閱 NGINX 存取記錄，找出「502」狀態的原因 再也不是件繁重乏味的工作如果問題是過去發生或 且無法在 UI 中擷取追蹤記錄。請按照下列步驟 判斷這項資訊是否來自 NGINX 存取記錄：

  1. 查看 NGINX 存取記錄。
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. 搜尋特定期間內與特定 API Proxy 相關的 502 錯誤 (如果問題過去發生) 或是任何要求仍使用 502 失敗。
  3. 如果發生任何 502 錯誤，請確認錯誤是否由目標造成。 正在傳送 Unexpected EOF。如果 X-Apigee.fault-source 和 X- Apigee.fault-code 與下表顯示的值相符，502錯誤發生 (因目標意外關閉連線所致)：
    回應標頭 值
    X-Apigee.fault-source target
    X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget

    以下項目範例顯示目標伺服器造成的 502 錯誤：

此外，請記下 502 錯誤的郵件 ID，以便進一步調查。

原因：目標伺服器設定錯誤

目標伺服器設定有誤，因此無法支援 TLS/SSL 連線。

診斷

  1. 使用 API 監控、追蹤工具或 NGINX 存取記錄，判斷郵件 ID、 錯誤程式碼，以及 502 錯誤的錯誤來源。
  2. 在使用者介面中為受影響的 API 啟用追蹤記錄。
  3. 如果失敗 API 要求的追蹤記錄顯示以下內容：
    1. 啟動目標流程要求後，系統就會立即顯示 502 Bad Gateway 錯誤。
    2. error.class 會顯示 messaging.adaptors.http.UnexpectedEOF.

      那麼這類問題很可能是由不正確的目標伺服器所造成 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定

  4. 使用 Edge Management API 呼叫取得目標伺服器定義：
    1. 如果您是公用雲端使用者，請使用這個 API： 
      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
    2. 如果您是 Private Cloud 使用者，請使用這個 API： 
      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      錯誤 TargetServer 定義範例：

      <TargetServer  name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

  5. 上述的 TargetServer 定義是其中一項常見的 錯誤設定的說明如下：

    假設目標伺服器 mocktarget.apigee.net 已設定完成 接受通訊埠 443 的安全 (HTTPS) 連線。不過，如果您查看 目標伺服器定義，沒有其他屬性/標記來表示 適用於安全連線這會導致 Edge 將傳送至 將特定目標伺服器當做 HTTP (非安全) 要求。Edge 不會 此目標伺服器啟動 SSL 握手程序。

    由於目標伺服器設定為在 443 中只接受 HTTPS (SSL) 要求，因此將會 拒絕來自 Edge 的要求或關閉連線。因此，您會得到 訊息處理器發生 UnexpectedEOFAtTarget 項錯誤。訊息處理者 502 Bad Gateway 做為對用戶端的回應。

解析度

請務必確保目標伺服器已根據您的需求設定正確。

請參考上述範例中的範例，瞭解如何向安全的 (HTTPS/SSL) 目標發出要求 伺服器，您需要加入已設定 enabled 標記的 SSLInfo 屬性 至 true。雖然您可以對目標中的目標伺服器新增 SSLInfo 屬性， 端點定義本身，建議您將 SSLInfo 屬性新增為目標的一部分。 避免混淆

  1. 如果後端服務需要單向 SSL 通訊，請：
    1. 您必須加入 SSLInfo，以在 TargetServer 定義中啟用 TLS/SSL enabled 標記設為 true 的屬性，如下所示： 
      <TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    2. 如要在 Edge 中驗證目標伺服器的憑證，您還必須 包含信任儲存庫 (包含目標伺服器的憑證)，如下所示： 
      <TargetServer  name="mocktarget">
    <Host>mocktarget.apigee.net</Host>
    <Port>443</Port>
    <IsEnabled>true</IsEnabled>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <Protocols/>
        <TrustStore>mocktarget-truststore</TrustStore>
    </SSLInfo>
</TargetServer>
  2. 如果後端服務需要雙向 SSL 通訊，請：
    1. 您需要具備 SSLInfo 屬性和 ClientAuthEnabled， Keystore、KeyAlias和 已正確設定 Truststore 標記，如下所示： 
      <TargetServer  name="mocktarget">
     <IsEnabled>true</IsEnabled>
     <Host>www.example.com</Host>
     <Port>443</Port>
     <SSLInfo>
         <Ciphers/>
         <ClientAuthEnabled>true</ClientAuthEnabled>
         <Enabled>true</Enabled>
         <IgnoreValidationErrors>false</IgnoreValidationErrors>
         <KeyAlias>keystore-alias</KeyAlias>
         <KeyStore>keystore-name</KeyStore>
         <Protocols/>
         <TrustStore>truststore-name</TrustStore>
     </SSLInfo>
  </TargetServer >

參考資料

負載平衡 以及跨後端伺服器

原因：後端伺服器中的 EOFException

後端伺服器可能會突然傳送 EOF (檔案結尾)。

診斷

  1. 使用 API 監控、追蹤工具或 NGINX 存取記錄，判斷郵件 ID、 錯誤程式碼，以及 502 錯誤的錯誤來源。
  2. 查看訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)，搜尋看看您是否 必須含有特定 API 的 eof unexpected，或您對 API 有專屬的 messageid 您就能搜尋該圖片

    訊息處理器記錄中的例外狀況堆疊追蹤範例

    "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
java.io.EOFException: eof unexpected
at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

    在上述範例中，您可以看到訊息處理器嘗試讀取以下回應時發生 java.io.EOFException: eof unexpected 錯誤 後端伺服器這個例外狀況表示檔案結尾 (EOF) 或串流結尾 能正常播放

    也就是說，「訊息處理者」已將 API 要求傳送至後端伺服器 或是讀取回應不過，後端伺服器突然終止連線 或能夠讀取完整回應

  3. 檢查您的後端伺服器記錄，看看是否有任何錯誤或資訊 已指示後端伺服器突然終止連線。如果發現任何 前往「解決」 並妥善修正後端伺服器的問題。
  4. 如果你在後端伺服器中找不到任何錯誤或資訊，請在訊息處理器上收集 tcpdump 輸出內容：
    1. 如果您的後端伺服器主機擁有單一 IP 位址，請使用下列指令： 
      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
    2. 如果您的後端伺服器主機有多個 IP 位址，請使用下列指令： 
      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      造成這項錯誤的原因通常是後端伺服器傳回 [FIN,ACK]。

  5. 請參考以下 tcpdump 範例。

    502 Bad Gateway Error (UnexpectedEOFAtTarget) 發現的 tcpdump 樣本 發生

  6. 從 TCPDump 輸出中，您注意到下列事件序列：
    1. 在 985 封包中，「訊息處理者」將 API 要求傳送至後端伺服器。
    2. 在 986 封包中，後端伺服器會立即傳回 [FIN,ACK] 的回應。
    3. 在 987 封包中，訊息處理者會以 [FIN,ACK] 回應後端 伺服器
    4. 最終雙方都與 [ACK] 和 [RST] 關閉了連線。
    5. 後端伺服器會傳送 [FIN,ACK]，因此您會收到例外狀況 訊息中有 java.io.EOFException: eof unexpected 例外狀況 處理器。
  7. 如果後端伺服器發生網路問題，就可能發生這種情況。與您的人脈網路互動 作業團隊進一步調查這個問題。

解析度

妥善修正後端伺服器的問題。

如果問題仍未解決，且你需要我們協助排解問題，請502 Bad Gateway Error；或 懷疑這是 Edge 中的問題，請與 Apigee Edge 支援團隊聯絡。

原因：未正確設定保持運作逾時

在診斷這是否為502錯誤的原因之前，請先詳閱下列說明 下列概念

Apigee 中的永久連線

Apigee 預設 (且隨 HTTP/1.1 標準) 會使用永久連線 與目標後端伺服器通訊時可有完整的通訊內容永久連線可提高效能 允許重複使用已建立的 TCP 和 (如適用) TLS/SSL 連線 可降低延遲負擔連線需要保留的時間長度會受控制 載入資源「保持運作逾時」 (keepalive.timeout.millis)。

後端伺服器和 Apigee 訊息處理者都會使用存留逾時時間來保留 連結是由另一個應用程式開啟在保持運作逾時前未收到任何資料 時，後端伺服器或訊息處理者就能關閉兩者的連線。

根據預設，部署至 Apigee 訊息處理器的 API Proxy 的存留時間已設為 60s (除非遭到覆寫)。未收到 60s 的資料後，Apigee 就會 關閉與後端伺服器的連線。而後端伺服器也會維持運作逾時 到期後，後端伺服器會關閉與訊息處理器的連線。

不正確保持運作逾時設定的影響

如果 Apigee 或後端伺服器設定的保持運作逾時有誤， 會產生競爭狀況，導致後端伺服器傳送非預期的 End Of File (FIN) 來回應資源的要求。

舉例來說，如果你在 API Proxy 或「訊息」應用程式中設定保持運作逾時 值大於或等於上游後端伺服器逾時的處理器，然後 下列競爭狀況可能會發生。也就是說，如果「訊息處理者」沒有收到 直到接近後端伺服器臨界值門檻，使系統保持運作逾時後， 且會透過現有的連線傳送至後端伺服器。這會導致 502 Bad Gateway 因發生非預期的 EOF 錯誤，如下所述：

  1. 假設在訊息處理器和後端伺服器上設定保持運作逾時 60 秒，但也沒有任何新的 直到指定要求數量的 59 秒 訊息處理器。
  2. 訊息處理器會處理並處理在第 59 秒內收到的要求 使用現有的連線 (因為保持運作逾時尚未結束)，然後傳送 要求將要求傳送至後端伺服器
  3. 不過，在要求送達後端伺服器之前，保持運作逾時 超過此門檻。
  4. 訊息處理者對資源的要求正在處理中，但後端伺服器 嘗試將 FIN 封包傳送至「訊息」，藉此關閉連線 處理器。
  5. 訊息處理者在等待接收資料時，會改為接收 非預期的 FIN，且連線已終止。
  6. 這會產生 Unexpected EOF，而 502 則是 訊息處理者傳回用戶端。

在這個例子中，我們觀察到發生 502 錯誤，因為相同的保持運作逾時 訊息處理器和後端伺服器已設定 60 秒的值。同樣地 如果將較高的值設為保持「訊息」的存留時間上限，也可能會發生這個問題 處理者比後端伺服器的處理器慢。

診斷

  1. 如果您是公有雲使用者：
    1. 使用 API 監控或追蹤工具 (如 常見診斷步驟)，並確認您同時符合下列兩項條件 設定：
      • 錯誤代碼： messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • 錯誤來源： target
    2. 如要進一步調查，請參閱使用 tcpdump。
  2. 如果您是 Private Cloud 使用者：
    1. 使用追蹤工具或 用來判斷郵件 ID 的 NGINX 存取記錄， 502 錯誤的錯誤程式碼和錯誤來源。
    2. 在訊息處理者記錄中搜尋郵件 ID
      (/opt/apigee/var/log/edge-message-processor/logs/system.log)。
    3. 您看到的 java.io.EOFEXception: eof unexpected 如下所示： 
      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
        java.io.EOFException: eof unexpected
        at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
        at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
        at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
        at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
        at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
    4. 錯誤 java.io.EOFException: eof unexpected 表示 訊息處理器在等待讀取 EOF 時收到 回應。
    5. 上述錯誤訊息中的屬性 useCount=7 表示 訊息處理者重複使用了這個連結七次，且使用了屬性 bytesWritten=159 表示訊息處理器已傳送要求 將 159 位元組的酬載傳送至後端伺服器。但收到 0 個位元組 復原為未預期 EOF 的時間點。

    6. 這顯示訊息處理器 曾多次重複使用同一個連線 發生這種情況時，資料會在傳送後不久，但不久後卻收到 EOF 未接收任何資料。這表示後端 伺服器的保持運作逾時較短或等於 API Proxy 中設定的逾時時間。

      您可以按照下列說明，使用 tcpdump 的幫助進一步調查。

使用 tcpdump

  1. 使用下列指令在後端伺服器上擷取 tcpdump： 
    tcpdump -i any -s 0 host MP_IP_Address -w File_Name
  2. 分析擷取的 tcpdump：

    以下是 tcpdump 輸出內容範例：

    在上述 tcpdump 範例中，您可以看到：

    1. 在封包 5992, 中，後端伺服器收到 GET 要求。
    2. 在 6064 封包中，它會以 200 OK. 回應
    3. 在封包 6084 中，後端伺服器收到另一項 GET 要求。
    4. 在 6154 封包中，它會以 200 OK 回應。
    5. 在 6228 封包中，後端伺服器收到第三個 GET 要求。
    6. 這次，後端伺服器將 FIN, ACK 傳回訊息處理器 (封包 6285) 啟動連線關閉作業。

    在此範例中，系統成功重複使用同一個連線兩次，但在第三次要求中 後端伺服器會啟動連接，訊息處理器則會 等待來自後端伺服器的資料這表示後端伺服器 逾時時間最可能短或等於 API Proxy 中設定的值。進行驗證 請參閱「比較 Apigee 和後端伺服器的保持運作逾時」。

比較 Apigee 和後端伺服器的保持運作逾時

  1. 根據預設，Apigee 的保持運作逾時屬性值會是 60 秒。

  2. 不過，您可能已覆寫 API Proxy 的預設值。 您可以檢查 TargetEndpoint API Proxy 執行失敗，導致發生 502 錯誤。

    TargetEndpoint 設定範例： 

    <TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>https://mocktarget.apigee.net/json</URL>
    <Properties>
      <Property name="keepalive.timeout.millis">30000</Property>
    </Properties>
  </HTTPTargetConnection>
</TargetEndpoint>

    在上述範例中，保持運作逾時屬性以 30 秒 (30000 毫秒) 的值覆寫。

  3. 接著，檢查後端伺服器上設定的保持運作逾時屬性。假設 您的後端伺服器設為 25 seconds 值
  4. 如果您確定 Apigee 的保持運作逾時屬性值值較高 保持後端伺服器保持運作逾時屬性值，如上所示 那麼這是 502 錯誤的原因。

解析度

確保 Apigee 的保持運作逾時屬性一律較低 (在 API Proxy 中， 訊息處理器元件) 與後端伺服器上的訊息處理器元件進行比較。

  1. 請決定後端伺服器上保持有效逾時的設定值。
  2. 為 API Proxy 中的保持運作逾時屬性設定適當的值，或是 訊息處理器，例如，保持運作逾時屬性值低於 偵測執行個體 設定訊息處理器保持運作逾時。

如果問題仍未解決，請前往 必須收集診斷資訊。

最佳做法

強烈建議您，下游元件的存留時間一律較短 門檻值，避免發生這類競爭狀況， 502 個錯誤。每個下游躍點均應低於每個上游躍點。在 Apigee 中 Edge，建議您使用下列指南：

  1. 用戶端保持運作逾時時間應小於邊緣路由器保持運作逾時的時間。
  2. Edge Router 保持運作逾時應小於訊息處理器保持運作逾時的時間。
  3. 訊息處理器保持上線逾時應小於目標伺服器保持上線逾時。
  4. 如果您在 Apigee 的前面或後面有其他躍點，則應套用相同的規則。 請一律保留此通知，因為下游用戶端會自行關閉 才能與上游連線

必須收集診斷資訊

如果按照上述說明操作後仍無法解決問題，請收集下列資訊 ，然後與 Apigee Edge 支援團隊聯絡。

如果您是公有雲使用者，請提供下列資訊：

  • 機構名稱
  • 環境名稱
  • API Proxy 名稱
  • 完成 curl 指令來重現 502 錯誤
  • 含有 502 Bad Gateway - Unexpected EOF 錯誤要求的追蹤檔
  • 如果目前沒有發生 502 錯誤，請提供時間範圍 顯示過去 502 個錯誤發生的時區資訊。

如果您是 Private Cloud 使用者，請提供下列資訊：

  • 偵測到失敗要求的完整錯誤訊息
  • 要觀察的機構、環境名稱和 API Proxy 名稱 502 個錯誤
  • API Proxy 套裝組合
  • 含有 502 Bad Gateway - Unexpected EOF 錯誤要求的追蹤檔
  • NGINX 存取記錄
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  • 訊息處理器記錄
    /opt/apigee/var/log/edge-message-processor/logs/system.log
  • 含有時區資訊發生 502 錯誤的時間範圍
  • 在訊息處理器或後端伺服器上收集的 Tcpdumps，或是在發生錯誤時收集 發生