Cloudflare has begun a closed test of Cloudflare OHTTP Gateway, a paid add-on that can be enabled on a customer domain to receive Oblivious HTTP (OHTTP) traffic through a managed infrastructure. The service targets developers who want to conceal IP addresses and client-identifying indicators from their application servers, particularly when those servers are hosted behind the Cloudflare network or on Workers.
At the same time, the company renamed its previous Privacy Gateway product to Cloudflare OHTTP Relay. The change reflects the existence of two different products in the OHTTP model: the relay forwards encrypted requests and hides the client’s identity, while the gateway handles decrypting the request envelope and re-encrypting the response before delivering it to the application server.
How Does the OHTTP Model Work?
In a traditional connection, an application server can see the client’s IP address, TLS characteristics, and location information, which may allow multiple requests to be linked to the same user. In OHTTP, the request passes through an independent relay that removes client identity indicators before forwarding it. The request contents remain encrypted using Hybrid Public Key Encryption (HPKE), so the relay cannot see the plaintext.
After that, the gateway processes the cryptographic portion and sends the request to the application server in the usual HTTP format. This creates a separation of trust: the relay sees the connection identity but not the request content, while the gateway and application server see the request content without the client’s direct identity. This model requires that the two parties performing the relay and gateway roles do not collude.
What Does the New Gateway Add?
OHTTP Gateway operates as a feature within Cloudflare’s domain and can be enabled through specific access points such as /.well-known/ohttp-gateway. The service supports standard OHTTP and Chunked OHTTP, with a recommendation to use the chunked type to process requests progressively. Cloudflare also manages the public HPKE keys and provides them to customers, rather than making the customer responsible for managing the key lifecycle.
The service benefits from Cloudflare’s global network, allowing the gateway to run at the network edge and reducing latency between the relay and the gateway. If application servers use the company’s CDN, request processing and access to the server can take place on the same infrastructure. The gateway handles OHTTP requests only, while ordinary requests continue to reach the server without undergoing OHTTP processing.
Trust and Usage Controls
Cloudflare Access allows authentication policies to be enforced before requests are decrypted, including mutual TLS, static service credentials, and custom external logic. The gateway also rejects requests originating from Cloudflare Workers or hosts proxied through Cloudflare, to avoid having the same party operate both the relay and gateway and weakening the separation of trust on which OHTTP relies.
Cloudflare recommends using OHTTP Gateway when application servers are behind Cloudflare or when the request comes from a relay and client belonging to a third party, such as certain Apple LiveCallerID use cases. Cloudflare OHTTP Relay, under its new name, is suitable for those who want to use Cloudflare’s relay while operating the gateway themselves outside Cloudflare.
What Changes in Practice?
The new service reduces the operational burden of building an OHTTP gateway, but it does not eliminate the core architectural requirements. The client still needs to implement OHTTP, and the user needs an independent relay; Cloudflare emphasizes that the relay must be an entity that can be trusted not to inspect logs or link client identities to decrypted requests. OHTTP also does not protect metadata contained within the request body itself, so developers are responsible for not sending email addresses, usernames, or other identifiers as part of the request content.
The service is currently available through a closed test and waiting list, and the announcement did not specify a public launch date or pricing details. The step therefore represents an important expansion of network privacy tools, but it still requires development teams to make independent decisions regarding the relay, request content, and trust model between the parties.