499 用戶端已中斷連線

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊

問題

用戶端應用程式收到 API 要求的逾時錯誤，或要求在 Apigee 上執行時突然終止。

您會在 API Monitoring 中觀察此類 API 要求的狀態碼 499，以及 NGINX 存取記錄。有時候，您會在 API 數據分析中看到不同的狀態碼，這是因為訊息處理器傳回的狀態碼。

錯誤訊息

用戶端應用程式可能會看到以下錯誤： 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

用戶端逾時的原因是什麼？

在 Edge 平台上，API 要求的一般路徑為「Client」>「 Router」>「Message Processor」>「Backend Server」，如下圖所示：

Apigee Edge 平台中的路由器和訊息處理器都設定了合適的預設逾時值，確保 API 要求完成時間不會過長。

用戶端逾時

用戶端應用程式可根據需求設定合適的逾時值。

網路瀏覽器和行動應用程式等用戶端都有作業系統定義的逾時。

路由器逾時

路由器上的預設逾時時間為 57 秒。這是指從 Edge 收到 API 要求到傳回回應 (包括後端回應和執行的所有政策) 起，API Proxy 可執行的時間長度上限。您可以按照 設定路由器的 I/O 逾時一文的說明，覆寫路由器和虛擬主機上的預設逾時設定。

訊息處理器發生逾時

「訊息處理器」的預設逾時時間是 55 秒。這是後端伺服器處理要求並回應訊息處理器所需的時間上限。您可以在訊息處理器或 API Proxy 中覆寫預設逾時設定，詳情請參閱 設定訊息處理器的 I/O 逾時設定。

如果用戶端在 API Proxy 逾時之前關閉與路由器的連線，您會看到特定 API 要求的逾時錯誤。系統會在路由器中記錄這類要求的狀態碼 499 Client Closed Connection，詳情請參閱 API 監控和 NGINX 存取記錄檔。

可能原因

在 Edge 中，499 Client Closed Connection 錯誤的常見原因為：

原因 說明 適用的疑難排解指示
用戶端突然關閉連線 這可能是因為用戶端在要求完成前因使用者取消要求而關閉連線。 公有雲與私有雲使用者
用戶端應用程式逾時 如果用戶端應用程式在 API Proxy 有時間處理及傳送回應之前逾時，就會發生這種情形。通常發生於用戶端逾時小於路由器逾時的情況。 公有雲與私有雲使用者

常見診斷步驟

請使用下列其中一種工具/技巧診斷這項錯誤：

  • API 監控
  • NGINX 存取記錄檔

API Monitoring

如何使用 API Monitoring 診斷錯誤：

  1. 前往「分析」>「API 監控」>「調查」頁面。
  2. 請篩選 4xx 個錯誤，並選取時間範圍。
  3. 依據「Time」繪製「Status Code」。
  4. 選取含有 499 錯誤的儲存格，如下所示：

  5. 右側窗格會顯示 499 錯誤的相關資訊，如下所示：

  6. 按一下右側窗格中的「查看記錄檔」。

    在「Traffic Logs」視窗中，記下部分 499 錯誤的詳細資料：

    • 要求：提供用來發出呼叫的要求方法和 URI
    • 回應 時間：這項資訊會提供要求所經過的總時間。

    另外，您也可以使用 API Monitoring GET logs API 取得所有記錄。例如，藉由查詢 org、env、timeRange 和 status 的記錄，您就可以下載用戶端逾時交易的所有記錄檔。

    由於 API Monitoring 會針對 HTTP 499 錯誤將 Proxy 設為 -，因此您可以使用 API (記錄 API) 取得虛擬主機與路徑相關聯的 Proxy。

    例如：

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. 檢查「回應時間」中是否有其他 499 錯誤，然後確認所有 499 錯誤的「回應時間」是否一致 (假設為 30 秒)。

NGINX 存取記錄檔

如何使用 NGINX 存取記錄檔診斷錯誤：

  1. 如果您是 Private Cloud 使用者，即可使用 NGINX 存取記錄檔來判斷 HTTP 499 錯誤的相關重要資訊。
  2. 查看 NGINX 存取記錄檔：
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. 搜尋特定時間範圍內是否有任何 499 錯誤 (如果問題過去發生)，或是否有任何要求仍失敗並顯示 499。
  4. 關於部分 499 錯誤，請注意下列資訊：
    • 總回應時間
    • 請求 URI
    • 使用者代理程式

    範例 499 錯誤 NGINX 存取記錄：

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    在這個範例中，您會看到以下資訊：

    • 總回應時間： 10.001 秒。這表示用戶端在 10.001 秒後逾時
    • 要求： GET /v1/products
    • 主機：api.acme.org
    • 使用者代理程式：okhttp/3.9.1
  5. 確認所有 499 錯誤中「總回應時間」和「使用者代理程式」是否一致。

原因：用戶端突然關閉連線

