跳轉到主要內容
你寫了一個防火牆政策——一個 default-deny 姿態、一個對 shell.exec 的 deny、一個 egress 允許清單——而你相信它是對的。但 對照生產代理流量將它切換為開啟是一場信心的跳躍：一條過於寬泛的 規則，你就會封鎖你的代理正當發出的呼叫。 防火牆影子模式是那個安全推出開關。它是一個每政策的旗標，告訴 閘道完全像在生產環境中那樣評估該政策、記錄一切，但封鎖無物。 每個強制執行的裁決都會被降級為 audit，而事件原因會被加上前綴 [shadow] would …，所以你能精確地讀出該政策會做什麼——而它尚未 做任何事。
影子模式是政策上的一個旗標，在主控台中設定（或 /api/workspace/firewall/policies 管理路由，後者使用你的工作階段／ 存取權杖——而非中繼 sk-orca-… 金鑰）。切換它是一項 Developer+ 動作。你代理的 /v1/* 中繼呼叫不變。

​
1. 防火牆影子模式做什麼

當一個政策的 shadow_mode 旗標開啟時，閘道會執行完整的評估—— 解析政策、按優先順序走訪規則、挑選一個裁決——然後，就在該裁決 生效之前，降級任何會改變呼叫的東西：
解析後的裁決在影子模式下
deny→ audit，原因 [shadow] would deny — …
sanitize→ audit，原因 [shadow] would sanitize — …
pending_approval→ audit，原因 [shadow] would pending_approval — …
allow / audit不變（已經是非封鎖的）
呼叫總是會通過。沒有東西被封鎖、沒有引數被遮罩、沒有人工保留被 開啟——但事件會以該政策會產生的裁決被記錄，所以 事件動態讀起來就像一次關閉了 強制執行的生產執行。
[shadow] would … 前綴是你的頭號篩選條件。按它對事件動態排序， 你就有了這個政策即將開始封鎖的每一次呼叫的完整清單，就在它封鎖 任何一次之前。

​
2. 一次具體的推出

假設你有一個政策 prod-agents，帶有一條對破壞性 shell 指令的 deny 規則，而你想確認它不會在任何正當的東西上絆倒。
1

開啟影子模式

在 Security → Firewall → Policies 中開啟 prod-agents，將 Shadow mode 切換為開啟並儲存。政策保留它的綁定與它的規則 ——它只是停止強制執行。
2

讓真實流量流動

你的代理像以前一樣繼續呼叫閘道。每一次工具呼叫都會被評估；沒有 東西被封鎖。給它一個有代表性的窗口——長到足以涵蓋你真實的 工具組合。
3

讀取會發生的拒絕

開啟 Events 並按 [shadow] 原因篩選。每一列都顯示工具、介面、執行，以及匹配到的規則——所以 在一個 shell.exec 呼叫上的 [shadow] would deny — destructive shell command 正是你在生產環境中會看見的，只少了那個 HTTP 400。
4

關閉影子模式

一旦動態顯示政策在你預期的事物上觸發、在你不預期的事物上不 觸發，就將 Shadow mode 切換為關閉。從下一次呼叫起，那些 [shadow] would deny 事件會變成真實的 firewall_blocked 拒絕。
如果影子模式確實浮現出一個誤報——一個匹配到某 deny 規則的正當 呼叫——就在仍處於影子狀態時修正該規則（收緊 glob或加入一個 引數子句），然後再次 觀察動態。你能以零波及範圍對照真實流量反覆迭代。

​
3. 影子模式不會軟化什麼

影子模式是政策的一個預覽，而不是一個總開關。
受治理的技能在一個影子政策下仍會強制執行。 一個處於 block 模式的技能仍會拒絕，而一個處於 quarantine 模式的技能仍會保留待審批，即使匹配到的政策被影子化。 技能強制執行模式是技能的審查狀態的屬性，而不是你正在預覽的政策 的屬性——影子化一個政策從來不是解除隔離一個技能的請求。政策在 事件中仍會被標記為已影子化，但技能的處置勝出。
幾個值得知道的額外邊界：
只有強制執行的裁決（deny、sanitize、pending_approval）會被 降級。一個 allow 或 audit 已經讓呼叫通過，所以沒有東西可 軟化——那些事件仍會攜帶影子標記，所以你能分辨它們被記錄時政策 處於影子狀態。
一條 cap_cost 規則會根據該 執行的累計花費解析為一個具體的 allow 或 deny，而那個解析後 的裁決才是影子模式接著降級的對象——一個會發生的觸頂拒絕就像 其他任何裁決一樣顯示為 [shadow] would deny。
影子模式獨立地存在於每個政策上。你可以影子化一個全新政策，同時 一個身經百戰的政策繼續強制執行——沒有一個工作區範圍的影子開關 會讓你忘了關掉。

​
4. 影子模式 vs. 其他推出旋鈕

防火牆給你三個不同的「先別弄壞任何東西」控制項。它們解決不同的 問題：
控制項範圍它回答的問題
影子模式一個政策「如果我強制執行這個政策，它會封鎖什麼？」
audit 預設裁決一個政策「記錄沒有規則指名的一切，封鎖無物。」
觀察模式工作區「哪些工具正在執行而沒有政策涵蓋它們？」
當你有一個真實、強制執行的政策，並想在它改變流量之前衡量它的確切 影響時，影子模式就是要去拿的那一個。一個 預設裁決 audit 是針對一個政策未匹配的尾端；觀察模式則是關於跨工作區的 涵蓋缺口，而不是某個特定政策的強制執行。
你可以將它們堆疊。一個影子模式下的新 default-deny 政策是可能最 溫和的推出：即使是 default-deny 底線也只記錄 [shadow] would deny 而不封鎖，所以你能在 deny 上線之前看見你的 allow 規則尚未涵蓋的 完整呼叫集合。

​
5. 合規包先落入影子

當你以觀察（非強制執行）模式 安裝一個合規包時，它具體化的 防火牆政策會以影子模式開啟的方式建立——它們會對照你的流量評估 並記錄而不封鎖任何東西。將該包晉升為強制執行會把那些政策切出 影子。同一個機制，為你套用：乾跑控制項、讀取會發生的裁決，然後 強制執行。

​
6. 切換它

在主控台中，影子模式是政策編輯器上的一個切換開關。同一個旗標在 管理 API 上以政策物件上的 shadow_mode 公開——這些路由使用你的 工作階段／存取權杖並需要 Developer+：
方法與路徑角色備註
PUT /api/workspace/firewall/policiesDeveloper+在主體中對政策設定 shadow_mode: true / false。
GET /api/workspace/firewall/policies/:idMember讀取一個政策目前的 shadow_mode 狀態。
每一次變更都會寫入一筆稽核列 並使政策的 version 整數遞增，所以開啟與關閉影子本身就被追蹤。

​
接下來去哪裡

建立與綁定政策

影子模式推出的兩步設定——建立政策、綁定一個金鑰。

事件記錄

[shadow] would … 出現的地方——篩選、鑽入執行與規則。

裁決

影子模式降級的強制執行裁決，以及每一個在即時下做什麼。

強制執行模式

影子、audit 與 observe 如何契合更廣的強制執行模型。
要了解一旦你關閉影子後一個政策會阻止的威脅，參見 危險的工具呼叫與 過度代理權。