Cloudflare OHTTP Gateway cierra su beta y renombra Privacy Gateway a OHTTP Relay

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 29 Visitas 9 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Cloudflare cierra la beta de OHTTP Gateway y renombra Privacy Gateway a OHTTP Relay: qué cambia para tu backend

El 5 de octubre de 2026, Cloudflare anunció el cierre de la beta cerrada de su nuevo Cloudflare OHTTP Gateway y, en el mismo movimiento, renombró el producto que lanzó en 2022 — Privacy Gateway — a Cloudflare OHTTP Relay. El cambio no es cosmético: cierra una pieza que faltaba en el protocolo OHTTP (RFC 9458) y separa oficialmente dos roles que antes se confundían bajo un mismo nombre. Si hosteas un backend detrás de Cloudflare o estás construyendo una app de salud, finanzas o identidad digital, esto te toca de cerca.

Qué es OHTTP y por qué importa

Oblivious HTTP (OHTTP) es un estándar del IETF publicado como RFC 9458 que añade una capa de privacidad sobre HTTP tradicional. La idea es simple: el cliente cifra la petición antes de salir, un intermediario ciego (el relay) la reenvía sin poder verla, y solo un segundo actor (el gateway) descifra y entrega al backend.

El resultado: el backend nunca ve la IP del cliente final. El relay nunca ve el contenido. Cada actor ve solo lo que le corresponde. Es el mismo principio que Apple Private Relay o iCloud Private Relay, pero estandarizado como protocolo abierto y construido sobre HPKE (RFC 9180), un esquema de cifrado de clave pública híbrido.

Casos de uso que ya están en producción: Flo Health usa OHTTP para su modo anónimo de tracking de períodos, Apple LiveCallerID lo usa para que apps de identificación de llamadas no sepan qué usuario pidió cada lookup, y Apple Private Cloud Compute desasocia las peticiones de inferencia de IA de la identidad del usuario final. Todos son escenarios donde el backend necesita procesar datos sensibles sin construir un perfil rastreable del cliente.

Qué cambió el 5 de octubre

Cloudflare llevaba cuatro años operando el rol de Relay. Lo que faltaba era ofrecer el rol de Gateway también como servicio gestionado. Antes del anuncio, los clientes que querían desplegar OHTTP tenían dos opciones:

Usar el Relay de Cloudflare y montar su propio Gateway en infraestructura propia — viable si tus servidores están fuera de Cloudflare.
Usar un Relay de terceros y montar también tu propio Gateway — viable si tus servidores ya viven dentro de Cloudflare (CDN o Workers).

Ninguna opción era cómoda. Operar un Gateway en producción significa mantener claves HPKE rotativas, validar encapsulaciones binarias según IANA, autenticación de relays upstream, y cumplir con la separación de confianza del protocolo (relay y gateway no pueden ser operados por la misma entidad, porque entonces esa entidad ve IP + contenido).

Con la beta cerrada de Cloudflare OHTTP Gateway, Cloudflare ofrece ahora ambos roles como productos diferenciados:

Producto	Antes	Ahora	Cuándo conviene
Cloudflare OHTTP Relay	Privacy Gateway	OHTTP Relay (closed beta)	Tu backend está fuera de Cloudflare y quieres cifrar, entregás sin ver IP del cliente
Cloudflare OHTTP Gateway	No existía	OHTTP Gateway (closed beta, otoño 2026)	Tu backend está dentro de Cloudflare (CDN/Workers) y quieres recibir OHTTP de relays de terceros
Combinación	Imposible bajo un mismo vendor	Posible: usas tu propia infra en el rol faltante	Si tu backend está en Cloudflare, no puedes usar el Relay de Cloudflare (rompería la separación)

Cómo funciona OHTTP técnicamente

Una petición HTTP normal expone, como mínimo, los siguientes datos del cliente al servidor:

ipAddress: 192.0.2.33
ASN: 7922
tlsCipher: AEAD-CHACHA20-POLY1305-SHA256
tlsVersion: TLSv1.3
Country: US
Region: California
City: Campbell

Cuando esa misma petición viaja por un relay OHTTP, el backend solo ve los metadatos del relay, no del cliente:

ipAddress: 128.62.37.13
ASN: 18
tlsCipher: AEAD-AES-128-GCM-SHA256
tlsVersion: TLSv1.3
Country: US
Region: Texas
City: Austin

El relay ve ciphers IP y fingerprint TLS del cliente, pero no puede ver el contenido. El gateway ve el contenido descifrado, pero no puede ver la IP del cliente. La clave HPKE la publica el gateway en su endpoint GET /.well-known/ohttp-gateway y rota automáticamente; el cliente la descarga por una IP distinta a la que después usará para enviar la petición, lo que dificulta correlación.

Cómo se habilita Cloudflare OHTTP Gateway

El setup vive en la zona DNS de tu dominio dentro de Cloudflare. Una vez que Cloudflare te aprueba en la waitlist, habilitas el Gateway como add-on pagado y la pasarela queda escuchando en una ruta estándar:

# Endpoint público donde los relays envían las requests OHTTP
GET https://your-zone.com/.well-known/ohttp-gateway
# Descargar la configuración de claves HPKE
curl -s https://your-zone.com/.well-known/ohttp-gateway | jq .

El gateway intercepta cada petición OHTTP, descifra, emite una sub-request HTTP plano a tu app server, y devuelve la respuesta cifrada al cliente. Las peticiones no-OHTTP siguen su ruta normal sin tocar el gateway. La integración con Cloudflare Access corre antes del descifrado: puedes exigir mTLS, credenciales de servicio estáticas, o políticas Zero Trust sobre el relay antes de que el gateway descifre nada.

