Cloudflare OHTTP Gateway separates app requests from IPs

Cloudflare OHTTP Gateway is designed to let applications receive requests without learning the user's internet address, while keeping the contents unreadable to the intermediary forwarding them. In an announcement dated October 2, 2026, Cloudflare authors Lara Schull and Akshat Mahajan describe a managed service that handles the encryption needed for Oblivious HTTP (OHTTP), a protocol that separates information about who is connecting from what they are requesting.

For website owners and application teams, the central change is operational: Cloudflare takes responsibility for the gateway's cryptography and encryption keys rather than requiring customers to run that component themselves. The service operates across Cloudflare's global network, with capacity adjusted automatically, according to the company. Application servers can use it whether or not they otherwise sit behind Cloudflare.

Separating identity from request contents

An IP address is the network address used to connect over the internet. Along with location information and connection characteristics, it can help a service associate activity with a user. OHTTP inserts a relay, an intermediary that forwards traffic, between the user's application and the receiving infrastructure. The application server then sees the relay's network details rather than the user's.

Cloudflare illustrates this with a request showing the relay's IP address, 128.62.37.13, and ASN 18. An autonomous system number (ASN) identifies a network on the internet. The example places the relay in Austin, Texas, US, and lists TLSv1.3 and AEAD-AES-128-GCM-SHA256 as connection details. Transport Layer Security (TLS) protects connections; the cipher identifier describes the cryptographic methods used. Together, such details can form a TLS fingerprint, a recognisable pattern of connection settings. In this example, the location and fingerprint belong to the relay, not the end user.

When many users share a relay, these network details no longer distinguish their individual requests at the application server. That limits the server's ability to link activity back to one person through those details. It is a specific privacy boundary, not a claim that every possible means of identifying someone has disappeared.

The other essential part is encryption. A basic forwarding proxy, a service that passes traffic onward, does not by itself provide OHTTP's separation of visibility. OHTTP uses Hybrid Public Key Encryption (HPKE), a method for encrypting messages for an intended recipient, to wrap requests and responses. The relay sees encrypted data rather than readable contents. A gateway between the relay and application server unwraps incoming requests and encrypts outgoing responses, leaving the application to handle ordinary HTTP, the request-and-response language used by web services.

The result is a split-trust privacy model: the relay can see client network identifiers but not the inner request, while the gateway and application server can see request contents without receiving the user's network identifiers. Responses follow the same route back. The gateway is therefore part of the trusted infrastructure that can read the request, not merely another blind forwarding service.

How the managed gateway works

Cloudflare OHTTP Gateway is enabled for a zone, the domain configuration managed through Cloudflare. Clients send correctly formatted OHTTP requests to https://your-zone.com/.well-known/ohttp-gateway. The gateway decrypts each request, makes a separate request to the application server, and encrypts the response before returning it. Traffic that is not OHTTP bypasses this gateway processing, so an application can continue accepting ordinary HTTP requests too.

The service supports standard OHTTP and chunked OHTTP, which divides messages into pieces that can be processed incrementally. Cloudflare recommends the chunked option for better performance. Its account says the design addresses difficulties encountered by customers of Cloudflare OHTTP Relay who operated their own gateways.

Tying the gateway to a zone also limits where it can forward requests. For a zone named example.com, clients may target foo.example.com or bar.example.com, but not wikipedia.com. This restriction is intended to stop unauthorised clients from using a customer's gateway to direct traffic at unrelated domains.

Cloudflare also manages the encryption keys. Clients need a public HPKE key configuration, information that lets them encrypt messages the gateway can open. They retrieve it by sending a GET request, the standard web operation for fetching a resource, to /.well-known/ohttp-gateway. Cloudflare says clients can strengthen privacy by obtaining those keys through a different IP address from the one used to contact the gateway.

Trusting the relay without combining both roles

Because the gateway deliberately receives little information about the original client, it relies on the relay to authenticate clients and forward traffic responsibly. Cloudflare Access, the company's product for checking access permissions, runs before gateway requests are decrypted. Customers can apply its standard policies to restrict which relays may connect.

The supported options include mutual TLS, where both sides prove their identities using digital certificates; static service credentials, fixed credentials used by software; and custom external logic, checks supplied by another system. These controls address abuse without requiring the gateway to take over the relay's view of the user.

Cloudflare also describes a safeguard against customers accidentally placing both sides of the privacy boundary with the same provider. Its gateway refuses to decrypt requests originating from Cloudflare Workers, its application-running platform, or from hosts whose traffic is proxied through Cloudflare. The stated purpose is to prevent Cloudflare from seeing both client identities and decrypted inner requests.

For businesses assessing how to keep these responsibilities separate, AEU-I provides security-first IT, infrastructure and consulting, services relevant to reviewing a privacy-sensitive application design.

The supplied announcement ends partway through a comparison of Cloudflare OHTTP Gateway and Cloudflare OHTTP Relay, so it does not establish the full selection guidance or commercial terms. What it does describe is a managed gateway with key handling, relay authentication and restrictions intended to preserve separation of trust. For application owners, that separation is the core requirement to check, not simply whether traffic is encrypted.