499 用戶端已中斷連線

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

問題

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

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

錯誤訊息

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

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

用戶端逾時的原因為何？

Edge 平台上 API 要求的一般路徑為 客戶 >路由器 >訊息處理器 >後端伺服器，如下圖所示：

Apigee Edge 平台中的路由器和訊息處理器已設定合適的 預設的逾時值，以確保 API 要求不會花太多時間完成。

用戶端逾時

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

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

路由器發生逾時

路由器上的預設逾時時間為 57 秒。這是指系統最多可在 201 天內 從收到 API 要求到 Edge 的回應為止，API Proxy 可以執行，直到回應 ，包括後端回應和執行的所有政策。預設 路由器和虛擬主機可覆寫逾時，詳情請參閱 設定路由器的 I/O 逾時。

訊息處理器逾時

「訊息處理器」的預設逾時時間為 55 秒。這是 後端伺服器處理要求並回應訊息 處理器。您可以在訊息處理器或 API 中覆寫預設逾時時間 Proxy 範例： 設定訊息處理器的 I/O 逾時。

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

可能原因

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

原因 說明 適用的疑難排解操作說明
用戶端突然關閉連線 當用戶端因使用者取消連線而關閉連線時， 這類要求。 公開與私有雲使用者
用戶端應用程式逾時 如果用戶端應用程式在 API Proxy 還有時間達成 並傳送回覆一般來說，如果用戶端逾時時間較短，就會發生這種情況 而非路由器逾時 公開與私有雲使用者

常見的診斷步驟

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

  • API 監控
  • NGINX 存取記錄

API Monitoring

如何使用 API Monitoring 診斷錯誤：

  1. 前往「Analyze」(分析) >「API 監控 >調查頁面。
  2. 請篩選出 4xx 項錯誤並選取時間範圍。
  3. 根據「時間」繪製「狀態碼」。
  4. 選取含有 499 個錯誤的儲存格，如下所示：

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

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

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

    • Request：提供用於發出呼叫的要求方法和 URI
    • Response Time (回應時間)：提供要求的總時間長度。
    ，瞭解如何調查及移除這項存取權。

    您也可以使用 API Monitoring 取得所有記錄檔 GET 記錄 API。適用對象 例如，您可以查詢 org、env 的記錄檔， 「timeRange」和「status」可以下載所有 則用於記錄用戶端逾時的交易。

    由於 API Monitoring 會將 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 錯誤，並確認是否 在所有管道中，回應時間 (假設為 30 秒) 一致 499 個錯誤。

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. 檢查「Total Response Time」和「User Agent」是否一致 在所有 499 個錯誤中

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

診斷

  1. 當在瀏覽器或行動應用程式中執行的單一頁面應用程式呼叫 API 時， 如果使用者突然關閉瀏覽器、進行瀏覽，瀏覽器就會取消要求。 在相同分頁中的其他網頁，或是點擊或輕觸停止載入頁面 停止載入。
  2. 如果發生這種情況，具有 HTTP 499 狀態的交易通常會有所差異 個別請求的處理時間 (回應時間)。
  3. 您可以比較回應時間並確認是否 使用 API 監控功能或 NGINX 存取 (NGINX 存取權) 的每個 499 錯誤皆不同 記錄，如同「常見診斷步驟」一文所述。

解析度

  1. 此為正常現象，通常不是因為 HTTP 499 錯誤所致 而且數量不多

  2. 如果該網址經常出現在相同網址路徑中，可能是因為特定 Proxy 這類路徑的執行速度非常慢，使用者也不想等待。

    知道可能受到影響的 Proxy 後，請使用 延遲 分析資訊主頁，進一步調查造成 Proxy 延遲的原因。

    1. 在這種情況下，請使用 常見的診斷步驟。
    2. 使用 延遲時間分析資訊主頁，深入調查造成 Proxy 延遲及 修正問題。
    3. 如果您發現特定 Proxy 會發生延遲狀況，那麼 請通知使用者，這個 Proxy 需要一段時間才能回應。

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

這可能會在多種情況下發生。

  1. 要求預計需要一段時間才能完成 (如 10 秒) 在正常運作的情況下。不過，用戶端應用程式的設定 逾時值 (假設為 5 秒)，導致用戶端應用程式在 API 要求在完成之後，就會到達 499。在這個範例中，我們需要將 用戶端逾時。
  2. 目標伺服器或呼叫花費的時間超出預期。在這種情況下，您必須修正網站的 並適當調整逾時值。
  3. 「用戶端」不再需要回應，因此已中止。這種情況如果 例如自動完成或簡短輪詢

診斷

API Monitoring 或 NGINX 存取記錄檔

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

  1. 按照下列說明，查看 HTTP 499 交易的 API Monitoring 記錄檔或 NGINX 存取記錄： 常見的診斷步驟。
  2. 確認所有 499 錯誤的回應時間是否一致。
  3. 如果是，可能是因為特定用戶端應用程式已設定固定逾時 。如果 API Proxy 或目標伺服器回應速度緩慢，用戶端會逾時 因此造成大量 HTTP 499s 同一個 URI 路徑在這種情況下，請從 NGINX 存取記錄檔找出「使用者代理程式」， 可以協助您判斷特定的用戶端應用程式。
  4. 也可能是 Akamai 等 Apigee 的前台 F5、AWS ELB 等。如果 Apigee 在自訂負載平衡器後方執行，則要求 負載平衡器的逾時時間必須設為高於 Apigee API 逾時時間。變更者： Apigee 路由器預設會在 57 秒後逾時，因此適合設定要求 負載平衡器的逾時時間限制為 60 秒。

Trace

使用 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)