全部產品
Search
文件中心

Edge Security Acceleration:等候室快速上手

更新時間:Dec 31, 2025

當您的網站因大促或熱門活動面臨高並發流量衝擊時,來源站點伺服器可能因不堪重負而響應緩慢甚至宕機。等候室功能通過在邊緣設定虛擬排隊地區,對超出來源站點處理能力的使用者請求進行排隊,從而保護來源站點穩定運行,並為排隊使用者提供明確的等待預期,最佳化使用者體驗。通過以下步驟您可以為您的網站快速搭建並啟用一個等候室。

快速開始:5分鐘為促銷活動配置一個基礎等候室

假設您的來源站點伺服器處理並發的能力上限為300個使用者,您需要為即將上線的促銷活動頁面 promo.example.com/flash-sale 配置等候室,以保護伺服器。

操作步驟

  1. 在ESA控制台,選擇網站管理,在網站列單擊目標網站。

  2. 在左側導覽列,選擇流量 > 等候室

  3. 等候室地區,單擊建立等候室。填寫以下核心參數:

    • 等候室名稱flash-sale-room

    • 主機名稱和路徑promo.example.com/flash-sale

      • 子域promo

      • 路徑flash-sale

    • 自訂Cookie__aliwaitingroom_flash_sale(用於表示排隊憑證)

    • 活動使用者總數300 (與您的來源站點並發能力匹配)

    • 每分鐘的新用戶數300 (確保初始階段能快速允許存取使用者)

    • 會話期間5

效果驗證

等候室建立後預設啟用。當訪問 promo.example.com/flash-sale 的並發使用者數超過活動使用者總數300時,後來的使用者將看到一個等待頁面,告知預計等待時間。

image

建立與配置等候室

如果您需要對等候室進行更精細化的控制,可參考以下完整步驟進行配置。

步驟一:進入等候室配置頁面

  1. 在ESA控制台,選擇網站管理,在網站列單擊目標網站。

  2. 在左側導覽列,選擇流量 > 等候室

  3. 等候室地區,單擊建立等候室

    image

步驟二:基礎設定

此步驟用於定義等候室的基本資料以及路徑等資訊。image

參數

說明

等候室名稱

為您的等候室設定一個易於識別的名稱,例如 promo_activity_room

主機名稱和路徑

定義等候室生效的精確URL。一個網站可包含多個主機名稱(網域名稱),此規則僅對您指定的主機名稱路徑生效。

樣本:若主機名稱為 event.example.com,路徑為 /route,則等候室僅對 event.example.com/route 的訪問請求生效。

自訂Cookie

用於標識和追蹤使用者排隊狀態的憑證。Cookie名稱首碼固定為 __aliwaitingroom_,您可以自訂尾碼部分。

樣本__aliwaitingroom_promo_user

步驟三:容量與速率配置

此步驟用於定義等候室的容量和使用者允許存取速率,是保護來源站點的核心配置。image

參數

說明

活動使用者總數

目的:設定能同時訪問您來源站點的並發使用者數上限。

說明:此值應根據您來源站點伺服器的實際並發處理能力來設定。當正在訪問來源站點的活動使用者數量達到此閾值時,新的使用者請求將被送入隊列等待。

注意:最小值為200。若來源站點實際負載低於200,建議將此值設為200,並通過每分鐘的新用戶數參數來更精確地控制允許存取速率。

每分鐘的新用戶數

目的:設定每分鐘從隊列中允許存取到來源站點的新使用者數量上限,用於控制來源站點負載的增長速度。

說明:此參數決定了隊列使用者的消化速度。例如,設定為300,則每分鐘最多有300名新使用者從等待頁面進入來源站點。

注意:最小值為200,且必須小於或等於活動使用者總數

會話期間

目的:定義使用者離開隊列後,其訪問會話的有效時間長度。

說明:使用者成功訪問來源站點後,若暫時離開(例如關閉頁面),在此參數設定的時間內再次訪問,無需重新排隊。預設值為5分鐘。

禁用會話續訂

目的:決定使用者的會話是否在與來源站點互動時自動重新整理有效期間。

注意:此開關的名稱與實際行為相反,請根據預期效果選擇:

  • 關閉 (預設):實際效果為啟用會話續訂。只要使用者在來源站點保持活動(持續發起請求),其會話就不會到期,不會被送回隊列。適用於多數情境。

  • 開啟:實際效果為禁用會話續訂。使用者的會話從首次進入來源站點時開始嚴格計時。一旦計時結束,即使使用者仍在活躍訪問,也需要重新排隊。適用於需要嚴格控制使用者單次訪問時間長度的促銷等情境。

