摘要： Cloudflare 在 2026 年 10 月 15 日宣布把 Cloudflare Gateway 與 DLP 和 Workers 運算平台整合，推出新的 Forward 政策動作（公開測試中）與 Custom Functions。安全政策不再只能 Allow、Block、Isolate、Log，而是可以在決策當下執行你自己寫的程式碼。對需要為自家環境客製邏輯的安全團隊來說，這改變了「自建偵測引擎 vs 接受廠商限制」的二選一困境。
老模型的問題：政策引擎只會做終端決策
Cloudflare 在公告中直接點出：市面上每一款 secure web gateway 的運作方式都一樣——流量符合條件，就觸發一個終端動作。這個模型近三十年來處理常見情境綽綽有餘，但複雜環境的客戶經常撞到天花板。
他們舉了幾個真實的痛點：一個團隊想根據身份供應商的 JWT claims 注入 HTTP header，Gateway 讀不到 JWT，只好為了這個轉換架一池 NGINX proxy，然後無限期地修補、監控、維護。另一個團隊想在員工註冊新 SaaS 服務時收到 Slack 通知，政策引擎只能 Allow 或 Block，結果繞出 Logpush 到 SIEM 再到 Slack 的管線，延遲五到十五分鐘還不保證送達。還有數十家企業客戶要求「警告頁面 + 使用者填寫理由後才放行」的功能，據說已經是最受歡迎的需求之一超過四年。
兩個進入點：Forward 動作與 Custom Functions
Cloudflare 的說法是，真正的可程式化不是有 API、Terraform provider 或 webhook 就算數，而是「在安全決策當下，於政策評估路徑中執行任意程式碼」。這次給了兩種方式：
Forward 動作：把符合條件的 HTTP 請求代理到一個 Worker。Worker 收到完整 headers 與 request body，可以修改兩者、轉發到 origin、修改回應再傳回使用者。TCP 連線、TLS 終止與再加密、憑證管理都由 Gateway 處理，Worker 只負責轉換邏輯——等於有了一個代理式的擴充點，卻不用維運傳統 HTTP proxy。Worker 也可以不做轉換，只是非同步接收完整請求脈絡，發 Slack 訊息、寫 R2、打 webhook，流量照常前往目的地。
Custom Functions：在政策評估期間內嵌呼叫 Worker，回傳一個型別化的值（字串、數字或布林）。這個值會以 selector 的形式出現在政策建構器中，用法跟內建的 Source IP 或 Content Category 一樣。合約很簡單：資料進、值出。因為它接收的是身份、裝置狀態與連線中繼資料而非完整 HTTP 請求，也能用在 Layer 4 的 Network 政策規則上。
為什麼架構決定了誰做得到
Cloudflare 強調，Gateway 和 Workers 從一開始就建在同一套基礎設施上。當 Gateway 把流量轉發到 Worker，那是一次本地函式呼叫，沒有繞回，沒有跨越網路邊界的額外延遲。獨立的 SASE 供應商如果沒有自己的運算平台，就得讓你在另一朵雲部署自動化、手動設定 webhook，接受來回延遲與拼接系統的管理成本。
這和我之前寫過的方向一致：Cloudflare 把 Web Search 放進 AI Gateway 的控制平面時，思路也是把能力移到決策點旁邊，而不是讓你在旁邊拼管線。控制平面離執行點越近，你要維護的膠水程式碼就越少。
什麼時候用哪一個
兩者的分工值得記下來：
- Custom Functions 適合快速、有界、無狀態的評估——延伸現有 selector 的結構化判斷，例如解析 JWT 回傳使用者角色，然後寫一條規則「Custom Function ‘JWT Role’ contains ‘finance_contractor’ 就 Allow」。
- Forward 動作適合需要深入轉換即時流量的場景，例如攔截敏感目的地的請求、回傳一個要求使用者填寫存取理由的插入頁，用 KV 記 session 加 TTL、用 D1 寫審計紀錄。這類 Worker 需要更謹慎的設計，避免拖慢使用者體驗。
公告也提到，隨著威脅以 AI 驅動的速度演進，安全組織需要這種靈活性來覆蓋廠商來不及做成內建功能的新威脅向量。
一個務實的下一步：Forward 動作已在所有 Zero Trust 方案的公開測試中，Custom Functions 預計年底前推出。如果你的團隊正在為了某個 header 注入或通知需求維護旁掛基礎設施，這是把它收編回政策路徑的好時機——前提是你接受 Worker 程式碼本身也成為需要審核與版本控制的安全元件。