子網域進階驗證

子網域進階驗證可為已開啟 要求登入 的 HTTP / HTTPS 服務 Host 加上條件式放行規則。請求第一次命中規則時，目前請求會先取得單次放行，系統並向支援 Cookie 的用戶端回傳短期能力探測；只有後續請求帶回探測值後，才會建立僅限目前 Host 的持久臨時憑據。若未命中，則仍依一般登入、工作階段與服務範圍處理。

臨時憑據不等同於系統登入：它不會建立登入工作階段或 IP 授權、不會顯示傳送門，也無法存取其他 Host。進階驗證是一條獨立的放行路徑，並不是在既有登入規則上再疊加一道驗證。

適用條件

• 映射項目是一般服務 Host，而不是身分驗證服務。
• Target 使用 HTTP 或 HTTPS。
• 映射已開啟 要求登入。
• 規則使用來源 IP 或地區時，閘道能正確識別真實用戶端 IP。

請在 子網域映射 清單中開啟服務 Host 右側選單，選擇 進階驗證設定。身分驗證 Host、公開映射以及 TCP / UDP 映射不會顯示此選項。

臨時憑據的範圍

支援 Cookie 的用戶端完成探測並取得持久臨時憑據後，只要仍在有效期內，存取目前 Host 的其他路徑或使用其他請求方法時，都不必每次重新符合原始條件。因此，路徑、Header 或 Query 條件不能當成持續、逐請求的存取控制。

不會回傳 Cookie 的 App、Script 與其他用戶端不會建立持久狀態；每次請求都必須重新命中規則，且只會取得該次請求的放行。WebSocket Upgrade 也只會按目前 Handshake 單次放行，因為 101 Switching Protocols 無法可靠下發 Cookie；連線中斷後重新連線時會再次比對。請求記錄中的 單次請求放行 可用來辨識此狀態。

例如，規則只比對 /health，並不代表持久憑據只開放 /health；瀏覽器完成探測後，在臨時憑據有效期間，整個目前 Host 都會放行。若只需要開放少數固定路徑，請使用路徑回應、拆分成獨立 Host，或繼續由上游應用程式執行權限檢查。

通用封鎖清單、WAF 與舊版嚴格允許清單等防護性拒絕規則仍具有較高優先順序。進階驗證不能用來繞過這些安全邊界。

設定有效時間

設定	預設值	可用範圍	行為
多久未存取後失效	24 小時	5 分鐘～30 天	每次有效存取後重新計算閒置時間
憑據最長可使用多久	30 天	5 分鐘～365 天	從首次簽發起算，不會因持續存取而延長

這兩個時間只會限制通過 Cookie 探測後建立的持久臨時憑據；單次請求放行不會延續至下一次請求。最長使用時間不可短於閒置失效時間。修改規則、有效時間或啟用狀態並儲存後，系統會輪替原則版本，既有臨時憑據會立即失效；停用進階驗證時則會保留規則草稿，方便日後重新啟用。

編排規則組

規則採用「組間 OR、組內 AND」：

規則組 1：條件 A AND 條件 B
       OR
規則組 2：條件 C AND 條件 D

命中任一完整規則組即可簽發憑據。每個 Host 最多可設定 16 個規則組，每組最多 16 個條件；啟用時至少要有一個非空的規則組。

下列涵蓋範圍較廣的規則，在儲存時會要求再次確認：

• 整組都使用「不等於」「不屬於」等否定條件；
• 只依 HTTP 方法放行；
• 路徑規則涵蓋根路徑 /；
• 來源網路包含 0.0.0.0/0 或 ::/0。

再次確認只是在提醒規則涵蓋範圍較大，不代表此設定已經安全。儲存後，應立即分別從符合與不符合條件的外部網路進行驗證。

規模與簽發速率限制

單一 Host 的規則另有以下硬性限制：

項目	上限
每個條件的比對值或地區選項	256 項
所有條件的比對值合計	4096 項
規則運算式合計	256 個
單一規則運算式	512 Bytes
地區與網路條件解析後的 CIDR 合計	100000 條
進階驗證設定請求	8 MiB

