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.

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.

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.

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 or engine-side mTLS configuration.

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.

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.

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.