跳轉到主要內容
當兩條規則都可能匹配同一次工具呼叫時,防火牆規則優先順序決定 哪一個勝出。一個防火牆政策是一份有序 的規則清單——引擎按優先順序走訪它們、在第一個匹配的那一個停下,並 套用它的裁決。把順序弄對,一個寬泛的守衛加上一個窄的例外就乾淨地 共存;弄錯,寬泛的規則就吞掉你意在切出的例外。 本頁是針對排序的聚焦參考。關於完整的規則文法,參見 防火牆規則;關於一條規則能產生的 裁決,參見裁決。

​
1. 順序：優先順序遞增、第一個匹配者勝出

在一個政策內,規則按 priority ASC, id ASC 順序評估：
  1. 較低的 priority 先執行。 一條 priority: 0 的規則會在一條 priority: 10 的之前被檢查。把它想成一個佇列位置,而非一個強度 分數——較小的數字先發言。
  2. 同分時以規則 id 決定。 同一 priority 的兩條規則按建立順序 （遞增的規則 id）執行,所以較舊的規則贏得同分。當順序真的重要時 使用不同的優先順序,而非倚賴 id 的同分決勝。
  3. 第一個匹配者勝出。 引擎在第一條其條件全部成立的規則停下,並 套用它的裁決。清單下方更遠的規則,對那次呼叫絕不被諮詢。
  4. 無匹配 → 預設裁決。 若無任何匹配,則套用政策的 default_verdict ——除非你改過它,否則是 audit。
一條規則只在每一個宣告的條件同時成立時才匹配: 介面、 工具名稱 glob、可選的技能 glob、可選的引數子句, 以及 egress 範圍（僅 egress 規則）。一個部分匹配即不匹配,而評估 移到下一條規則。

​
2. 一個具體範例：特定在寬泛之前

典型的排序工作是讓一個窄的 allow 在一個寬泛的 deny 中存活。 把特定的規則放在一個較低的優先順序,這樣它先被觸及： 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
一次對 shell.echo 的呼叫先擊中 Rule A（優先順序 10）、匹配,並 被允許——引擎絕不觸及 Rule B。一次對 shell.exec 的呼叫落空 A（glob 不匹配）、擊中 Rule B,並被拒絕。 翻轉優先順序,優先順序 10 上寬泛的 shell.* deny 會先捕捉 shell.echo,而你優先順序 20 上的 allow 會是死碼。拇指規則:最特定 在先、最寬泛在後。
不要為此倚賴 id 同分決勝。如果 allow 與 deny 共享同一 priority, 勝出者是你先建立的那條規則——一個脆弱的排序,如果你刪除並重新建立 一條規則它就會靜默翻轉。給特定的規則一個較低的 priority,意圖就 明確了。

​
3. 在你依賴它之前驗證順序

一旦一個政策有超過少數幾條規則,在紙上推理優先順序就容易出錯。 Test 沙盒對照一個樣本工具呼叫執行真實引擎,並告訴你不只是裁決, 而是哪條規則勝出——所以你能確認你預期的規則實際觸發了：
1

開啟政策的 Test 分頁

在主控台中,開啟該政策並切換到 Test（Developer+）。
2

提交一個樣本呼叫

輸入一個工具名稱（以及引數,如果你的規則審查它們）並執行它。不 派發、不持久化任何東西——它是一次乾跑。
3

讀取匹配到的規則

結果指名裁決、匹配到的規則（依標籤/id）與原因。如果一個 寬泛的規則在你預期一個窄的之處勝出,降低那條窄規則的 priority 並重新測試。
完整的沙盒參見測試規則,就地 編輯規則順序參見管理政策。

​
4. 技能強制執行疊加在上

規則優先順序決定勝出規則的裁決——但那不總是最終答案。如果該工具 呼叫由一個受治理的技能擁有,該 技能的強制執行模式會在第一個匹配解析之後、疊加於勝出的 裁決之上：
技能模式對勝出裁決的效果
allow不變——規則裁決成立。
quarantine把任何未達 deny 的升級為 pending_approval;一個既有的 deny 保持原樣。
block無論規則裁決為何都強制一個 deny。
所以一個 quarantine 技能能把一條規則的 allow 變成一個被保留的 呼叫,而一個 block 技能即使在沒有規則指名它的工具時也拒絕一個 呼叫。Quarantine 只升級——它絕不把一個 deny 降級為更柔和的東西。這 就是為什麼一個被自動偵測為高風險的技能會保持被隔離,直到你審查它, 無論你的規則多寬鬆。
技能模式不是一條規則,所以它沒有一個 priority,而你無法相對於你的 規則重新排序它。它總是在勝出的裁決被選出之後評估。如果一個 受治理技能的模式正封鎖你預期允許的呼叫,在技能上 修正它,而不是藉由加入一條更高優先順序的 allow 規則——規則無法覆寫 該模式。

​
5. 不走 first-match 的東西

幾個機制坐落在每規則優先順序走訪之外——知道它們落在哪裡,這樣你 不會試圖排序它們：
一條在其上限之下的 cap_cost 規則被當作不匹配,所以評估繼續到下一條規則,而不是讓它以 first-match 作為一個許可勝出。超過上限時它解析為一個 deny。它 絕不單因被觸及就短路一條較低優先順序的規則。
一條序列規則匹配一個 跨時間窗口的呼叫鏈,所以它由一個非同步匹配器被動式地強制執行, 而非在完成該鏈的那單一呼叫上。它點亮事件動態,但不為一個個別 呼叫贏得 first-match 走訪。
影子模式不改變哪條規則 勝出——它在第一個匹配解析之後,把勝出的強制執行裁決降級為 audit（原因加上前綴 [shadow] would …）,這樣你能在一個政策 改變流量之前衡量它的影響。

​
6. 把它組合起來

對任何工具呼叫,完整的解析是：
  1. 解析政策——綁定到呼叫金鑰的那個,或工作區預設值。參見 範圍。
  2. 按 priority ASC, id ASC 走訪規則——第一個匹配者勝出;無匹配 → default_verdict。
  3. 套用技能強制執行——一個受治理技能的模式疊加在勝出的裁決之上 （block 強制 deny、quarantine 升級）。
  4. 套用影子模式——若開啟,把強制執行的裁決降級為 audit。
  5. 記錄事件——裁決、介面、工具與匹配到的規則落入 事件動態。
編輯一條規則的優先順序會在綁定到該政策的每個金鑰的下一次呼叫 時生效——無需重新部署、無需代理程式碼變更。重新排序後重新執行 Test 沙盒,以在即時流量依賴它 之前確認新的勝出者。

​
接下來去哪裡

裁決

每個勝出的裁決實際做什麼。

Glob 語法

工具名稱匹配如何決定一條規則是否甚至是一個候選者。

測試規則

乾跑一個政策並看見哪條規則勝出。

工具允許清單

最倚賴排序的 default-deny 模式。
關於一條規則背後的匹配語言,參見完整的 防火牆規則參考;關於技能如何疊加 在上,參見防火牆技能與 強制執行模式。