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 edge authentication and request-level semantics. The other protocols are intended for non-HTTP traffic and custom protocols, and they rely primarily on transport-level controls such as mutual TLS.

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 enabled listeners.

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/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. See Connection Upgrades for setup details and Go SDK examples.

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.

TLS passthrough cannot be combined with server-side TLS policy fields such as TLS minimum version, engine-side mTLS configuration, custom ALPNs, or upstream TLS.

DTLS and QUIC

DTLS and QUIC support datagram-oriented traffic. These protocols are useful for real-time applications and for custom protocols that do not map to HTTP.

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.

QUIC tunnels always use upstream TLS 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.

Support depends on enabled listeners. In the community edition engine build, QUIC and DTLS listeners are disabled in the runtime wiring. In enterprise builds, QUIC and DTLS can be enabled through configuration. In the current plan matrix, published DTLS and QUIC tunnels are available on Pro and Enterprise projects.

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.

Mutual TLS

Mutual TLS can be used as a strong client authentication mechanism for non-HTTP protocols. When enabled, the engine requires clients to present a certificate that validates against the configured CA bundle.