Tunnel Protocols

The tunnel protocol describes what the engine exposes on the public endpoint and how inbound traffic is handled before it reaches the upstream service. rstream models four protocol families: HTTP, TLS, DTLS, and QUIC.

HTTP tunnels are the most feature-complete option and support request-level semantics, browser-oriented flows, WebSocket, plain CONNECT for TCP forward proxying, WebTransport, and MASQUE protocols such as CONNECT-UDP and CONNECT-IP. TLS, DTLS, and QUIC tunnels cover protocol-native connectivity when the upstream application should keep its own protocol instead of being mapped into HTTP.

This page describes published tunnel protocols. The separate client-to-edge transport layer is covered in Tunnel Transports.

Protocol availability depends on the engine edition and project plan.

HTTP

HTTP tunnels are documented in HTTP Tunnels. They support upstream version selection (http/1.1, h2c, h3) and can enforce token authentication and rstream auth at the edge.

HTTP tunnels support WebSocket across all three upstream versions. On H1 and H2C upstreams the engine relays the standard upgrade handshake and the resulting bidirectional byte stream to the upstream service with no special configuration. On H3 upstream the engine uses Extended CONNECT over QUIC, which requires an HTTP/3-aware upstream server.

HTTP tunnels also support plain authority-form CONNECT for upstream forward proxy services. The engine forwards CONNECT host:port to the upstream proxy and relays bytes only after a 2xx response. Routing is bound to the tunnel selected by the downstream connection, not to the target authority, and reused HTTP/2 or HTTP/3 connections cannot mix reverse HTTP traffic with proxy egress traffic.

HTTP/3 (h3) tunnels also support WebTransport. The engine accepts WebTransport sessions using the Extended CONNECT mechanism, establishes a matching session with the upstream HTTP/3 service, and relays bidirectional streams, unidirectional streams, and datagrams between the two sessions. All HTTP-level authentication features — token auth, rstream auth, and access policies — apply to WebTransport sessions.

Published HTTP/3 datagram tunnels can also carry CONNECT-UDP and CONNECT-IP. These MASQUE protocols use HTTP Extended CONNECT, HTTP Datagrams, and the Capsule Protocol to proxy UDP payloads or IP packets through an HTTP tunnel. The upstream service remains responsible for UDP target handling, DNS resolution, IP route assignment, packet validation, and forwarding policy. See Connection Upgrades for setup details and Go SDK examples.

References:

HTTP semantics RFC 9110, HTTP/2 RFC 9113, HTTP/3 RFC 9114, WebSocket RFC 6455, HTTP Datagrams and capsules RFC 9297, CONNECT-UDP RFC 9298, CONNECT-IP RFC 9484.

TLS

TLS tunnels accept a downstream TLS connection and forward traffic to an upstream service. The engine supports two TLS modes: termination and passthrough.

In terminated mode, the engine terminates TLS at the edge and forwards plaintext to upstream. The agent-to-engine transport remains encrypted regardless of this setting.

When upstream TLS is enabled, the engine terminates downstream TLS at the edge and then establishes a new TLS connection to the upstream service. This is useful when the upstream service expects TLS even though the tunnel is edge-terminated.

In passthrough mode, the engine forwards the TLS connection to upstream without terminating it. In this mode, the upstream service is responsible for presenting a certificate that satisfies the client, and any TLS policy must be enforced by that upstream service.

TLS passthrough cannot be combined with engine-side TLS features such as edge mTLS, custom ALPN handling, or upstream TLS. Project-wide TLS settings that apply to edge-terminated surfaces do not change the behavior of passthrough tunnels because the edge does not terminate the TLS session.

References:

TLS 1.2 RFC 5246, TLS 1.3 RFC 8446, ALPN RFC 7301.

DTLS

DTLS tunnels expose datagram-oriented traffic over DTLS. They are useful for UDP-style protocols that need TLS-like protection but do not map naturally to HTTP or WebTransport.

DTLS tunnels terminate DTLS at the edge and forward datagrams upstream by default. With upstream TLS enabled, the engine establishes upstream DTLS to the publishing client and preserves the downstream ALPN when one was negotiated.

DTLS currently remains separate from the post-quantum and ECH policies that require TLS 1.3 on edge-terminated surfaces. Those project policies are documented in Access Policies.

References:

DTLS 1.2 RFC 6347, DTLS 1.3 RFC 9147, ALPN RFC 7301.

QUIC

QUIC tunnels expose raw QUIC applications through the edge. They are distinct from HTTP/3 tunnels: HTTP/3 is documented under HTTP Tunnels, while a QUIC tunnel is for a custom QUIC application protocol with its own ALPN.

QUIC tunnels always use upstream TLS semantics because QUIC is built on TLS 1.3. When a custom ALPN list is configured, the edge negotiates from that list and reuses the negotiated ALPN toward the upstream QUIC service. Without a configured list, the edge preserves the downstream client's QUIC ALPN.

Published QUIC requires an application ALPN to be negotiated. This makes protocol selection explicit and allows the upstream QUIC service to see the same application protocol selected by the downstream client.

References:

QUIC transport RFC 9000, QUIC TLS RFC 9001, ALPN RFC 7301.

Other application protocols

The tunnel protocol is the public transport shape exposed by rstream, not a fixed list of application protocols. Any application protocol can be carried when it fits an available tunnel type and edge protocol.

For example, SCTP-based application protocols can run over datagram tunnels and can be exposed through DTLS when a published encrypted datagram endpoint is needed. gRPC can run over a bytestream or TLS tunnel, or through an HTTP/2-capable HTTP tunnel when HTTP-aware edge behavior is required. The same model applies to other protocol-native workloads: the rstream tunnel type and public protocol define the transport shape, while the application protocol remains unchanged.

References:

SCTP RFC 9260.

Availability

Community Edition supports HTTP and TLS tunnels. QUIC and DTLS are not supported on Community Edition.

On managed projects, plain CONNECT follows the HTTP version support available to the runtime. Published DTLS tunnels, published QUIC tunnels, HTTP/3 upstream, WebTransport, CONNECT-UDP, and CONNECT-IP are available on Pro and Enterprise projects when the corresponding runtime listeners are enabled.

Custom ALPNs

The tls_alpns tunnel property configures the ALPN values advertised by published TLS, DTLS, and QUIC tunnels. In the CLI this is exposed as --tls-alpn.

Custom ALPNs are for non-HTTP published protocols. HTTP tunnel ALPN is managed by the HTTP version behavior: HTTP/1.1 and HTTP/2 are negotiated on the HTTPS edge, and HTTP/3 uses h3.

When upstream TLS is enabled for TLS or DTLS, the engine uses the downstream negotiated ALPN for the upstream handshake. If no ALPN was negotiated, it falls back to the configured ALPN list. QUIC uses the same preservation model and requires an application ALPN to be negotiated.