如果您的網站需要自訂控制使用者的存取原則，您可以在自訂規則中佈建要求匹配條件，並通過攔截、觀察等方式控制匹配到的使用者請求，協助您的網站更加靈活的限制使用者可訪問的內容。
用戶端 IP 歸屬的準確性說明
使用 WAF 自訂規則結合規則引擎來攔截用戶端請求時，由於規則引擎對用戶端 IP 歸屬的「洲」、「國家 / 地區」、「省份」、「電訊廠商」資訊無法做到 100% 準確，很可能存在誤識別的情況，因此請謹慎使用。
如果出現用戶端 IP 歸屬資訊識別不準確的情況，可以使用白名單規則允許存取指定的 IP 位址，避免正常的用戶端 IP 被 WAF 誤攔截。
配置自訂規則
在ESA控制台選擇網站管理，在網站列單擊目標網站。
在左側導覽列，選擇。
單擊自訂規則頁簽，進入自訂規則頁簽，單擊新增規則。
單擊確定。
配置規則時，請注意以下事項：
User-Agent 匹配大小寫：配置 User-Agent 匹配規則時，若選擇不區分大小寫匹配模式，則匹配值需全部設定為小寫。同時，請根據實際需求確認選擇精準匹配（等於）還是模糊比對（包含），避免因匹配模式選擇不當導致規則未生效（例如狀態代碼仍返回 200）。
規則引擎能力邊界：當前 WAF 規則引擎僅支援判斷請求欄位是否包含特定字串（返回布爾值），不支援對匹配結果進行數組長度計算或計數判斷，因此無法實現"攔截 URL 中包含超過 N 個某關鍵詞"這類複雜邏輯。WAF 防護策略需基於用戶端 IP、User-Agent、Referer、URI 等請求特徵進行配置，不支援僅通過訪客 ID 等業務層標識進行攔截。
執行動作說明
攔截：表示攔截命中規則的請求，並向發起請求的用戶端返回攔截響應頁面。
說明若需要在攔截操作中自訂攔截頁面時，請參見自訂頁面。
觀察：表示不攔截命中規則的請求，只通過日誌記錄請求命中了規則。您可以通過WAF日誌，查詢命中當前規則的請求，分析規則的防護效果（例如，是否有誤攔截等）。觀察模式方便您試運行首次配置的規則，待確認規則沒有產生誤攔截後，再將規則設定為攔截模式。
說明只有開通Log Service，您才可以使用日誌查詢功能。
JS挑戰：表示ESA向用戶端返回一段正常瀏覽器可以自動執行的JavaScript代碼。如果用戶端正常執行了JavaScript代碼，則ESA在一段時間（預設30分鐘）內允許存取該用戶端的所有請求（不需要重複驗證），否則攔截請求。
滑塊挑戰：ESA向用戶端返回滑動驗證頁面。如果用戶端成功執行滑動驗證，則ESA在 30 分鐘（預設）內允許存取該用戶端的所有請求，否則攔截請求。
說明如果結果為通過（即正常使用者成功完成滑塊挑戰），則計入流量。如果結果為攔截，則免計流量。
WAF自訂規則、頻次控制規則的JS挑戰和滑塊驗證僅適用於靜態頁面。如需相容
XMLHttpRequest、Fetch等非同步介面響應，需在Bots中啟用JS挑戰和滑塊驗證。啟用後，當請求命中規則時，ESA對用戶端發起JS挑戰或滑塊驗證，當用戶端通過後將會在HTTP報文的Header中分別植入Cookie acw_sc__v2和acw_sc__v3，用於表示用戶端已通過驗證。
嚴格滑塊挑戰：嚴格滑塊驗證模式下，用戶端的每次請求都需要驗證（無滑塊挑戰的30分鐘內允許存取已通過挑戰用戶端請求的特性），請按需謹慎開啟。且嚴格滑塊挑戰僅Enterprise可申請開通使用。
自訂規則支援 JS 挑戰和滑塊驗證兩種人機驗證執行動作：
JS 挑戰：無感驗證。系統向用戶端下發 JavaScript 代碼自動完成驗證，使用者無需手動操作。
滑塊驗證：顯式驗證。使用者需完成滑動操作以通過驗證。
使用 JS 挑戰和滑塊驗證時，請注意以下限制：
JS挑戰和滑塊挑戰僅適用於靜態頁面請求，不適用於 POST 表單提交、API 介面等動態請求情境，否則可能導致表單資料丟失或重複觸發驗證。
對圖片等純資源檔啟用JS挑戰或滑塊挑戰時，可能因瀏覽器機制導致驗證失敗從而無法正常顯示資源。建議對純圖片類型網域名稱或資源路徑配置攔截動作或通過白名單允許存取，避免使用人機驗證。
JS挑戰通過後，允許存取時間長度預設為 30 分鐘，暫不支援調整。允許存取有效期間內，已通過驗證的用戶端無需再次完成人機驗證。
如需一點即過等更多驗證碼類型，可使用AI驗證碼功能，支援一點即過、滑塊、旋轉等驗證方式，在 ESA 控制台單獨配置。
圖片類業務的處置動作建議：對以圖片等純資源檔訪問為主的業務情境，本文檔前述“對純圖片類型網域名稱或資源路徑配置攔截動作或通過白名單允許存取，避免使用人機驗證”的建議仍然適用；如果確需對該類資源啟用人機驗證進行二次確認，建議優先選擇無感的JS挑戰而非需要使用者手動操作的滑塊挑戰，以降低對圖片載入體驗的影響。
配置樣本
情境：通過安全分析或事件分析中發現了IP為192.168.0.1的用戶端向主機dns.example.com發起了異常請求行為。
配置方式：
參數 | 樣本值 |
如果請求匹配以下規則... | 同時滿足：
可直接編輯使用運算式： |
則執行… | 攔截並響應預設攔截頁面 |
防護效果：符合自訂規則條件的請求將被攔截。
常見配置樣本
以下為高頻防護情境的配置參考，可根據實際需求調整。
情境 1：攔截特定爬蟲（以 Bytespider 為例）
在如果請求匹配以下規則...地區設定：匹配欄位選擇User-Agent，運算子選擇包含，值填寫 Bytespider；在執行動作地區選取項目攔截。
情境 2：限制要求方法（僅允許 GET 和 POST）
配置規則：要求方法不等於 GET 且不等於 POST 時，執行攔截動作。此情境需進階版及以上套餐支援。
情境 3：僅允許指定 IP 訪問特定子網域名稱
組合兩個匹配條件：主機名稱等於目標子網域名稱，同時用戶端 IP 不等於指定 IP，執行動作選擇攔截。
情境 4：攔截空 Referer 請求並允許存取特定直訪路徑
需配置兩條規則並設定優先權：
白名單規則（高優先順序）：當請求URI 等於需支援直訪的路徑（如首頁
/、文章頁）時，執行跳過全部規則動作。攔截規則（低優先順序）：當Referer 為空白時，執行攔截動作。
白名單規則的優先順序必須高於攔截規則，以確保正常直訪路徑不受影響。
情境 5：攔截特定 URL 路徑的異常請求
配置組合條件：URI 包含特定字串，且Referer 為空白，執行動作選擇攔截或JS 挑戰。
情境 6：攔截特定 Referer 來源網域名稱
Referer 匹配欄位配置需Pro版或更高套餐。
當您需要屏蔽特定來源網域名稱的訪問請求時，在如果請求匹配以下規則...地區設定：匹配欄位選擇Referer，運算子選擇包含，值填寫目標網域名稱（如 example.com）；在執行動作地區選取項目攔截，響應碼設為 403。
情境 7：允許微信小程式正常訪問資源
微信小程式發起的請求通常不攜帶Referer。如果您已經配置了基於Referer 為空白的攔截規則（參見情境 4、情境 5），微信小程式的正常訪問請求也會被一併誤攔。為避免此問題，建議新增一條優先順序高於該攔截規則的自訂規則：在匹配條件地區，匹配欄位選擇User Agent，運算子選擇包含，值填寫 WeChat；在執行動作地區選取項目允許存取（或跳過全部規則），使命中該條件的微信小程式請求在輪詢到低優先順序的 Referer 攔截規則之前已被允許存取。
情境 8：僅允許指定網域名稱訪問當前網站
如果您需要嚴格限制只有指定來源網域名稱才能訪問當前網站，實現跨域存取控制，可以組合主機名稱與Referer 兩個匹配條件：匹配欄位選擇主機名稱，運算子選擇等於，值填寫當前網站網域名稱（如 blog.example.com）；再新增一個匹配條件，匹配欄位選擇Referer，運算子選擇包含，值填寫允許訪問的來源網域名稱（如 api.example.com）；兩個匹配條件之間的邏輯關係選擇同時滿足。在執行動作地區選取項目攔截。配置完成後，只有主機名稱等於目標網域名稱且 Referer 包含指定來源網域名稱的請求才能正常訪問，其餘請求將被攔截。
對異常User Agent（例如版本號碼異常，如 0.0.0）配置攔截規則時，命中真實使用者的機率極低，但仍建議謹慎處理：如果擔心誤攔截，可以將執行動作由攔截調整為滑塊挑戰或JS挑戰進行二次確認，而非直接攔截。您還可以結合安全分析觀察 User Agent 分布規律與Referer 特徵，綜合判斷是否為爬蟲流量，並據此配置針對性的防護規則。
不同套餐的支援情況
功能項 | Entrance | Pro | Premium | Enterprise |
自訂規則條數 | 5條 | 20條 | 100條 | 100條 |
Entrance版套餐不支援 Ip.Geoip.Country 等資源類型匹配條件。若在自訂規則中使用該欄位，系統將報錯 Ip.Geoip.Country.NotSupport，需升級套餐方可使用地理位置相關匹配條件。
常見問題
配置 IP 相關匹配條件時，應該使用哪個欄位來防止 IP 偽造？
自訂規則的匹配欄位中，客戶端IP（ip.src）與X-Forwarded-For（http.x_forwarded_for）是兩個語義不同的獨立匹配欄位：客戶端IP 取自與 ESA 建立串連的用戶端 IP，不受用戶端要求標頭影響；X-Forwarded-For 是 HTTP 要求頭中的欄位，可以被用戶端任意偽造。因此配置基於 IP 的匹配條件（如地區限制、IP 黑白名單）時，建議優先使用客戶端IP 作為匹配欄位，避免使用X-Forwarded-For，以防止攻擊者通過偽造該要求標頭繞過攔截規則。
如果您的來源站點需要擷取用戶端真實 IP，建議在轉換規則的託管轉換中開啟添加真實用戶端 IP 要求標頭，預設會在回源請求中添加名為 ali-real-client-ip 的要求標頭（標題名稱可自訂），來源站點側讀取該要求標頭即可擷取真實用戶端 IP，而不依賴可能被偽造的 X-Forwarded-For 頭。
如果您需要避免用戶端提交的 X-Forwarded-For 頭傳遞到來源站點造成幹擾，可以在轉換規則中配置修改出站要求標頭功能，對指定要求標頭執行新增、刪除或修改操作。
為什麼配置了地區/國家攔截規則，但非目標地區 IP 仍能訪問？
如果規則中除省/地區匹配條件外，還組合了其他匹配條件（如主機名稱、URI 等），當這些組合條件與實際請求不完全一致時，整條規則不會被觸發，非目標地區的 IP 就可能正常訪問。建議檢查規則運算式中主機名稱、URI 等欄位的值是否與實際訪問的請求特徵一致，也可以先通過安全分析或事件分析查看實際流量特徵，再據此調整規則邏輯。組合條件的運算式文法可參見請求匹配規則。
為什麼基於省/地區的攔截規則會出現誤攔截或無法識別 Unknown 地區？
IP 歸屬地資訊（洲、省/地區、省份、電訊廠商）無法做到 100% 準確，且 VPN 或代理服務會改變 IP 的歸屬地顯示，導致地理位置攔截失效。
私人 IP 段（如 100.64.0.0/10）及代理 IP 可能被識別為 Unknown 地區，ESA 不支援直接攔截 Unknown 地區。
建議：
在地區限制規則中增加
User-Agent或Referer的組合條件（例如：非指定地區 AND User-Agent 不是特定值），降低單獨依賴地區判斷帶來的誤判。出現誤攔截時，可配置白名單規則允許存取正常 IP。
第三方回調（如支付寶回調）被 WAF 誤攔截，如何處理？
分析回調請求的共性特徵（例如：URI 路徑包含 /pay/notify/、特定 User-Agent 標識、固定請求方式為 POST 等），然後在自訂規則中配置白名單允許存取規則：當請求同時滿足上述特徵時，跳過全部規則動作。
若無法確定完整特徵，可先針對攻擊特徵配置攔截規則，再逐步測實驗證回調是否正常通過。
訪問出現 403 Forbidden 錯誤如何排查？
訪問返回 403 Forbidden，常見原因包括：命中了 WAF 的自訂規則攔截動作、命中了 IP 黑名單、觸發了 Referer 防盜鏈規則、或觸發了地區/國家訪問限制等存取控制策略。
排查時，建議先擷取完整的 HTTP 回應標頭資訊，回應標頭中通常會包含命中規則的相關標識，可用於定位具體觸發的規則；然後登入 ESA 控制台，在安全防護模組下逐一檢查自訂規則的匹配條件與執行動作、IP 訪問規則（黑名單）配置，以及緩衝資源相關配置，確認是哪條規則或策略導致了本次攔截。
相關文檔
規則相關的功能，在生效優先順序、可重新進入性、生效顆粒度上存在差異，詳細情況請查看規則相關功能的特性說明。