Advanced Options

Most HTTP tunnels work well with the defaults: the engine exposes an HTTP endpoint and forwards upstream requests to a local HTTP server over http/1.1. Advanced options become relevant when the upstream service requires a specific HTTP version or when upstream TLS is required.

Upstream HTTP version

The upstream HTTP version can be set to http/1.1, h2c, or h3. When no upstream version is set and upstream TLS is disabled, the engine defaults to http/1.1.

h2c uses cleartext HTTP/2 to the upstream service. h3 uses HTTP/3 and requires the tunnel type to be set to datagram; this is the upstream version used for WebTransport tunnels.

In the CLI, the upstream version is configured with --http-version.

Upstream TLS

Upstream TLS enables TLS between the engine and the upstream service. This is configured with --upstream-tls. The older --http-use-tls flag is still accepted for compatibility, but new configs should use --upstream-tls.

When upstream TLS is enabled, the engine establishes a TLS connection to the upstream service and lets the HTTP client stack negotiate HTTP/1.1 or HTTP/2 over that connection. Setting an explicit upstream HTTP version together with upstream TLS is not supported except for h3, which requires upstream TLS.

The tls_alpns tunnel property is not used for HTTP tunnels. HTTP ALPN is derived from the HTTP mode: HTTPS accepts HTTP/2 and HTTP/1.1 at the edge, while HTTP/3 uses h3.

Edge authentication and challenge

HTTP tunnels expose --token-auth, --rstream-auth, and --challenge-mode. These options are described in the Authentication and Challenge Mode pages.

Related TLS options

The CLI also exposes TLS options such as --tls-min-version, --tls-ciphers, and mTLS settings. Those options apply to non-HTTP tunnel protocols and are documented in Tunnel Protocols.