排隊方法

目的:選擇使用者在等待頁面中的允許存取策略。

  • FIFO:按請求順序允許存取,最公平。為預設推薦選項。

  • 隨機:從隊列中隨機播放使用者允許存取。適用於對公平性要求不高的抽獎等情境。

  • 全部拒絕:所有新使用者都將進入等待頁面,且不會被允許存取。適用於活動開始前預熱、系統維護或緊急關閉入口的情境。

  • 直通:所有請求都無需排隊,直接存取來源站點。此模式下等候室相當於被禁用,可用於活動結束後恢複正常訪問或進行功能測試。

步驟四:自訂等待頁面

此步驟用於配置使用者在排隊時看到的頁面內容或API響應。image

參數

說明

等候室類型

預設等候室:系統提供的標準等待頁面,會自動顯示預計等待時間。您可以選擇預設語言模板英語簡體中文繁體中文)。

自訂等候室:允許您上傳自訂的HTML頁面。若需使用請聯絡您的銷售。

  • 您可以編輯模板或直接匯入 .html 檔案(大小不超過 50KB)。

  • 您可以在HTML中使用動態變數(如 ${waitTime})來顯示排隊資訊。

排隊預覽

單擊連結可以預覽等待頁面在不同狀態(如正在排隊全部排隊)下的顯示效果。

JSON響應

目的:為非瀏覽器用戶端(如App、小程式)提供結構化的排隊狀態資訊。

開啟此開關後,當用戶端要求標頭中包含 Accept: application/json 時,ESA將返回JSON格式的排隊資訊,而不是HTML等待頁面,具體參數請參見JSON響應參數說明:。

互動流程

  1. 首次請求:用戶端攜帶 Accept: application/json 要求標頭訪問目標URL。

  2. 擷取並儲存CookieESA的回應標頭中會包含一個 Set-Cookie 欄位。用戶端必須儲存此Cookie,作為後續請求的身份憑證。

  3. 輪詢狀態:用戶端需攜帶此Cookie,並根據響應體中 refreshIntervalSeconds 欄位指定的秒數,定時重新請求同一URL以重新整理排隊狀態。

  4. 訪問來源站點:當響應體中的 inWaitingRoom 欄位變為 false 時,表示已離開隊列,用戶端即可使用該Cookie正常訪問來源站點資源。

響應樣本

{
  "WaitingRoom": {
    "inWaitingRoom": true,
    "waitTime": 5,
    "waitTimeKnown": true,
    "waitTimeFormatted": "5 minutes",
    "queueIsFull": false,
    "queueAll": false,
    "lastUpdated": "2024-09-10T12:00:00.000Z",
    "refreshIntervalSeconds": 20
  }
}

隊列狀態代碼

自訂使用者在排隊時收到的HTTP響應狀態代碼。預設為200。您可以根據需要修改為202等其他狀態代碼。

步驟三:預覽並開啟等候室

  1. 為您展示前面兩步的設定總覽,便於您確認以及選擇是否配置其他功能,確認設定參數無誤後,單擊完成即可完成等候室的建立。

    image

  2. 等候室建立完成後,系統預設啟用等候室功能。

    image

  3. 您還可以根據實際情況開啟或關閉所有請求全部排隊的開關:

    • 關閉:預設狀態。當請求數達到活動使用者總數每分鐘的新用戶數中定義的閾值時,超出部分的請求將進入等候室排隊。

    • 開啟:所有新訪客都需要進行排隊等候,可以用於為產品發布或其他定期活動做準備。

      說明
      • 已經在您的來源站點進行訪問的活動使用者可以繼續訪問,並且在會話到期之前不會返回隊列。

      • 全部排隊將覆蓋所有其他等候室設定,包括事件設定。

    image

後續步驟

如果您是Enterprise使用者,還可以使用以下進階功能對等候室進行更靈活的控制:

  • 等候室計劃事件:在預設的特定時間自動調整等候室的容量和速率參數,以應對可預見的流量高峰或低穀。

  • 等候室繞過規則:設定特定規則(如基於IP、Header、Cookie),使滿足條件的請求可以繞過等候室,直接存取來源站點。