診斷

  1. 從瀏覽器或行動應用程式中執行的單一頁面應用程式呼叫 API 時，如果使用者突然關閉瀏覽器、前往同一個分頁的其他網頁，或是點選或輕觸 「停止載入」停止載入網頁，瀏覽器就會取消要求。
  2. 如果發生這種情況，以 HTTP 499 狀態的交易通常會依要求處理時間 (回應時間) 而異。
  3. 如要判斷原因是否為原因，您可以比較回應時間，並使用 API 監控功能或 NGINX 存取記錄檔，確認每個 499 錯誤是否有此錯誤，相關說明請參閱常見診斷步驟。

解析度

  1. 這很正常，如果 HTTP 499 錯誤發生次數不多，通常通常不會造成問題。

  2. 如果在相同網址路徑中經常發生這種情形，可能是因為與該路徑相關聯的特定 Proxy 速度非常緩慢，使用者也就沒有意願等待。

    知道哪些 Proxy 可能受到影響後，請利用延遲時間分析資訊主頁，進一步調查導致 Proxy 延遲的原因。

    1. 在此情況下，請使用「常見診斷步驟」中的步驟找出影響的 Proxy。
    2. 使用 延遲時間分析資訊主頁來進一步調查導致 Proxy 延遲的原因，並修正問題。
    3. 如果您發現特定 Proxy 會預期延遲時間，建議您告知使用者這個 Proxy 需要一段時間才能回應。

原因：用戶端應用程式逾時

這可能發生了某些情況。

  1. 要求在一般運作情況下需要特定時間 (例如 10 秒) 才能完成。然而，用戶端應用程式設定的逾時值有誤 (例如 5 秒)，導致用戶端應用程式在 API 要求完成前逾時，進而導致 499。在這種情況下，我們必須將用戶端逾時設為適當的值。
  2. 目標伺服器或呼叫的處理時間超出預期。在這種情況下，您必須修正適當的元件，並適當調整逾時值。
  3. 用戶端不再需要回應，因此取消。這種情況可能會發生在高頻率 API，例如自動完成或短暫輪詢。

診斷

API 監控或 NGINX 存取記錄檔

使用 API 監控或 NGINX 存取記錄檔來診斷錯誤：

  1. 按照常見診斷步驟的說明，查看 HTTP 499 交易的 API 監控記錄檔或 NGINX 存取記錄檔。
  2. 判斷所有 499 錯誤的回應時間是否一致。
  3. 如果是的話，可能是因為特定用戶端應用程式設定了固定逾時。如果 API Proxy 或目標伺服器的回應速度緩慢，用戶端會在 Proxy 逾時前逾時，導致同一個 URI 路徑出現大量 HTTP 499s。在此情況下，請從 NGINX 存取記錄找出使用者代理程式，藉此判斷特定的用戶端應用程式。
  4. Apigee 前面也有負載平衡器，例如 Akamai、F5、AWS ELB 等。如果 Apigee 在自訂負載平衡器的背後執行，負載平衡器的要求逾時時間必須設為超過 Apigee API 逾時時間。根據預設，Apigee 路由器會在 57 秒後逾時，因此適合將負載平衡器的要求逾時設為 60 秒。

追蹤記錄

使用 Trace 診斷錯誤

如果問題仍未解決 (仍有 499 個錯誤)，請執行下列步驟：

  1. 在 Edge UI 中為受影響的 API 啟用追蹤記錄工作階段。
  2. 您可以等待錯誤發生，或是如果有 API 呼叫，然後發出一些 API 呼叫並重現錯誤。
  3. 檢查每個階段的經過時間，並記下大多數時間花費在哪個階段。
  4. 如果你在下列任一階段後發現經過的最長時間錯誤，表示後端伺服器處理要求的速度緩慢，或處理時間過長：
    • 要求已傳送至目標伺服器
    • 服務摘要政策

    以下 UI 追蹤記錄範例顯示在要求傳送至目標伺服器之後的「閘道逾時」：

解析度

  1. 請參閱 設定 I/O 逾時的最佳做法，瞭解透過 Apigee Edge 進行 API 要求流程中，相關元件應設定哪些逾時值。
  2. 請務必按照最佳做法，在用戶端應用程式中設定適當的逾時值。

如果問題仍未解決，請參閱「必須收集診斷資訊」。

必須收集診斷資訊

如果問題仍未解決，請收集下列診斷資訊，然後與 Apigee Edge 支援團隊聯絡。

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

  • 機構組織名稱
  • 環境名稱
  • API Proxy 名稱
  • 完成用於重現逾時錯誤的 curl 指令
  • 顯示用戶端逾時錯誤的 API 要求追蹤檔

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

  • 觀察失敗要求的完整錯誤訊息
  • 環境名稱
  • API Proxy 套裝組合
  • 顯示用戶端逾時錯誤的 API 要求追蹤檔
  • NGINX 存取記錄檔 (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • 訊息處理器系統記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)