Oblivious HTTP is an IETF standard that lets app backends receive HTTP requests without learning user IP addresses. The request path is split across two independently operated hops: a relay that blindly forwards encrypted requests, and a gateway that performs the cryptography — decapsulating requests and encapsulating responses so that app servers can treat OHTTP traffic like plain HTTP. Neither hop sees both client identifiers and request contents.

Cloudflare launched an OHTTP relay, Privacy Gateway, in 2022. Flo Health uses OHTTP for its Anonymous Mode, and Apple’s Private Cloud Compute uses it to disassociate AI inference requests from user identities. But customers already running their servers behind Cloudflare could not also use a Cloudflare-operated relay: Cloudflare would sit on both sides of the trust boundary. Those customers need a gateway instead.

With the existing Cloudflare OHTTP Relay, customers must bring their own Gateway to preserve a separation of trust.

One protocol, two deployment shapes

The self-serve Cloudflare OHTTP Gateway is entering closed beta, and Privacy Gateway is being renamed Cloudflare OHTTP Relay to distinguish the two products. Customers who want an OHTTP architecture with the required separation of trust now have two options:

  1. Cloudflare OHTTP Relay plus your own gateway. Suited to application servers hosted off Cloudflare, where you can operate an OHTTP gateway yourself.
  2. Cloudflare OHTTP Gateway plus a third-party relay. Suited to app servers already behind Cloudflare (on the CDN or Workers), deployments receiving OHTTP traffic from a third party such as Apple’s LiveCallerID, or anyone who prefers a managed gateway to reduce latency and operational overhead.

The Gateway will be available as a paid add-on to a zone; registration for the waitlist is open.

Why a managed gateway

Operating an OHTTP gateway is harder than it looks, and Cloudflare’s experience running the relay side informed the build.

Demand is real: developers of privacy-oriented apps want network privacy as a default, but it remains difficult to implement. The operational side is the obstacle. Every proxying architecture adds latency because requests travel extra hops, and that cost compounds with the work of decrypting requests and encrypting responses — enough that a homegrown OHTTP setup can carry a significant latency penalty. Cloudflare’s anycast network addresses this directly: the Gateway runs on every server on the edge network, minimizing the relay-to-gateway hop. For customers using the CDN, requests can be decrypted by the Gateway and resolved by app servers on the same Cloudflare metals, removing gateway-to-origin latency. The same building blocks behind 1.1.1.1 and iCloud Private Relay are what make an OHTTP gateway viable as a managed service.

The privacy model is the second constraint. OHTTP requires that the relay and app server be run by separate, non-colluding parties, so server operators behind Cloudflare were previously locked out of the Relay. Offering both products lets developers choose whichever hop Cloudflare should occupy in their architecture.

What OHTTP hides, and how

A conventional client–server exchange is leaky by construction. The app server learns the client’s IP address, since each packet carries a source IP like a “from” label on an envelope, and can fingerprint the client from attributes such as supported TLS versions or cipher suites. Combined, those signals let app servers link multiple requests to one user.

A regular client–server exchange might reveal the following about a client:

- ipAddress: 192.0.2.33 # the client’s IP address 
- ASN: 7922
- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique
- tlsVersion: TLSv1.3
- Country: US
- Region: California # the client's location
- City: Campbell

Routing the same request through an OHTTP relay leaves the app server seeing only the relay’s information:

- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint 
- ASN: 18 
- tlsCipher: AEAD-AES-128-GCM-SHA256 
- tlsVersion: TLSv1.3 
- Country: US
- Region: Texas  # the relay's location
- City: Austin

Because the relay strips client identifiers before forwarding, the app server learns neither the end user’s location nor their TLS fingerprint per request. When many users share the relay, individual requests become indistinguishable from one another, which limits the app server’s ability to trace activity back to a single user.

Encryption is what separates OHTTP from a plain forwarding proxy. Requests and responses are encapsulated with Hybrid Public Key Encryption (HPKE), so only the client and app server see plaintext and the relay sees ciphertext. The gateway handles that cryptography and leaves the app server speaking ordinary HTTP.

A diagram showing how requests flow from end users through the OHTTP Gateway to app servers. A response from app servers follows the same path in reverse to the end user. Note that with the Gateway, you can choose whether or not to put your servers behind Cloudflare.

Design decisions in the Gateway

The Gateway runs as a feature of a zone, deployed across Cloudflare’s global network and scaled automatically, so customers need not plan for capacity. It is enabled with a couple of clicks, after which clients send well-formed OHTTP requests to https://your-zone.com/.well-known/ohttp-gateway. Both standard and chunked OHTTP are supported; chunked OHTTP is recommended because it lets requests be processed incrementally for better performance. The Gateway intercepts each OHTTP request, decrypts it, issues a subrequest to the app server, and returns an encrypted response to the client. Non-OHTTP requests reach the server without invoking the Gateway.

Four further decisions shaped the service:

  • Zone binding limits abuse. A client sending to example.com may send to foo.example.com or bar.example.com, but not wikipedia.com, which stops unauthorized clients from using a zone to target other domains.
  • Keys are fully managed. The Gateway maintains the public HPKE key configuration clients need to encrypt requests and serves it in response to GET requests to /.well-known/ohttp-gateway. Clients can fetch keys over a different IP than the one they use for the gateway, which strengthens privacy.
  • Relays are authenticated before decryption. The Gateway knows little about the client behind a request and relies on the relay to authenticate clients and forward traffic responsibly. Cloudflare Access runs ahead of decryption, so standard Access policies — mutual TLS, static service credentials, custom external logic — can be applied to incoming traffic.
  • Separation of trust is enforced. To prevent a customer from accidentally collapsing OHTTP’s privacy model by running relay and gateway both on Cloudflare, the Gateway refuses to decrypt requests sent from Cloudflare Workers or from proxied hosts on Cloudflare, ensuring Cloudflare never holds both client identities and decrypted inner requests.

Choosing between Cloudflare’s relay and gateway

Two questions decide it. If your app servers live on Cloudflare — behind the CDN or built on Workers — the Gateway is the fit, because it keeps the relay and app server under separate operators. If your use case involves accepting OHTTP requests from a third-party client and relay, such as integrating Apple’s LiveCallerID SDK, the Gateway is likewise the better choice.

Building an OHTTP deployment

Two roles have to be filled before traffic can flow: an OHTTP client and a relay. Cloudflare also offers a client library and a CLI to help with both halves of the work.

Client considerations

Start by implementing an OHTTP client; ohttp.info and Cloudflare's sample client library both provide starting points. Keep one property of the protocol in mind while building: OHTTP protects the network layer only and does not touch the inner request body. Any identifying data placed there — an email address or username, for example — is left exposed, so keeping it out is the client's responsibility.

Running a relay

Relays are not tied to any particular infrastructure provider. The published sample code shows how little is involved. The harder problem is trust: without a verifiable commitment not to inspect logs for client identifiers, the relay operator can correlate clients at the relay with decrypted requests at the application servers, which defeats the point of the deployment.

Testing

Once a deployment is live, the open-sourced pvcli client can be used for testing and debugging.

Feature requests and waitlist registrations go through the privacy edge sign-up page, which is also the contact point for trying the OHTTP Gateway.