問題：選了 Cloudflare 當源站，就走不了完整的 OHTTP 架構
OHTTP（Oblivious HTTP）是 IETF 標準，設計目標很具體：讓應用後端收到 HTTP 請求，但看不到使用者的 IP 位址和 TLS 指紋。做法是引入兩個獨立營運的跳點——relay 負責盲目轉發加密請求、隱藏客戶端識別資訊，gateway 負責 HPKE 的加解密工作，讓應用伺服器只處理明文 HTTP。兩邊分離的信任模型是整個協議的核心：任何單一一方都不該同時看到客戶端識別資訊和請求內容。
Cloudflare 早在 2022 年就推出了 relay 產品 Privacy Gateway（現在改名為 OHTTP Relay），Flo Health 的 Anonymous Mode 和 Apple 的 Private Cloud Compute 都用了 OHTTP。但這裡一直有個結構性的缺口：如果你的應用伺服器本身就放在 Cloudflare 後面——不管是 CDN 還是 Workers——就不能再用 Cloudflare 的 relay，因為 Cloudflare 會同時看到客戶端 metadata 和解密後的請求內容，直接打破 OHTTP 的隱私模型。你需要的是一台 gateway，配上別家的 relay。
2026 年 10 月的公告補上這一塊
根據 Cloudflare 在 2026 年 10 月 2 日的公告，公司推出了 Cloudflare OHTTP Gateway 的封閉測試版，未來將以付費附加服務的形式掛在 zone 上，幾次點擊就能開啟，客戶端可以向 /.well-known/ohttp-gateway 端點發送 OHTTP 請求。同時 Privacy Gateway 更名為 Cloudflare OHTTP Relay，把兩個產品的分工講清楚：
- 應用伺服器不在 Cloudflare 上：用 Cloudflare 的 OHTTP Relay，自己跑 gateway。
- 應用伺服器在 Cloudflare 上、或要接收第三方 OHTTP 請求（例如 Apple 的 LiveCallerID SDK）：用新的 OHTTP Gateway，配第三方 relay。
這其實延續了 Cloudflare 這段時間一貫的打法——把過去只有大廠會自己刻的基礎設施，拆成免費或低門檻的產品。我之前寫過 Cloudflare 把 Enterprise 級功能下放到免費用戶的趨勢（Enterprise 級功能下放到免費用戶：Cloudflare 這一年把「能用的」和「用多少」分開了），OHTTP Gateway 是同一條線：Cloudflare 說它替 1.1.1.1 和 iCloud Private Relay 營運隱私基礎設施積累的能力，現在開放給一般客戶。
對 builder 實際有意思的三個設計決定
延遲被壓到同一台機器上解決。 Cloudflare 指出，自己搭建的 OHTTP 架構延遲成本不低——多一兩跳加上加解密開銷。它的做法是 gateway 跑在整個 anycast 邊緣網路的每一台伺服器上；如果你的源站也在 Cloudflare，解密和回源可以在同一組機器完成，省掉 gateway 到 origin 的一段。
Key 管理和 relay 驗證都被託管了。 Gateway 全權管理 HPKE key，客戶端透過 GET 請求拿公鑰設定；認證方面，Cloudflare Access 在解密之前執行，可以用 mTLS、靜態服務憑證或外部邏輯來驗證哪些 relay 有資格送流量進來。
防止你自己打破隱私模型。 如果客戶把 relay 和 gateway 都跑在 Cloudflare 上，gateway 會拒絕解密來自 Cloudflare Workers 或 proxied hosts 的請求。這是一種「把犯錯路徑堵死」的設計，比文件裡寫一行警告有效得多。
值得注意的邊界
OHTTP 提供的是網路層的隱私，解決的是「伺服器無法把請求關聯到特定使用者」這件事，不是匿名的萬靈丹——應用層如果自己記帳號、記行為，照樣能畫出使用者輪廓。另外，目前產品還在封閉測試，Cloudflare 提供了 waitlist 表單，並建議開發者先參考 ohttp.info 和官方的 sample client library 實作 OHTTP 客戶端；公告也推薦用 chunked OHTTP，因為 gateway 可以增量處理請求，效能更好。
如果你手上的產品涉及健康、位置這類敏感資料，多一層「伺服器看不到來源」的架構選項，值得放進設計討論裡——至少先想清楚你的隱私承諾停在哪一層。