--- title: Announcing Cloudflare OHTTP Gateway – expanding access... description: Cloudflare is launching a closed beta for a self-serve OHTTP (Oblivious HTTP) Gateway, a paid zone add-on that lets app servers already behind Cloudflare... canonical: https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure | daily.dev og:description: Cloudflare is launching a closed beta for a self-serve OHTTP (Oblivious HTTP) Gateway, a paid zone add-on that lets app servers already behind Cloudflare... og:url: https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe og:image: https://api.daily.dev/og/posts/lLcHHfrPE.png og:image:alt: Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure **[Cloudflare](https://daily.dev/sources/cloudflare)** · 11 min read · 1 upvotes · 0 comments ## Summary Cloudflare is launching a closed beta for a self-serve OHTTP (Oblivious HTTP) Gateway, a paid zone add-on that lets app servers already behind Cloudflare accept privacy-preserving OHTTP traffic. Alongside this, Cloudflare is renaming its existing Privacy Gateway product to Cloudflare OHTTP Relay to clarify the distinction between the two roles in OHTTP's relay/gateway architecture. The Gateway handles decapsulation/encapsulation automatically, manages HPKE keys, authenticates relays via Cloudflare Access, runs on every edge server for low latency, and refuses to decrypt requests originating from Cloudflare Workers or proxied Cloudflare hosts to preserve OHTTP's separation-of-trust privacy model. The post also walks through how OHTTP works, why a relay and gateway must be independently operated, and how developers can get started building clients and relays. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between Cloudflare's OHTTP Relay and the new OHTTP Gateway? The OHTTP Relay (formerly Privacy Gateway) blindly forwards encrypted requests to hide client identifiers, while the OHTTP Gateway performs the cryptographic decapsulation and encapsulation so app servers can handle requests as plain HTTP. Use the Relay if your app servers run off Cloudflare and you operate your own gateway; use the Gateway if your servers are already behind Cloudflare or you receive OHTTP from a third-party relay like Apple's LiveCallerID. _Teams choosing between relay and gateway architectures can track infrastructure changes like this on daily.dev._ ### Why was Cloudflare's Privacy Gateway renamed to OHTTP Relay? Cloudflare renamed Privacy Gateway to Cloudflare OHTTP Relay to distinguish it from the newly launched Cloudflare OHTTP Gateway, since the two products perform different roles in the OHTTP architecture: a relay hides client identifiers while a gateway decrypts request contents. The rename accompanies the closed beta launch of the self-serve OHTTP Gateway as a paid zone add-on. _Developers relying on Cloudflare privacy products can follow naming and product changes like this via daily.dev._ ### Why can't an app server already behind Cloudflare use Cloudflare's OHTTP Relay product? OHTTP's privacy model requires the relay and app server to be operated by separate, non-colluding parties so no single entity sees both client identifiers and decrypted request contents. If an app server is already behind Cloudflare, using a Cloudflare-operated relay would let Cloudflare see both pieces of information, breaking that separation of trust; such customers need Cloudflare's new OHTTP Gateway with a third-party relay instead. _Architects designing privacy-preserving systems can reference trust-separation requirements like this via daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 112 comments across lobsters, hackernews (as of 2026-10-04). **TL;DR:** Much of the discussion spirals into tangents about whether Cloudflare is effectively a surveillance chokepoint (NSA/CIA jokes aside), while a smaller technical thread debates whether OHTTP actually improves privacy given Cloudflare still sees either the IP or the request content. **Sentiment:** 15% positive · 30% mixed · 55% skeptical **The case for** - Some argue the relay/gateway split genuinely prevents any single party from knowing both who is asking and what they're asking, unlike a plain proxy. - One commenter notes it's a good fit for stateless, non-correlatable requests like DNS-over-HTTPS, with real latency and security advantages over SOCKS5-style proxies. - Developers building offline/private software mention wanting exactly this kind of privacy-preserving network call for things like update checks. **The pushback** - Many are skeptical that funneling more traffic/metadata through Cloudflare's infrastructure actually improves privacy versus just keeping data in your own logs. - Several see it as reinforcing Cloudflare's centralization and MITM-like position over a huge share of web traffic, despite the cryptographic separation-of-trust design. - Concerns that it could make abuse/bot traffic harder to identify and ban, and that charging for a privacy feature creates poor incentives for broader adoption. - Confusion/skepticism about real-world use cases, with some finding the stated rationale (reducing IP/TLS fingerprint exposure) unconvincing given sites still run trackers like Google's. **By community** - lobsters (mixed): No substantive comments were provided, so there's no real discussion signal to characterize. - hackernews (heated): A long, contentious thread mixing dark jokes about Cloudflare as a surveillance proxy with a genuine technical debate over whether OHTTP meaningfully improves privacy or just centralizes more metadata with Cloudflare. **Hottest debate:** Whether routing more traffic through Cloudflare's gateway/relay split actually protects privacy or just shifts trust and metadata exposure onto an already-dominant centralized infrastructure provider. **Open questions** - Can site owners toggle OHTTP on/off unpredictably, and how would a visitor know in advance whether it's enabled for their request? - Does Cloudflare's TLS fingerprinting/WAF still function when OHTTP is enabled, and if so does that mean client metadata is still being read by Cloudflare even if not passed to the app server? - Is there a way to self-host or run a personal OHTTP relay/gateway outside Cloudflare's offering? **Highlights** > OHTTP is designed for a relatively narrow use case: stateless requests where you don't want the gateway to be able to correlate multiple requests from the same client (i.e., it's not just about hiding the IP address). A clear example of when this might be a good idea is DNS-over-HTTPS — you don't want the resolver being able to correlate multiple requests from the same client. You _can_ try and do this with SOCKS5, however you need to be very careful to avoid sharing any state: * You must use a new TCP connection for each request, with a new TLS and HTTP connection atop. * You must ensure you do not use TLS Session Resumption or 0-RTT data. * You must, to the maximum extent possible, be very conservative with what you send in the TLS ClientHello to avoid exposing fingerprinting data. SOCKS5 is also unencrypted, and the request contains the destination: the hostname if the proxy resolves it, or the IP if the client resolved it itself (and ECH doesn't help here, since it only protects the SNI inside the TLS handshake that follows). With OHTTP, that's all inside the TLS connection to the relay. OHTTP doesn't have the client sending up-front metadata about all the different encryption methods it supports to the gateway (it relies on the gateway to tell it what it supports, and the client just picks one); the gateway doesn't get to see any of the TLS fingerprinting surface (because that is only visible to the relay). OHTTP also doesn't require there to be multiple new TCP connections made for every request (whereas with SOCKS5 you're looking at a new TCP connection from the client to the proxy, and from the proxy to the server, per request) — you can have a long-lived connection to the relay, and the relay can have a long-lived connection to the gateway (shared by many clients). That's a big latency win for applications like DNS-over-HTTPS. The risks of key disclosure also differ between the two — with OHTTP, disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy), whereas disclosure of the client <-> relay and relay <-> gateway keys matters a lot less (because there is forward secrecy); with SOCKS5, you have forward secrecy via the end-to-end TLS connection. For the use-case of a general-use proxy, work such as MASQUE provides a multi-hop approach to limit exposure to any single party, and that does provide an end-to-end TLS connection — but you with that you're back to exposing all the fingerprinting associated with it, though for a general use proxy you may also be sending session-specific data (like auth tokens) that clearly tie requests together anyway. > — [gsnedders on hackernews](https://news.ycombinator.com/item?id=49949431) > It's literally not MITM because they can't see the ciphertext, and specifically went out of their way to prevent themselves from being able to decrypt it (ie. you can't set up an OHTTP service where both hops are cloudflare). > — [gruez on hackernews](https://news.ycombinator.com/item?id=49946193) > This separates who sees what. Cloudflare (or any OHTTP gateway) sees who talks to who, but can't see the content. The service sees the content but not who you are/your IP. You can imagine a lot of threat models where who you talk to isn't sensitive, nor is "someone talked to them about X" but knowing both facts is a risk. > — [johnhess on hackernews · 1 comments](https://news.ycombinator.com/item?id=49945607) > > Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks. I love to see privacy improvement in tech. However I do wonder at this. Cloudflare is obviously a business and can't do everything for free, but charging extra for websites to add privacy Seems like a poor incentive if the goal is to improve privacy generally > — [freedomben on hackernews · 1 comments](https://news.ycombinator.com/item?id=49944816) > It adds some level of privacy without going as far as something like Tor. As a result, it's a lot faster than Tor, but a lot less private. The "privacy" it adds is that it separates your IP from your request, so no one actor on the way knows "X requested Y". A server knows "X requested something", another one knows "someone requested Y". Maybe you don't need it, but I don't see how this is slightly creepy. > — [palata on hackernews](https://news.ycombinator.com/item?id=49948101) **Source threads** - [lobsters](https://lobste.rs/s/l5ev1t/announcing_cloudflare_ohttp_gateway) · 1 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=49941091) · 92 points · 112 comments ## Similar posts on daily.dev - [Cloudflare’s OHTTP Gateway Refuses to Decrypt Requests That Arrive Through Cloudflare](https://daily.dev/posts/cloudflare-s-ohttp-gateway-refuses-to-decrypt-requests-that-arrive-through-cloudflare-txtr8d54d) · InfoQ · 0 upvotes · 0 comments - [Moving from license plates to badges: the Gateway Authorization Proxy](https://daily.dev/posts/moving-from-license-plates-to-badges-the-gateway-authorization-proxy-dbacpdxas) · Cloudflare · 0 upvotes · 0 comments - [Is Cloudflare Tunnel Secure for Self-Hosting?](https://daily.dev/posts/is-cloudflare-tunnel-secure-for-self-hosting--btpc3mo3w) · Noted · 0 upvotes · 0 comments - [Self-hosted HTTP tunnels with SSH and nginx](https://daily.dev/posts/self-hosted-http-tunnels-with-ssh-and-nginx-qeu3pqxry) · Lobsters · 1 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#privacy](https://daily.dev/tags/privacy), [#cloudflare](https://daily.dev/tags/cloudflare) [View this post on daily.dev](https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure","url":"https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe"},"datePublished":"2026-10-02T13:13:46.164Z","dateModified":"2026-10-04T01:13:34.478Z","description":"Cloudflare is launching a closed beta for a self-serve OHTTP (Oblivious HTTP) Gateway, a paid zone add-on that lets app servers already behind Cloudflare...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/a04b042561b1cc68b477ad136f266c1f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/a04b042561b1cc68b477ad136f266c1f?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Cloudflare","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Cloudflare","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/38522e1d11354cd6b7af66f9d4316735","url":"https://daily.dev/sources/cloudflare"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,privacy,cloudflare","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Cloudflare","item":"https://daily.dev/sources/cloudflare"},{"@type":"ListItem","position":3,"name":"Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/announcing-cloudflare-ohttp-gateway-expanding-access-to-cloudflare-s-privacy-preserving-infrastruc-llchhfrpe#faq","mainEntity":[{"@type":"Question","name":"What is the difference between Cloudflare's OHTTP Relay and the new OHTTP Gateway?","acceptedAnswer":{"@type":"Answer","text":"The OHTTP Relay (formerly Privacy Gateway) blindly forwards encrypted requests to hide client identifiers, while the OHTTP Gateway performs the cryptographic decapsulation and encapsulation so app servers can handle requests as plain HTTP. Use the Relay if your app servers run off Cloudflare and you operate your own gateway; use the Gateway if your servers are already behind Cloudflare or you receive OHTTP from a third-party relay like Apple's LiveCallerID. Teams choosing between relay and gateway architectures can track infrastructure changes like this on daily.dev."}},{"@type":"Question","name":"Why was Cloudflare's Privacy Gateway renamed to OHTTP Relay?","acceptedAnswer":{"@type":"Answer","text":"Cloudflare renamed Privacy Gateway to Cloudflare OHTTP Relay to distinguish it from the newly launched Cloudflare OHTTP Gateway, since the two products perform different roles in the OHTTP architecture: a relay hides client identifiers while a gateway decrypts request contents. The rename accompanies the closed beta launch of the self-serve OHTTP Gateway as a paid zone add-on. Developers relying on Cloudflare privacy products can follow naming and product changes like this via daily.dev."}},{"@type":"Question","name":"Why can't an app server already behind Cloudflare use Cloudflare's OHTTP Relay product?","acceptedAnswer":{"@type":"Answer","text":"OHTTP's privacy model requires the relay and app server to be operated by separate, non-colluding parties so no single entity sees both client identifiers and decrypted request contents. If an app server is already behind Cloudflare, using a Cloudflare-operated relay would let Cloudflare see both pieces of information, breaking that separation of trust; such customers need Cloudflare's new OHTTP Gateway with a third-party relay instead. Architects designing privacy-preserving systems can reference trust-separation requirements like this via daily.dev."}}]} ```