Cloudflare soporta tanto OHTTP estándar como chunked OHTTP (draft draft-ietf-ohai-chunked-ohttp-08). Chunked permite procesar el cuerpo en fragmentos incrementales, lo que reduce latencia de primer byte en respuestas largas. Para producción, chunked es lo recomendado.

Por qué la separación de confianza no es opcional

El modelo de privacidad del protocolo exige que relay y gateway sean operados por entidades independientes. Si la misma entidad corre ambos roles, podría correlacionar la IP del relay con el contenido descifrado del gateway — anulando la garantía. Para evitar que un cliente rompa esto por accidente, Cloudflare añadió una salvaguarda interesante:

El Gateway se niega a descifrar peticiones que lleguen desde Cloudflare Workers o desde hosts proxied dentro de Cloudflare. Si las dos puntas viven dentro de la misma red, el relay y el gateway comparten operador, y el protocolo deja de tener sentido.

Esto cierra un agujero que otros proveedores de privacy proxy vacíos ya tropezaron. La lógica es: si vas a usar el Relay de Cloudflare, tu gateway tiene que correr fuera de Cloudflare. Si tu gateway está dentro de Cloudflare, tu relay tiene que ser de otra empresa o auto-hospedado. No hay atajos.

Cuándo te conviene este producto (y cuándo no)

Conviene si:

Eres un desarrollador de app de salud, finanzas, identidad o cualquier vertical donde el modelo de negocio depende de no construir perfiles de usuario.
Tu backend ya vive detrás de Cloudflare CDN o Workers y quieres aceptar peticiones de relays de terceros como Apple.
Quieres privacidad de red sin tener que operar tu propia criptografía HPKE ni la rotación de claves.
Quieres integrarte con Apple LiveCallerID u otros SDKs que esperan un gateway OHTTP compatible.

No conviene si:

Tu problema real es el fingerprinting del cliente en el cuerpo HTTP (no la IP). OHTTP solo protege metadata de transporte, no el payload. Si sigues mandando email del usuario en el cuerpo, OHTTP no te sirve de nada.
Tu volumen es bajo y mantener un gateway casero te sale más barato que pagar el add-on de Cloudflare.
necesitas auditoría criptográfica verificable de extremo a extremo. Un gateway gestionado es un componente de confianza delegado; si tu amenaza es contra el propio proveedor, no hay solución técnica que valga.
operas en una jurisdicción donde Cloudflare no tiene presencia o tiene obligaciones legales de entregar datos. OHTTP no te protege contra una orden judicial.

El ángulo crítico: el modelo de privacidad tiene asunciones no triviales

La separación de confianza entre relay y gateway asume que ambos son honestos pero curiosos (honest-but-curious): siguen obedecerán lo que el protocolo dicta, pero registrarían datos si pudieran correlacionarlos después. El protocolo los hace no querer correlacionar, no les impide físicamente hacerlo.

En una discusión en Hacker News sobre el anuncio, varios lectores plantearon el caso obvio: si Cloudflare opera ambos productos en la misma organización, un insider con acceso a logs podría correlacionar peticiones. La respuesta formal de Cloudflare es que cada producto corre en infraestructura con accesos y telemetría separados. Es una promesa operacional, no una garantía criptográfica. Para casos donde la amenaza es un insider del propio proveedor, OHTTP no alcanza.

Cómo empezar a probar

Hoy, los dos productos están en closed beta. Para entrar a la waitlist, el formulario oficial está en cloudflare.com/lp/privacy-edge. Si te aprueban, vas a poder:

Habilitar el OHTTP Gateway como add-on en tu zona dentro del dashboard de Cloudflare.
Implementar un cliente OHTTP con la librería de referencia en GitHub o las alternativas de la comunidad: Go, Rust, JavaScript/TypeScript.
Apuntar tu cliente al endpoint https://your-zone.com/.well-known/ohttp-gateway y dejar que Cloudflare gestione las claves HPKE.
Probar la integración con pvcli, el cliente CLI open source de Cloudflare para testing y debugging de OHTTP.

El backend NO necesita modificarse: cuando el gateway descifra la petición, lo que le llega al backend es HTTP plano. Tu app sigue hablando el mismo protocolo de siempre.

Conclusión

El anuncio del 5 de octubre de 2026 consolida a Cloudflare como el primer proveedor hyperscale que ofrece ambos roles del protocolo OHTTP como servicio gestionado, lo que baja la barrera de entrada para que cualquier equipo con un dominio en Cloudflare pueda empezar a recibir peticiones cifradas contra su backend sin tener que mantener claves HPKE ni la criptografía del gateway. El rename a OHTTP Relay también clarifica la nomenclatura del espacio, que estaba confusa entre “Privacy Gateway” (relay) y “gateway” (gateway), y eso solo ayuda a quien aterrice por primera vez en el estándar.

Para equipos que están construyendo infraestructura de privacidad en 2026, vale la pena mirar la beta. Para casos donde el backend es OVPN clásico y no necesitas este nivel de privacidad, OHTTP es probablemente overkill — un buen WAF y TLS mutuo siguen cubriendo el 95% de las necesidades reales.

Preguntas frecuentes

¿Por qué Cloudflare OHTTP Gateway cierra su beta y renombra Privacy Gateway a OHTTP Relay es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Cloudflare OHTTP Gateway cierra su?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Cloudflare OHTTP Gateway cierra su?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Cloudflare OHTTP Gateway cierra su y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Cloudflare OHTTP Gateway cierra su?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.