摘要： Cloudflare 在 2026 年 8 月 14 日讓 Cloudflare Access 可直接套用到單一 Worker 或整個帳戶的 Worker，涵蓋自訂網域、路由、workers.dev 子網域與預覽 URL。應用程式碼執行前會先完成驗證，已驗證身份可透過 ctx.access 取得。帳戶層級預設可讓內部應用預設私有，必要時再對單一 Worker 繞過。
內部工具上線速度太快，安全常跟不上
AI 已經讓各部門的員工都能親手把應用做出來，但這股速度同時帶來一個風險：只要有人把東西部署到公開網路上，內部的作品或公司資料就可能意外曝光。Cloudflare 在 2026 年 8 月 14 日發布了新功能，讓託管在 Workers 上的應用更容易維持私密。現在你可以把 Cloudflare Access 直接套用在單一 Worker，或套用在整個帳戶，應用預設就位於公司登入之後，不必依賴每位開發者自行設定。
保護對象從主機名稱換成 Worker
以前 Access 政策是架在主機名稱這一層的。Worker 只要能從某個網域連上，你就得為那個網域各自建立政策；日後新增自訂網域時，若沒有先更新政策，該網域就會在毫無驗證的情況下對外公開。現在政策改為跟著 Worker 本身走，凡是與該 Worker 相關的網域或 URL 都自動納入保護。範圍可以自己挑：只守住預覽 URL，或守住所有主機名稱。選預覽的話，每次部署新版本時，workers.dev 預覽網址或自訂預覽網域都會要求先通過認證；選全部的話，自訂網域、路由、workers.dev 子網域和預覽 URL 全部涵蓋在內。
帳戶層級設一次，私有成為預設
組織裡若有很多開發者都在部署 Workers，就不該把成敗押在每個人是否記得開啟 Access。現在可以在帳戶層級設定一次 Access 政策，此後帳戶內現有與未來新增的每個 Worker，從建立的那一刻起就是私密的。政策涵蓋的範圍有三種選擇：只包括預覽流量、包括所有正式流量，或兩者都包括。當正式的 Worker 本來就刻意公開、只是不想讓進行中的部署被看見時，預覽限定就很合適。若某個 Worker 需要公開，可以在該 Worker 上繞過帳戶政策。
身份直接送進程式碼，JWT 驗證交給平台
Access 為 Worker 把關時，每個請求都會附上已驗證使用者的 email、姓名和群組，你可以用這些資訊來個人化內容、強制權限或記錄活動。這套機制透過 Worker 的 context 物件（ctx）運作。Access 啟用之後，系統會把身份附加在 ctx.access 上，只要呼叫 ctx.access.getIdentity() 就能取得使用者資訊。以往你得自行解析 JWT、驗證簽章再擷取 claims，現在這些步驟全都不必了。在 Worker 中取得身份的完整寫法如下：
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access required", { status: 403 });
}
const identity = await ctx.access.getIdentity();
const email = identity?.email ?? "unknown";
return new Response(`Hello, ${email}`);
}
};在本機開發時，可以在 wrangler.jsonc 加入 access 區塊來模擬一位已驗證使用者，這樣 ctx.access.getIdentity() 回傳的身份物件會和正式環境相似。把 email 換掉，就能改用不同使用者身份測試，不必每次部署完再透過 Access 登入。access 區塊的設定方式如下：
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@company.com" }
}
}
}內部平台：往後每個部署都預設私有
如果你負責的內部平台要讓員工打樣並部署應用，你會需要每個應用都私有，卻不想逐一設定。Workers for Platforms 能大規模部署 Workers，所有流量都必須經過單一入口，也就是 dispatch Worker。只要在這個 dispatch Worker 上設定 Access 政策，透過它部署出去的每個 Worker 就預設私有。Cloudflare 也開源了一個範例，讓你可以部署自己的內部拖放式平台：在 dispatcher worker 設定一次 access，之後每個站台都預設私有。
背後是 FL2，把路由與執行拆開
這項功能是靠 FL2 撐起來的，也就是 Cloudflare 邊緣網路全新的 Rust 模組化代理。傳統上，Access 在請求管線中的執行位置早於所有 Workers 邏輯。然而要讓 Access 針對個別 Worker 而不是主機名稱，系統必須先知道請求要送往哪個 Worker。這就要求把 Workers 路由從執行中拆離，並將路由邏輯移到 Access 之前。若換成舊的 FL1 系統（以 NGINX 和 Lua 模組為基礎），這種改動既複雜又有風險。FL2 嚴格的模組系統把邏輯切分成定義良好、順序一致的階段，並靜態宣告各階段的輸入與輸出，讓編譯器能找出階段之間的破壞性互動，也讓重構可以逐步、安全地推出。
現在就能開始用
這項功能目前已對所有人開放。你可以在儀表板中試用，或參考 Cloudflare Access for Workers 文件。設定好帳戶層級政策之後，所有新的 Worker 都會自動受到保護；需要公開時，再針對單一 Worker 繞過即可。查看 Worker 的 Access 分頁，就能看到哪些政策正在套用，優先順序依序是主機名稱政策、Worker 政策、帳戶政策。
對產品建構者來說，這表示內部工具能更快上線，同時把安全負擔從個別開發者轉移到平台層級。預設私有再加上直接取得身份，不僅減少了設定摩擦，也讓稽核與個人化變得更容易。