Thanks — I hear you: the failing GET to https://<subdomain>.livekit.cloud/settings/regions is causing intermittent

room.connect()

failures and repeated retries keep failing. Below are practical mitigations you can apply quickly and diagnostics to narrow the root cause. Recommended mitigations (fast wins) • Bypass region detection and connect directly to your project URL. Use your project's WebSocket URL (for example

wss://<subdomain>.livekit.cloud

) when calling

room.connect()

so the client skips the regions fetch entirely. This removes dependence on the failing endpoint. • Implement retry with exponential backoff when you must call the regions endpoint. Don’t retry immediately — use increasing delays (for example 200ms → 500ms → 1s → 2s) and cap the number of attempts to avoid tight retry loops. • Cache the regions result client-side for a short TTL (e.g., a few minutes). If the cached region is available, use it rather than re-fetching on every connect attempt. • Add a fallback region or a fallback URL. If the region fetch fails, fall back to a known-good region or the direct project URL so the user can still connect. Diagnostic steps (to find a root cause) • Confirm whether failures are global or limited to certain networks/clients: ◦ Ask affected users to try different networks (cellular vs. corporate Wi‑Fi). ◦ Check if a particular ISP or geographic area shows more failures. • Check DNS resolution and network path to

<subdomain>.livekit.cloud

from failing clients: ◦ On web: open DevTools → Network and inspect the GET to

/settings/regions

for status code, response time, and CORS errors. ◦ From a terminal: run

nslookup <subdomain>.livekit.cloud

and `traceroute`/`ping` (or

tracert

on Windows) to look for DNS or routing problems. • Look for client-side errors that prevent the request (CORS, mixed content, blocked by browser extension, or ad blockers). • If failures are persistent only for some users, inspect local firewall/proxy or corporate content filtering which may block that specific endpoint. Instrumentation & logging (helpful for ongoing troubleshooting) • Log the full response/error for the

/settings/regions

request (status code, error message, timing). • Record environment info with each failure (browser/OS, network type, client SDK version). • Track whether the same client repeatedly fails — that points to local network/DNS rather than server-side transient errors. Short-term approach I recommend 1. Immediately switch your client to connect using

wss://<subdomain>.livekit.cloud

for user-facing flows to stop failures. 2. Add client-side caching of the region result (short TTL) and exponential backoff for any necessary region fetches. 3. While the above reduces user impact, collect logs from failing clients (network traces, status codes) and run the connection test utility to help diagnose whether DNS, firewall, or routing is the root cause. If you want, share: • whether failures are seen across many users or only a subset, • a sample network error message or the DevTools Network response for the

/settings/regions

request, and I’ll suggest targeted next steps for diagnostics or configuration changes. Sources: server-sdk-go | livekit/livekit_composite | DeepWiki | server-sdk-js | livekit/livekit_composite | DeepWiki | client-sdk-js | livekit/livekit_composite | DeepWiki | Diagnosing Connection Errors with the Connection Test Utility | LiveKit