499 用戶端已中斷連線

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

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

您會在 API 監控和 NGINX 存取記錄檔中，觀察這類 API 要求的狀態碼 499。有時，API Analytics 會顯示不同的狀態碼，因為它顯示的是訊息處理器傳回的狀態碼。

錯誤訊息

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

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

什麼原因會導致用戶端逾時？

Edge 平台上的 API 要求通常會經過「用戶端 > 路由器 > 訊息處理器 > 後端伺服器」路徑，如下圖所示：

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

用戶端逾時

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

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

路由器逾時

路由器上設定的預設逾時時間為 57 秒。這是指 API Proxy 從 Edge 接收 API 要求到傳回回應 (包括後端回應和所有執行的政策) 所能執行的時間上限。如「 在路由器上設定 I/O 超時」一文所述，您可以在路由器和虛擬主機上覆寫預設逾時。

訊息處理器逾時

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

如果用戶端在 API Proxy 逾時前關閉與 Router 的連線，您會看到特定 API 要求的逾時錯誤。這類要求的狀態碼 499 Client Closed Connection 會記錄在路由器中，您可以在 API 監控和 NGINX 存取記錄中觀察到。

可能原因

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

原因 說明 適用於以下裝置的疑難排解說明
用戶端突然關閉連線 如果使用者在要求完成前取消要求，用戶端就會關閉連線。 公有雲和私有雲使用者
用戶端應用程式逾時 如果 API Proxy 處理及傳送回應的時間不足，導致用戶端應用程式逾時，就會發生這種情況。通常發生這種情況是因為用戶端逾時時間短於路由器逾時時間。 公有雲和私有雲使用者

常見的診斷步驟

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

  • API Monitoring
  • NGINX 存取記錄

API Monitoring

如要使用 API 監控功能診斷錯誤，請按照下列步驟操作：

  1. 依序前往「Analyze」>「API Monitoring」>「Investigate」頁面。
  2. 篩選 4xx 錯誤並選取時間範圍。
  3. 繪製「狀態碼」與「時間」的關係圖。
  4. 選取含有 499 錯誤的儲存格，如下所示：

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

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

    在「流量記錄」視窗中，記下部分 499 錯誤的下列詳細資料：

    • 要求：提供用於發出呼叫的要求方法和 URI
    • 回應 時間：顯示要求經過的總時間。

    您也可以使用 API 監控 GET 記錄 API 取得所有記錄。舉例來說，查詢 org、env、timeRange 和 status 的記錄，即可下載所有用戶端逾時的交易記錄。

    由於 API 監控會將 HTTP 499 錯誤的 Proxy 設為 -，因此您可以使用 API (Logs 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
    • 使用者代理程式

    NGINX 存取記錄檔中的 499 錯誤範例：

    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. 如「常見診斷步驟」一文所述，檢查 API 監控記錄或 NGINX 存取記錄中的 HTTP 499 交易。
  2. 判斷所有 499 錯誤的「回應時間」是否一致。
  3. 如果是，可能是特定用戶端應用程式已在自身端設定固定逾時。如果 API Proxy 或目標伺服器回應緩慢，用戶端會在 Proxy 逾時前逾時，導致相同 URI 路徑出現大量 HTTP 499s。在這種情況下，請從 NGINX 存取記錄判斷 User-Agent，這有助於判斷特定用戶端應用程式。
  4. Apigee 前方也可能設有負載平衡器，例如 Akamai、F5、AWS ELB 等。如果 Apigee 是在自訂負載平衡器後方執行，負載平衡器的要求逾時必須設定為大於 Apigee API 逾時。根據預設，Apigee Router 會在 57 秒後逾時，因此適合在負載平衡器上設定 60 秒的要求逾時。

追蹤記錄

使用 Trace 診斷錯誤

如果問題仍未解決 (499 錯誤仍持續發生)，請執行下列步驟：

  1. 在 Edge UI 中，為受影響的 API 啟用追蹤工作階段。
  2. 請等待錯誤發生，或如果您有 API 呼叫，請發出一些 API 呼叫並重現錯誤。
  3. 檢查每個階段經過的時間，並記下耗時最長的階段。
  4. 如果在下列其中一個階段後，發現錯誤的經過時間最長，表示後端伺服器速度緩慢，或處理要求需要很長時間：
    • 要求已傳送至目標伺服器
    • ServiceCallout 政策

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

解析度

  1. 請參閱「 設定 I/O 逾時的最佳做法」，瞭解應在 API 要求流程中，透過 Apigee Edge 涉及的不同元件上設定哪些逾時值。
  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)