編按:本文綜合整理自 Cloudflare 官方公告、IETF RFC 9458 Oblivious HTTP 標準、Apple Private Cloud Compute 安全指南、Cloudflare 2022 形式化驗證分析 與 Hacker News 社群討論,並加入 Siami 編輯部觀點與分析。
從 Privacy Gateway 到 OHTTP Gateway:一次遲到四年的產品線閉合
2026 年 10 月 2 日,Cloudflare 在年度 Birthday Week 期間推出 Cloudflare OHTTP Gateway 封測版。表面上這只是「再加一個 gateway 產品」,但實際意義比字面更深:它把 Cloudflare 自 2022 年起跑的 OHTTP 隱私基礎建設,從「只能當外部 relay」補完到「也能在同一供應商內部做 gateway」,讓原本被迫分裂部署的應用廠商,終於可以留在 Cloudflare 同一個網域內享用雙盲隱私。
但 Cloudflare 也順手做了一個產品命名手術:把 2022 年推出的 Privacy Gateway 改名為「Cloudflare OHTTP Relay」,把這次新出的產品稱為「OHTTP Gateway」,區隔兩者在 OHTTP 雙跳架構中扮演的不同角色。
OHTTP 之所以特別,是因為它把「保護 client IP 的角色」和「處理解密請求的角色」分給兩個互相獨立的單位——任何一方都不能同時看到「誰在連」與「連什麼內容」。
OHTTP 是什麼:為什麼 app 開發者需要「雙盲」
Oblivious HTTP（OHTTP） 是 IETF 於 2024 年 1 月正式發布的標準(RFC 9458),目標是讓應用伺服器「只看到請求內容,看不到誰送的」。它靠的是兩個獨立節點:
- Relay(中繼站):知道 client 的 IP 與 TLS 指紋,但收到的請求是加密過的,看不到內容。
- Gateway(閘道站):用 Hybrid Public Key Encryption(HPKE)解密請求,但只看到 relay 的 IP,不知道真正的 client 是誰。
兩者必須由互相不勾結的不同單位營運,否則隱私模型就破功。Cloudflare 2022 年推出 Privacy Gateway 時,正是扮演 relay 角色——但這對「應用伺服器已經放在 Cloudflare 後面」的廠商來說毫無用處,因為同一家公司不能同時當 relay 又當 origin,否則 Cloudflare 就能同時看到 client IP 與解密內容,違反 OHTTP 的隱私前提。
這次推出的 OHTTP Gateway,就是補上這塊缺:讓應用伺服器即使託管在 Cloudflare 也能享受 OHTTP 雙盲保護,只要把 gateway 也交給 Cloudflare 託管——但這條路上 Cloudflare 必須靠技術與政策防止自己「兩端通吃」,文章後段會展開。
為什麼這件事重要
OHTTP Gateway 不是「Cloudflare 又多了一個產品」這種小事,它是隱私基礎建設的「最後一塊拼圖」。
過去四年,隱私社群有兩個長期張力:第一,真正需要「不要讓 app 知道我是誰」的應用(生殖健康、秘密爆料、心理健康、政治敏感地區的 AI 推論)工程難度極高,得自己架 relay、處理 HPKE 金鑰輪替、還要找到願意營運 relay 的非勾結夥伴;第二,大型雲端商不願意提供 OHTTP-as-a-service,因為金鑰管理、流量審計、跨節點延遲都是營運地獄。
Cloudflare 這次用三招打破僵局:Anycast 部署降低延遲、自動金鑰管理、Zone 綁定防止濫用。 任何 zone 持有人只要在 Cloudflare 儀表板點幾下,就能把 https://your-zone.com/.well-known/ohttp-gateway 開成標準 OHTTP endpoint,不用自己處理金鑰、不用管容量。
這代表 OHTTP 從「學術標準」正式變成「隨選即用的基礎建設」——這是 IETF 標準落地商業產品最關鍵的一步。
從 Apple Private Cloud Compute 看 OHTTP 的真實戰場
OHTTP 並非新玩意兒。Apple 的 Private Cloud Compute 早在 2024 年 6 月就用 OHTTP relay 來切斷 AI 推論請求與使用者身分的連結——這是 Apple Intelligence 整套隱私承諾的核心技術之一。同樣的,Flo Health 在月經健康 App 裡的「Anonymous Mode」也是用 Cloudflare 的 OHTTP relay。
但這些場景過去都假設「應用伺服器在別人家、relay 在 Cloudflare」的部署模型。當 AI 推論越來越多廠商選擇「應用、模型、CDN 全部在同一個 hyperscaler 內」時,OHTTP 的雙盲前提就開始被侵蝕——這也是為什麼這次 OHTTP Gateway 的命名邏輯要刻意區隔「Relay」與「Gateway」兩個角色。
「Gateway 不能和 origin 在同一個 provider」的解套方案
Cloudflare 內部知道這個問題,所以這次 OHTTP Gateway 採用了兩個關鍵防呆機制:
- 拒絕解密自家流量:如果偵測到請求來自 Cloudflare Workers 或來自 Cloudflare 代理過的 host,Gateway 會直接拒絕解密。這代表 Cloudflare 員工無法透過 Workers 偷看解密後的內容。
- Cloudflare Access 強制認證:所有進入 Gateway 的流量會先經過 Cloudflare Zero Trust 的政策驗證(mTLS、靜態憑證、自訂外部邏輯),避免 Gateway 被當成開放的隱藏跳板。
這兩條不是「道德承諾」,是寫進產品行為的硬規則,符合 Cloudflare 在 2022 年 Stronger than a Promise 部落格 提出的形式化驗證精神。
三招工程魔法:Cloudflare 怎麼讓 OHTTP 變簡單
1. 用 Anycast 把延遲壓下來
任何 proxy 架構都會增加延遲,OHTTP 因為是雙跳更是如此。Cloudflare 的解法是 OHTTP Gateway 跑在「每一台 Cloudflare 全域 edge server」上,Anycast 路由自動把 client 導到最近的 gateway;如果 origin 也在 Cloudflare,Gateway 解密後直接在同一機房丟給 origin,連 cross-region latency 都省下來。
2. 自動金鑰管理,使用者完全不用碰
OHTTP 客戶端要拿到 gateway 的 HPKE 公鑰才能加密請求,過去要自己管金鑰輪替、簽章、過期。Cloudflare Gateway 把金鑰管理完全內化,只要 GET /.well-known/ohttp-gateway 就能拿到當下的公鑰,並且支援從不同 IP 下載金鑰(讓 client 不會因為「金鑰下載 IP 等於請求 IP」而被關聯)。
3. 標準 + chunked OHTTP 雙支援,效能優先
Cloudflare Gateway 同時支援標準 OHTTP 與 Chunked OHTTP 兩種訊息格式。後者可以把請求切成 chunk 增量處理,在長請求或大型模型推論的場景下大幅降低 tail latency——這對 AI 推論這種「等不到回應就很難用」的場景特別關鍵。
質疑與侷限:HN 社群點出的三個根本問題
Cloudflare 公告發出後,Hacker News 在 9 小時內湧入 32 則評論,雖然分數最高不到 130,但點出了 OHTTP 模式在實務上的三個根本難題。
問題一:檸檬市場(Adverse Selection)
「這個通道如果被惡意流量佔多數,所有走這個通道的流量都會被當成惡意。暗巷之所以被視為暗巷,是因為長期下來累積的名聲。」——@dzink
這是 OHTTP 隱私工具的老問題:有強烈隱私需求的一般使用者通常缺乏技術能力去安裝 OHTTP 客戶端,而有能力用 OHTTP 隱藏身分的反而是想繞過風控的駭客或代理人。長期下來 OHTTP 通道會變成「高風險流量池」,反讓正常使用者受害。Cloudflare 雖有 Cloudflare Access 認證把關,但這只在「client 端願意提供憑證」的場景有效,純匿名場景仍是死結。
問題二:WAF 與 OHTTP 的 metadata 取捨
「Cloudflare WAF（依賴 TLS 指紋）會不會在 OHTTP 開啟後失效？如果沒有失效,是不是代表 Cloudflare 還是會讀取並處理這些 metadata,只是不傳給應用伺服器？」——@arshxyz
這是工程師最尖銳的質疑。Cloudflare 的商業模式很大一部分是 WAF(用 TLS 指紋、TLS 版本、ASN、地理位置擋攻擊),而 OHTTP 的設計本意就是「讓 origin 看不到這些 metadata」。當 Cloudflare 既是 OHTTP gateway 又是 WAF 供應商時,metadata 還是會被 Cloudflare 看到——只是不轉給 origin。這跟「完全不收集 metadata」是有差距的。
問題三:「按 IP 封鎖濫用者」迴路斷裂
「在雙盲模型下,這個迴路本身就斷了。」——@Joker_vD
傳統反濫用流程是「觀察 → 識別 → 封鎖 IP」。在 OHTTP 雙盲架構下,gateway 看到的 IP 是 relay 的 IP,client 真正的 IP 早就被剝光。任何濫用行為的受害者要追溯源頭,只能去找 relay 業者查 log——但 relay 業者若遵守 OHTTP 隱私前提,就「不該」保存 client IP log。這在反詐欺、垃圾訊息、暴力破解密碼的場景下會變成營運災難。
對 Siami 讀者的意義:這件事離你多近
OHTTP Gateway 是基礎建設級的更新,短期內不會有終端使用者感受到差別——但它會在以下三類場景悄悄影響你:
- 你用的 AI 推論服務選擇 OHTTP:當某天 ChatGPT 競爭對手宣稱「我們的推論請求完全無法回溯到使用者」,背後的技術很可能就是 OHTTP Gateway。
- 你用的健康 / 政治 / 吹哨類 App 啟用 Anonymous Mode:工程團隊不用再自己架 relay,直接付費給 Cloudflare 就能上線。
- 你自己是開發者,在 Cloudflare 上有 zone:只要幾分鐘就能把 OHTTP endpoint 開起來,不用自己碰 HPKE 密碼學。
對重視隱私的台灣讀者來說,這也是少數「台灣可以直接用」的大型隱私基礎建設更新——因為 Cloudflare 在台北有機房,Taiwan 的低延遲 OHTTP 體驗是可達成的。
接下來看什麼
- OHTTP Gateway GA 時間:目前是封測,Cloudflare 沒給 GA 日期,但參考 Privacy Gateway 從封測到 GA 約 6 個月,推測 2027 年 Q1-Q2 會正式上線。
- Apple 是否會把 Private Cloud Compute 的 OHTTP relay 換成 self-host 的 OHTTP gateway:如果 Apple 開始自架 gateway,代表 Cloudflare 在 AI 隱私的護城河會被侵蝕;反之,Apple 續用 Cloudflare 代表這層信任關係會強化。
- Cloudflare 對 chunked OHTTP 的支援深度:目前公告只說「推薦使用 chunked」,實作細節要等開發者文件,可能會影響 AI 推論的 tail latency。
- 2027 年 IETF 對 OHTTP 的延伸工作:重點會放在 chunked OHTTP 標準化、Binary HTTP(草案中)整合,以及 OHTTP 與 MASQUE 的結合——這些都會影響下一代隱私 proxy 的設計。
編按:本文綜合整理自 Cloudflare 官方公告、IETF RFC 9458 Oblivious HTTP 標準、Apple Private Cloud Compute 安全指南、Cloudflare 2022 形式化驗證分析 與 Hacker News 社群討論,並加入 Siami 編輯部觀點與分析。
網友熱門留言 (7)