#7543·netbird

QUIC relay behind reverse proxy (Traefik) on self-hosted combined server — officially unsupported?

Author: NetHorrorCreated Sep 15, 2026Updated Sep 17, 2026

Hi team,

We run a self-hosted NetBird instance using the combined netbird-server image (management + signal + relay + STUN) behind Traefik, which terminates TLS for everything on 443 and forwards to the container over plain HTTP internally (standard Traefik-fronted self-hosted setup, matching the docs at docs.netbird.io/selfhosted/external-reverse-proxy).

We benchmarked relay transport on an isolated test stand (unrelated to this production instance) and measured ~3.6x higher throughput with QUIC vs WebSocket (20 MB/s vs 5.6 MB/s over the same WAN link). Naturally we'd like to get QUIC working on our production relay too.

From reading the source (combined/cmd/root.go), it looks like the combined image's relay component only ever calls relaySrv.RelayAccept() to multiplex over the shared HTTP handler — it never calls relaySrv.Listen(), so no QUIC listener is ever started, regardless of TLS configuration. QUIC only appears to be reachable via the standalone relay binary/image, which needs to terminate its own TLS and open its own port — i.e., a topology that bypasses the reverse proxy entirely for the relay component.

We also found the open issue #4472, which touches on relay-behind-reverse-proxy but is entirely about WebSocket connectivity bugs (Nginx headers, Docker port forwarding) rather than QUIC — no discussion of QUIC/UDP support there.

Questions:

  1. Is there any officially supported way to get QUIC relay working in a Traefik-fronted (or any reverse-proxy-fronted) self-hosted deployment using the combined image, short of switching to a standalone relay container with its own certificate/port outside the proxy?
  2. If the standalone-relay-with-dedicated-port approach is the only path, is there a reference/documented example of running it alongside a Traefik-fronted combined server (cutover via server.relays.addresses), including how peers/clients discover and prefer QUIC vs WS in that setup?
  3. Is there a plan to support QUIC transparently in the combined image regardless of front-end proxy (e.g. via ALPN/protocol detection on the shared listener), or is standalone-relay-with-own-TLS-termination expected to remain the only way to get QUIC?

Thanks for any guidance — happy to share our exact compose/config if useful.