持久臨時憑據只會在用戶端帶回有效探測值，且目前沒有可重複使用的憑據時建立。同一 Host、同一用戶端 IP 每 60 秒最多可建立 10 個；單一 Host 的總建立量限制為每 60 秒 1000 個，且最多保留 100000 個有效憑據。若達到建立速率或容量上限，或持久儲存暫時無法使用，已命中規則的目前請求會降級為 單次請求放行，不會因無法持久化而改為拒絕；下一次請求仍須重新命中規則。共用 Proxy 出口會讓多個用戶端被計入同一來源，因此使用前置 Proxy 時，務必先確認真實用戶端 IP 能被正確識別。

比對目標

目標	可用的比對方式	設定重點
來源 IP	等於、不等於、屬於 CIDR、不屬於 CIDR	支援 IPv4 與 IPv6；每行一個位址或網段
來源地區	屬於地區、不屬於地區	選擇省、市、全省或電信業者範圍，儲存時解析為固定 CIDR
URL 路徑	等於、不等於、前綴、非前綴、包含、不包含、RE2 規則運算式、非規則運算式	比對請求路徑，不包含網域
請求 Header	存在、不存在、等於、不等於、包含、開頭、結尾及其對應否定、RE2 規則運算式	從常用名稱中選擇或直接輸入自訂 Header；比對值預設區分大小寫
Query 參數	存在、不存在、等於、不等於、包含、開頭、結尾及其對應否定、RE2 規則運算式	參數和值會納入設定備份
HTTP 方法	方法屬於集合、方法不屬於集合	每行一個方法，例如 GET、HEAD

條件允許填入多個比對值時，正向條件只要命中任一值即可；否定條件則要求請求值與所有設定值都不相符。例如，兩個 不等於 值並不是「只要不同於其中一個就放行」，而是必須同時不同於兩者。

地區範圍會在儲存時展開並固化為 CIDR。日後 CIDR 資料來源有所變動，已儲存的規則不會自動擴大或縮小；只有重新開啟並儲存設定，才會使用目前的地區資料重新編譯。

Header 名稱不得使用 Host、Cookie、Authorization、X-Forwarded-*、X-Real-IP、X-Reauth-* 等與憑據、轉送或用戶端 IP 有關的 Header。使用前置 Proxy 時，也應由 Proxy 移除或改寫外部用戶端可偽造的 Header。

Header、Query 與路徑比對內容會以明文保存在設定與備份中，但系統不會將這些設定值當作進階驗證的診斷內容寫入 Log、Metrics 或錯誤詳細資訊；請求記錄只會記下命中的規則組 ID 與臨時憑據狀態，不會回顯設定值。請勿將可長期使用的高價值金鑰直接放進 Query；匯出的備份也應視為敏感檔案妥善保存。

規則範例

若要讓可信任辦公網路中的受管裝置直接進入 nas.example.com，可在同一規則組中設定：

1. 來源 IP → 屬於 CIDR → 203.0.113.0/24。
2. 請求 Header → 等於 → X-Device-ID → 裝置識別碼。

只有兩個條件都符合時，才會簽發目前 Host 的臨時憑據。Header 本身可由用戶端自行建構，因此脫離可信任來源網路後，不能單獨當成高強度身分憑據；上游服務仍應保留自身的權限控管。

驗證與疑難排解

1. 從真實外部網路送出一筆符合規則的請求。
2. 在 請求記錄 中確認身分驗證結果為 子網域規則放行。
3. 檢查 子網域規則組 ID 是否為預期的規則組，並確認 臨時憑據狀態 為 單次請求放行、已簽發、已續期 或 已重複使用。瀏覽器首次請求通常先是單次放行，帶回探測 Cookie 後才會顯示已簽發。
4. 再從不符合條件的來源進行測試，確認請求會回到一般登入流程。
5. 使用不會儲存 Cookie 的用戶端連續請求兩次，確認每次都重新比對並顯示單次請求放行；再用瀏覽器確認探測值可換成持久憑據。
6. 修改規則並儲存，確認舊瀏覽器中的臨時憑據會立即失效。

若來源 IP 或地區規則異常，請先檢查 Log 中的用戶端 IP 與連線來源 IP。若規則無法儲存，請檢查條件值、CIDR 位址家族、RE2 規則運算式、地區資料來源與閘道版本是否相容。

• 子網域映射
• 身分驗證、工作階段與服務範圍
• 安全邊界與基準設定
• 請求記錄