Hi LiveKit team, I've got a consistently failing voice agent on LiveKit Cloud. The agent registers fine but every dispatch fails at ctx.connect() with a region- info fetch error pointing to its own region's settings endpoint. The URL is correctly formed and externally reachable, just not from inside the agent's own container. Confirmed across TWO regions (us-east / oashburn1b AND eu-central / ofrankfurt1b) — so the bug is in @strong-father-34524/rtc-node's Rust HTTP path itself, not region-specific. Project ID: wingman-31s02l4a Failing agents: CA_NXPRnfBrp42t (us-east → oashburn1b, deleted) CA_yaXvLr7HMA9n (eu-central → ofrankfurt1b, current) SDK versions: @strong-father-34524/agents 1.4.0, @strong-father-34524/rtc-node 0.13.27, livekit-server-sdk 2.15.2 (all latest as of 2026-05-11) Node runtime: 22-slim, glibc Both regions, same fail mode: 1. Worker registers OK: { msg: "registered worker", server_info: { region: "US East B" / "Germany 2", nodeId: NC_OASHBURN1B_... / NC_OFRANKFURT1B_... } } 2. Dispatch arrives, requestFunc fires, parseMetadata OK, we accept. 3. ctx.connect() THROWS immediately: engine: signal failure: failed to retrieve region info: error sending request for url (https://wingman-31s02l4a.<region>.production .livekit.cloud/settings/regions) Stack: at Room.connect (file:///app/node_modules/@livekit/rtc-node /dist/room.js50617) at async JobContext.connect (file:///app/node_modules /@strong-father-34524/agents/dist/job.js1525) at async entry (file///app/dist/agent.js87:9) 4. Process exits, worker pool respawns, next dispatch repeats. Verified externally (rules out URL / auth / region-list bugs): - The same URL with the same project Bearer token from my Mac returns HTTP 200 with a valid 6-region list. So the URL is correctly shaped and externally reachable. - Dispatching directly via the Twirp endpoint succeeds (200 + dispatch ID), so token auth + dispatch service are fine. - The fail is at the network layer ("error sending request") inside rtc-node's Rust HTTP client, not at HTTP 4xx/5xx — the request never gets a response. - Same fail in TWO regions = rtc-node SDK bug, not region infra issue. Dispatch IDs today (if helpful): AJ_3jP6fb6GJAU7 (us-east) AJ_PEaw428a7DTy (us-east) AJ_ygPPftYz3KmH (eu-central) AJ_MH8uYsGNhhSp (eu-central) All approx 2026-05-11 between 20:43 and 20:58 UTC. Questions: - Is there a known issue with rtc-node's region-discovery path in ctx.connect() across regions right now? - Is there an SDK flag to bypass region discovery (since the agent is already running in the right region)? - ETA on a fix or workaround? Voice-in-video is the headline feature for our app so this is currently blocking dogfood. Happy to grant project access or share more logs. Thanks! Beibei

Thanks for reaching out, Beibei. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Hi LiveKit AI — answers to your 4 followup Qs. All from inside the current eu-central agent container (CA_Lzjf5UFCxXiU, ofrankfurt1b), captured via Node

https.get

probes added on startup: Q1 — Proxy env vars: ALL UNSET HTTP_PROXY = <unset> HTTPS_PROXY = <unset> NO_PROXY = <unset> http_proxy = <unset> https_proxy = <unset> Q2 — Outbound TLS sanity (google.com): https://www.google.com/ → status=200 time=99ms ✅ (also 82ms, 132ms, 158ms across multiple worker restarts) Q3 — LiveKit URLs reachable via Node `https`: PROJECT URL: https://wingman-31s02l4a.livekit.cloud/settings/regions → status=200 time=11-24ms ✅ REGIONAL URL (us-east): https://wingman-31s02l4a.oashburn1b.production.livekit.cloud/settings/regions → status=200 time=271-310ms ✅ REGIONAL URL (eu-central, current pod region): https://wingman-31s02l4a.ofrankfurt1b.production.livekit.cloud/settings/regions → status=200 time=13-86ms ✅ All four endpoints return HTTP 200 with a valid region list, from inside the same container, AT THE SAME TIME as

Room.connect()

throws "error sending request" for the same URL. So: - Egress is NOT blocked (google.com 200, LiveKit URLs 200) - No proxy injected (env all unset) - The rtc-node Rust HTTP client is the only path failing — Node's stdlib

https

succeeds against the exact URLs rtc-node fails on, in the same process, same container, same network egress Latest repro (dispatch AJ_5pfFvriHqrMw, 2026-05-11T21:54Z): [wm-agent] Room.connect override original=https://wingman-31s02l4a.ofrankfurt1b.production.livekit.cloud using=wss://wingman-31s02l4a.livekit.cloud ctx.connect() THREW: engine: signal failure: failed to retrieve region info: error sending request for url (https://wingman-31s02l4a.livekit.cloud/settings/regions) Stack: Room.connect at /app/node_modules/@livekit/rtc-node/dist/room.js:506 Two follow-ups would unblock us: (1) Confirm this is a known rtc-node Rust HTTP bug and share the GitHub tracking issue or fix ETA, OR (2) Provide an SDK escape hatch — env var, RoomOptions field, or build-time flag — that makes rtc-node either skip the /settings/regions GET or fall back to Node's HTTP client for that one request. The browser-side livekit-client already treats this failure as non-fatal; the same behavior in rtc-node would let our agent join the room without your team shipping a regression fix first. Happy to add more probes if a specific test would help isolate further (e.g., DNS-only, TLS-only, IPv6 vs IPv4, etc). Thanks! — Beibei

Thanks — I see you confirmed from inside the failing container that: • no proxy env vars are set, • general TLS egress works (google.com 200), • Node's

https

can GET both the project and regional /settings/regions URLs (200), • but

ctx.connect()

still fails with "error sending request" from rtc-node's Rust HTTP client. Quick answers to your three asks, and a short next step plan: 1) Is this a known rtc-node Rust HTTP bug? • I cannot confirm a public issue or tracking ticket right now. Your diagnostics strongly indicate the Rust HTTP client inside

@livekit/rtc-node

is failing to send that request while Node’s

https

works — that narrows it to the SDK’s native HTTP path. 2) Is there an SDK flag to bypass region discovery? • There is no documented environment variable or official RoomOptions flag to skip the /settings/regions fetch. 3) ETA or workaround? • Immediate pragmatic workaround: connect directly to the regional websocket URL (bypasses region discovery). Example:

// Use the regional host instead of the project wss endpoint
const regionalUrl = 'wss://wingman-31s02l4a.ofrankfurt1b.production.livekit.cloud';
await room.connect(regionalUrl, token);

This should allow the agent to join the room in-place while we resolve the fetch failure. Next steps I’ll take for you: • I’ll escalate this with your repro details (project, dispatch IDs, SDK versions, and the inside-container probes you ran) so engineering can confirm and open a tracking issue if one doesn’t exist. • Meanwhile, if you want a quicker test I can provide, try forcing the regional URL in your agent code and report whether it reliably connects for the failing dispatches. If you want me to proceed opening the internal issue now, confirm and I’ll include the exact logs/dispatch IDs you listed. Sources: Checklist for Regional Deployments | LiveKit | Diagnosing Connection Errors with Connection Test Utility, with interactive elements

Yes please open the internal issue and include those logs

I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!