3.2 KiB
HTTP transport, TLS, HTTP/2 and HTTP/3
RustProxy distinguishes frontend client protocols from the upstream protocol used to contact an application. Selecting HTTP/3 on a listener does not require an HTTP/3 backend.
Frontend listeners
- HTTP/1.1: default plaintext HTTP and standard Upgrade-based WebSocket support where enabled.
- HTTPS / HTTP/2: TLS listeners may negotiate HTTP/2 and HTTP/1.1. Settings include H2 idle/connection-drain controls.
- HTTP/3 (QUIC): optional UDP transport on an enabled TLS frontend, using the listener certificate and supported H3 settings. The host firewall/NAT must pass UDP on the actual HTTPS port, not only TCP/443. Browsers can fall back to H2/H1 when H3 is unavailable.
- H2C: explicit cleartext HTTP/2 capability only where the listener or upstream policy enables it; it is not ordinary browser HTTPS.
Transport settings attach to named listeners, and a Vhost must select the appropriate listener IDs. Addresses locked by CLI/systemd startup cannot be rewritten from the panel. Changing a listener bind or startup-owned TLS option may require a restart.
Backend protocol selection
| Backend mode | HTTPS origin | Plain HTTP origin |
|---|---|---|
http1 |
HTTP/1.1 | HTTP/1.1 |
auto |
ALPN H2 or H1 | HTTP/1.1 |
Legacy http2 |
Compatible ALPN H2/H1 | H2C |
Strict h2 |
Requires H2 | Requires H2C |
WebSockets normally use HTTP/1.1 Upgrade. HTTP/2/HTTP/3 client requests can still reach HTTP/1.1 backends when the selected bridge/path is supported; do not assume the frontend and origin protocol always match. HTTP/2 GOAWAY, H3 stream cancellation and retries are constrained to safe lifecycle cases. Use backend protocol telemetry and logs when diagnosing negotiation.
TLS and trust
Public HTTPS requires a correct certificate with hostname coverage. Administration TLS is separate. Backend https:// encrypts traffic, but upstream certificate verification is opt-in by default in the current backend model; enable it and specify CA/name where needed. Private/loopback addresses and routing to a local RustProxy listener require explicit risk overrides.
Timeouts, request bodies and streaming
Idle/read/connect/response-header timeouts and backend connection pools are configurable. A response may stream after its headers have arrived; response-header metrics are not full-body duration. WebSockets and Streams have separate idle lifetimes and should be tested with the actual application. RustProxy rejects suspicious ambiguous request targets rather than normalizing them into potentially unsafe backend paths.
Troubleshooting
- HTTPS works but H3 does not: check UDP firewall/NAT, listener H3 enablement, TLS certificate, network middleboxes and actual browser negotiation.
- 502 / protocol error to backend: verify origin supports selected
auto,http2,h2or H2C mode and the correct TLS hostname/verification policy. - WebSocket disconnects: enable websocket forwarding in the Vhost and ensure idle limits/proxy/backend are compatible.
- Unexpected HTTP→HTTPS redirect: inspect Vhost
force_ssl, selected listeners and actual public scheme.
For listener configuration see Configuration; for safer deployment see Security.