Cloudflare 於二零二六年十月二日 Birthday Week 官方網誌宣布，推出自助式 Cloudflare OHTTP Gateway 封閉測試，可作為付費區級附加服務啟用，讓應用後端在收 OHTTP 流量時不必看見用戶 IP；同期把既有 Privacy Gateway 更名為 Cloudflare OHTTP Relay，與新閘道組成可選雙邊架構。文中指 Oblivious HTTP 為 IETF 標準，並舉 Flo Health Anonymous Mode 與 Apple Private Cloud Compute 等既有 OHTTP 用例。本文核對自 Cloudflare 官方網誌，來源真實性已驗證。

Cloudflare／官方：推出 OHTTP Gateway 封閉測試——區級附加服務收 OHTTP；Privacy Gateway 更名 OHTTP Relay；支援雙盲私隱架構

一般客戶端與應用伺服器直連時，伺服器會看到來源 IP、TLS 指紋與大致地理位置，容易把多次請求關聯到同一用戶。OHTTP 在路徑上拆成「中繼（relay）」與「閘道（gateway）」兩段：中繼轉發並剝離客戶端識別，閘道負責加解密，使應用端只處理近乎普通的 HTTP。Cloudflare 今次補上自營閘道封閉測試，讓已把源站放在其 CDN／Workers 後方的客戶，也能在不破壞「中繼與閘道須由不同、不共謀方營運」的前提下採用 OHTTP。來源真實性已驗證。

一、核心事件：OHTTP Gateway 封閉測試與產品更名

技術細節與產品要點

據 Cloudflare 二零二六年十月二日官方網誌《Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure》：

新產品：Cloudflare OHTTP Gateway 進入封閉測試（closed beta）；客戶可把閘道作為其 zone 的付費附加服務啟用，並經官方表單登記候補／功能請求。
更名：既有 Privacy Gateway 更名為 Cloudflare OHTTP Relay，與新閘道並列，避免名稱混淆。
兩種合規架構選項（官方列舉）：
- 使用 Cloudflare OHTTP Relay，並自建閘道——適合應用伺服器不在 Cloudflare 上、且有能力自營閘道者；
- 使用 Cloudflare 新 OHTTP Gateway，並搭配第三方中繼——適合源站已在 Cloudflare CDN／Workers 後方、需接收第三方客戶／中繼（例如文中提及的 Apple LiveCallerID）或希望託管閘道以降低延遲與維運負擔者。
端點與協定：啟用後，客戶可向 https://your-zone.com/.well-known/ohttp-gateway 送符合格式的 OHTTP 請求；支援標準與分塊（chunked）OHTTP，官方建議分塊以利增量處理、改善效能。閘道會攔截並解密 OHTTP、向應用發子請求、再把加密回應交回客戶端；非 OHTTP 請求仍直達源站而不觸發閘道。
金鑰：閘道為客戶全面管理 HPKE 公鑰組態；客戶端以 GET /.well-known/ohttp-gateway 取得公鑰。為加強私隱，客戶端可用與請求閘道不同的 IP 下載金鑰。
中繼認證：解密前先經 Cloudflare Access，可用 mTLS、靜態服務憑證或自訂外部邏輯等標準 Access 政策，只允許可信中繼送流量。
防誤用分離信任：為避免同一營運方同時看到客戶端身分與解密內容，閘道拒絕解密來自 Cloudflare Workers 或 Cloudflare 已代理主機的請求，以免破壞 OHTTP 私隱模型。
效能定位：官方指閘道以 anycast 部署於全球邊緣每一台伺服器，縮短中繼到閘道跳數；若同時使用其 CDN，解密與源站解析可落在同一金屬機，減少閘道到源站延遲。區綁定亦限制客戶只能打自家 zone 下主機，降低把閘道當開放代理濫用的風險。
既有用例（官方舉例）：Flo Health 以 OHTTP 支援 App 的 Anonymous Mode；Apple Private Cloud Compute 以 OHTTP 把 AI 推論請求與用戶身分脫鈎。Cloudflare 指自二零二二年推出中繼產品以來，觀察到開發者對可用私隱基建需求上升，且自建高效能閘道成本與延遲門檻偏高。

二、技術原理深度解析

OHTTP 與一般正向代理的關鍵差異，在於雙盲：

識別平面（中繼可見）：中繼看到客戶端 IP／TLS 指紋，但在轉發前剝離；應用端只看到中繼的網路指紋與位置，難以把多次請求綁回同一終端用戶。
內容平面（閘道／應用可見）：請求與回應以 HPKE（Hybrid Public Key Encryption） 封裝，中繼只見密文；閘道負責解封裝／再封裝，應用伺服器可當普通 HTTP 處理。
信任分離：中繼與閘道（及應用）必須由不同、不共謀的營運方負責，否則單一機構可同時關聯「誰」與「說了甚麼」。這也解釋為何「源站已在 Cloudflare 後方」時，不能再選 Cloudflare 自營中繼，而需要 Cloudflare 閘道＋第三方中繼（或反向：Cloudflare 中繼＋自建閘道）。

