LiveKit v1.13.1: Signaling WS drops mid-call with CLIENT_REQUEST_LEAVE + full reconnect (media UDP unaffected) behind Nginx ssl_preread

Self Hosting
1

Hi everyone, I’m trying to diagnose intermittent mid-call signaling reconnects on a self-hosted, single-node LiveKit deployment. The issue is observed on both web and mobile clients. Interestingly, when the drop occurs, the media (UDP) stays perfectly healthy; it’s only the signaling WebSocket that drops and reconnects.
Setup Details
• Infrastructure: Single-node MicroK8s with LiveKit using hostNetwork: true.
• Nginx (1.24.0) Reverse Proxy:
Handling incoming traffic on port :443 inside a stream {} block using ssl_preread for SNI routing.
TURN domain traffic → Passthrough directly to LiveKit (TLS terminated by LiveKit on internal :5349).
Everything else → Internal TLS vhost on :8443 (Nginx TLS) → Forwarded to LiveKit signaling on :7880.
WS vhost configuration: proxy_read_timeout 7d, proxy_buffering off.
• Components & Versions:
LiveKit Server v1.13.1 (Protocol 17), Helm chart 1.9.0
Redis 8.x (Bitnami via Sentinel)
Embedded TURN: tls_port: 5349 (advertised as turns:<domain>:443), udp_port: 3478, relay port range 40000-49999.
RTC: tcp_port: 7881, UDP range 50000-60000, use_external_ip: true.
Symptoms & What We’ve Ruled Out
Mid-meeting, a client randomly drops to a “reconnecting” state and recovers. This happens roughly 5, 10, or 30 minutes into a call—though sometimes a call runs completely fine without any issues.

  • Nginx side: proxy_read_timeout is set to 7d, so there are no idle cutoffs.
  • No Nginx reload or shutdown events are occurring during these windows.
  • LiveKit server logs show no read message error or failed to resume events. Surprisingly, almost all disconnect logs appear as CLIENT_REQUEST_LEAVE (client-initiated), immediately followed by a full reconnect with a brand new token/identity, rather than a session resume.
  • On the web client, we traced some CLIENT_REQUEST_LEAVE events to app-level actions (like explicit page reloads), but the exact same drop-and-reconnect pattern happens on mobile where no such page reloads exist. This leads us to suspect a shared underlying issue at the transport, token, or signaling layer.

Questions

  1. On v1.13.1 / Protocol 17, what specific server-side or token conditions can cause a client to skip a signaling resume entirely, send a CLIENT_REQUEST_LEAVE, and initiate a fresh full reconnect? (e.g., Token TTL expiration/refresh logic, strict ICE restart thresholds, etc.)
  2. Are there any known conflicts when using an embedded TURN server advertised as turns:<domain>:443 behind SNI passthrough while sharing port :443 with the signaling WS traffic?
  3. Is there any known edge case where signaling traffic routed through Nginx ssl_preread combined with a separate internal TLS-terminating vhost causes transient WebSocket drops?
  4. What is the best way to capture the exact server-side TCP/socket close reason to correlate with the client-side SignalReconnecting timestamp? Which components or packages should I bump the log level for?

Happy to share redacted configs or logs if needed. Appreciate any insights!

2

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.