Cloudflare 宣布將 Cloudflare OHTTP Gateway 推出封閉測試。這是一個託管端點，代為解密 Oblivious HTTP（簡稱 OHTTP，一種把「誰在發送請求」與「請求內容是什麼」拆給不同機器處理的傳輸協定）請求。真正引起討論的卻不是新功能，而是一項拒絕：當請求來自 Cloudflare Workers，或者來自透過 Cloudflare 代理的主機時，Gateway 不會解密。換句話說，Cloudflare 主動排除了把兩端放在同一家公司底下的部署方式。
背景與運作方式 OHTTP 已由 RFC 9458 標準化，運作時把一次請求切成兩段。用戶端先用 HPKE（Hybrid Public Key Encryption，一種基於橢圓曲線與對稱加密組合的公鑰加密機制，用來讓接收方用自己的私鑰解開資料，發送方不需要事先交換秘密金鑰）把內部 HTTP 請求加密到 Gateway 的公鑰上，再把這包密封內容送給 relay（中繼站）。relay 看得到用戶端的 IP 位址，但讀不到內容；Gateway 解密後以一般 HTTP 轉送給應用程式，因此看得到內容，卻只會看到 relay 的位址。這套設計成立的前提是兩跳由不同 operator 運作。作者 Lara Schull 與 Akshat Mahajan 明確指出，模型「要求 relay 與應用伺服器由互不串通、彼此獨立的雙方營運」。若在 Gateway 前放一個 Worker，或把 relay 透過 Cloudflare 代理，就會讓帶有用戶端識別資訊的一跳與負責解密的一跳落進同一家公司，於是 Cloudflare 乾脆讓產品拒絕在該配置下運行。
對評估這套方案的團隊來說，實際成本落在 relay。Cloudflare 不為 Gateway 供應 relay，理由是這個元件並不困難，relay「可以跑在任何基礎設施供應商上，而且很簡單」；困難的是你必須處於一個能「向用戶可驗證地承諾你不會去查看帶有用戶端識別資訊的日誌」的位置。Cloudflare 也把既有的 Privacy Gateway 更名為 Cloudflare OHTTP Relay，把兩側角色區分開。Gateway 本身綁定到特定 zone（網域區塊，代表客戶在 Cloudflare 上管理的一個網域），並固定監聽路徑 https://your-zone.com/.well-known/ohttp-gateway，這阻止客戶把自己的 Gateway 指向別的網域。金鑰由 Cloudflare 管理，公鑰在同一條路徑以 GET 回應提供，用戶端可以透過不同於發送請求的 IP 位址取得金鑰。標準與 chunked（分段）模式的 OHTTP 都支援，建議使用 chunked 以取得較好的效能。Cloudflare Access 會在解密之前執行，因此 relay 本身可用雙向 TLS（mutual TLS，兩端都出示憑證驗證身分的連線方式）、靜態服務憑證或自訂外部邏輯驗證。
技術脈絡與限制 Cloudflare 明確說明保護只到網路層為止：OHTTP「提供網路層的隱私，不碰觸內部請求內容」，並強調「不要在請求內容裡送出識別資訊（例如用戶的 email 或使用者名稱）」。一旦把 session token 或 email 放進密封請求，Gateway operator 就拿到了協定本來要隱藏的身分。Hacker News 上的討論同樣沒有質疑加密是否如描述運作，意見集中在適用範圍與代價。使用者 gsnedders 把 OHTTP 與自架 SOCKS5 proxy 做了詳細對照：OHTTP 針對的是無狀態請求，重點在於讓 Gateway 無法把同一用戶端的多次請求關聯起來，而不只是隱藏 IP；要用 SOCKS5 達到同樣效果，就得為每個請求開新的 TCP 連線、放棄 TLS session resumption 與 0-RTT，還要刻意保守的 ClientHello，因為 SOCKS5 未加密且以明文攜帶目的地。OHTTP 則把 TLS 指紋特徵留在 Gateway 之外，並允許用戶端到 relay、relay 到 Gateway 之間使用長連線，對 DNS over HTTPS 這類負載是明顯的延遲優勢。他同時點出代價：OHTTP 沒有前向安全性，一旦 Gateway 金鑰外洩，relay 就能解開先前用該金鑰錄下的流量。
影響、疑問與限制 操作層面的問題更尖銳。有人質疑啟用 OHTTP 後，依賴 TLS 指紋辨識的 Cloudflare WAF 是否還會運作，若會，是否代表用戶端中繼資料仍由 Cloudflare 讀取處理、只是不傳給應用伺服器；也有人問 IP 封鎖如何維持，以及單一實體服務大量網站時會累積出「哪些 IP 造訪過哪些站」的彙集紀錄，不過留言者也承認這仍比同時擁有來源 IP 與內容要好。採用面的疑問包括：目前有哪個 proxy、tunnel 或 VPN 軟體支援 OHTTP 傳輸；自架 relay 若只服務少數幾個人反而失去意義，因為服務方會知道經手的請求都來自那個小群體；以及付費隱私外掛是否反而不利於普及。與 Tor 的最接近比較是「帶有固定 Gateway 的兩跳 Tor 迴路」，差異在於 OHTTP 需要刻意講這套協定的用戶端，因此不是通用瀏覽隱私，而是適合想做遙測、推論或查詢功能、卻不想把每次請求綁到特定用戶的應用開發者。Cloudflare 舉出的實際部署包含 Flo Health 的 Anonymous Mode、Apple 的 Private Cloud Compute，以及 LiveCallerID 這類接受第三方 OHTTP 的服務，與 Apple 合作的 Reference Image 也以同樣傳輸索取時間戳記而不暴露詢問者。Gateway 預計秋季正式推出，自助版封閉測試現已開放，將以客戶 zone 的付費外掛形式銷售，價格尚未公布，有興趣的團隊可透過候補名單登記。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。