對產品團隊而言，OHTTP 只處理網路層私隱；若在請求本文仍放入電郵、用戶名等識別欄位，雙盲模型會被應用層自行拆穿。官方亦提醒客戶端實作可參考 ohttp.info 與樣例庫，並可用 pvcli 做部署後測試除錯。

四、日常應用場景

1. 開發者與技術團隊

若 API 已掛在 Cloudflare zone，可在封閉測試開放後為 /.well-known/ohttp-gateway 接上客戶端 SDK，並另選獨立中繼；優先採 chunked OHTTP，並用 Access 政策鎖死允許的中繼身分。本地與 CI 可用官方提到的樣例客戶端／pvcli 驗證加解密與金鑰輪替，再把非 OHTTP 管理流量與 OHTTP 業務流量分開觀測。

2. 企業與隱私敏感行業

醫療、金融與需要「盡量少知用戶是誰」的消費 App，可把登入後的身分流程與匿名／低連結模式分開：敏感查詢走 OHTTP，營運分析則只保留聚合指標。已使用 Cloudflare 的企業可把閘道當區級附加能力，而不必自建密碼學代理叢集；同時仍須自備可信第三方中繼，並在合約與稽核上證明中繼不會與閘道／源站共謀對帳。

3. 一般用戶

終端用戶通常不會直接設定 OHTTP；體感是 App 在匿名或私隱模式下，服務商較難把行為與家用 IP 長期綁定。用戶仍應理解：帳戶登入、裝置指紋與應用層識別不在 OHTTP 自動消除範圍內。

4. 香港與亞洲市場視角

香港金融、醫療與跨境 App 常同時面對《個人資料（私隱）條例》期望與全球邊緣加速需求。把源站放在 Cloudflare 並啟用 OHTTP Gateway，有助在「不放棄 CDN／Workers」的前提下引入 IETF 標準雙盲路徑，尤其適合要把 AI 推論、健康或位置相關 API 與家用 IP 脫鈎的產品。亞洲團隊選中繼供應商時，應一併評估日誌保留、司法管轄與「可驗證不窺探」聲明；封閉測試階段亦應把候補名額、SLA 與正式計費條款納入採購清單，避免把 beta 當成已全面 GA 的合規控制。

五、專業評價與潛在考量

優勢

官方一次補齊「中繼＋閘道」產品敘事，並把 Privacy Gateway 更名，降低架構選型混淆。
對已在 Cloudflare 後方的源站，提供符合分離信任的託管閘道路徑；anycast 與同機解密／源站解析有助控制延遲。
金鑰託管、/.well-known 端點、Access 前置認證與拒絕「自家人同時當中繼」等設計，針對實務誤用與濫用有具體防護。
引用 Flo Health、Apple Private Cloud Compute 等可見用例，說明 OHTTP 已不只是論文協定。

需要留意的地方

現為封閉測試，須登記候補；正式開放範圍、價目與 SLA 以後續官方公布為準，本文不臆測單價。
客戶必須自備第三方中繼（若用 Cloudflare 閘道），並確保應用層不回傳可識別個資。
OHTTP 不取代帳戶安全、裝置綁定或內容審核；它解決的是網路層關聯，不是完整零知識業務邏輯。
多一跳必然帶來架構複雜度；除錯需同時看中繼健康、閘道金鑰與 Access 政策。

結語

Cloudflare 以 Birthday Week 把 OHTTP 產品線從「只做中繼」擴成「中繼或閘道可選」：OHTTP Gateway 封閉測試讓已把應用放在其邊緣後方的團隊，也能用 IETF 雙盲模型接收不帶用戶 IP 的 HTTP 業務；Privacy Gateway 更名 OHTTP Relay 則釐清另一半拼圖。對要在邊緣加速與用戶私隱之間找平衡的產品而言，這直接影響 AI 推論、健康與匿名模式 API 的網路架構選型。

若香港團隊正規劃雲端遷移、零信任與面向私隱的邊緣／API 防護，可參考 YSK Limited 的雲端遷移與網絡安全服務（官網刊 99.99% SLA）：https://ysk.hk/services/cloud-security

參考來源

Cloudflare 官方網誌：Announcing Cloudflare OHTTP Gateway（2026-10-02）https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/
OHTTP 實作與說明入口（官方文內指引）https://ohttp.info/