The LiveKit agent deployed to LiveKit Cloud fails to connect to rooms. The worker process registers successfully, but the job subprocess cannot establish a room connection due to an HTTP request failure when fetching region settings.

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

Response to LiveKit Support 1. Exact HTTP Error The error message from job subprocess logs: room_connect_failed: "engine: signal failure: failed to retrieve region info: error sending request for url (

https://<ID>.livekit.cloud/settings/regions

)" The error is a generic "error sending request" - no HTTP status code is returned, suggesting the request never completed (likely DNS resolution or connection failure, not a 4xx/5xx response). 2. URL Being Requested

https://<ID>.livekit.cloud/settings/regions

3. Deployment Configuration livekit.toml: [project] subdomain = "`<ID>`" [agent] id = "`<AGENT_ID>`" region = "us-east" Deployed using: lk agent deploy out --secrets-file apps/agent/.env 4. Environment Variables Yes, all are set and passed via --secrets-file: - LIVEKIT_URL=

wss://<ID>.livekit.cloud

- LIVEKIT_API_KEY=<LIVEKIT_API_KEY> - LIVEKIT_API_SECRET=* (set) 5. Network Restrictions This is LiveKit Cloud managed hosting - we do not control the network configuration. The agent is deployed to LiveKit Cloud using lk agent deploy, not self-hosted. Key observation: The worker process connects successfully to LiveKit Cloud, but the job subprocess (spawned to handle a room) cannot make the HTTP request to /settings/regions. Additional Context - SDK versions:

@LiveKit/agents@1.0.27

,

@LiveKit/rtc-node@0.13.22

- The native Rust library (rtc-node FFI) is making the HTTP request - MCP connections to external servers (AWS ALB) work from the job subprocess

Thanks — this is helpful. I’m responding to the job subprocess failing to fetch region settings at

https://<ID>.livekit.cloud/settings/regions

with a generic “error sending request” (no HTTP status), while the worker process remains connected. Given what you’ve shared, the most likely causes are DNS resolution or connection failure for the subprocess environment, or the subprocess lacking access to the same network path/credentials the worker uses. Here are focused next steps to pinpoint and fix the issue: 1) Capture the subprocess runtime logs (full error + stack) • Please paste the 10–20 log lines immediately before and after the

room_connect_failed

error. That will show DNS or dial errors (e.g., “lookup … no such host” or “connect: connection refused / network unreachable”). 2) Verify DNS resolution from the job subprocess context • Run a DNS lookup from the same execution context the job uses. If you can’t run commands in the subprocess, share the subprocess logs that show name resolution attempts. Look for logs indicating DNS failure vs TLS/connection failure. 3) Confirm the subprocess can reach the HTTPS endpoint • You reported MCP connections to external servers work, so try to confirm an outbound HTTPS connection specifically to the livekit subdomain from the job subprocess. The exact command to run depends on the environment, but the check we need is: ◦ Does the subprocess successfully open an outgoing TLS connection to

https://<ID>.livekit.cloud

? 4) Re-check env visibility in the subprocess • Although you pass secrets via

--secrets-file

, confirm the subprocess inherits

LIVEKIT_URL

exactly as

wss://<ID>.livekit.cloud

and not an internal or differing host. Any mismatch could cause the subprocess to attempt a different HTTP host. 5) Compare worker vs job subprocess environment • Provide any differences you see between the worker process environment and the job subprocess environment (especially DNS, proxy, or environment variables). If you can capture and share the env dump from both (redact secrets), that will help identify missing variables or proxy settings. 6) If logs show TLS handshake or certificate errors • Share the TLS error text. TLS failures differ from DNS/connect failures and point toward SNI, certificate verification, or client TLS config issues. What I can do after you share logs/env diffs: • If logs show DNS/dial errors: provide exact checks and remediation steps for DNS or egress connectivity from the job subprocess. • If logs show TLS errors: provide targeted TLS/SNI troubleshooting steps. • If the subprocess environment is missing required env variables or has a different host: give steps to ensure secrets are injected into the job subprocess. Please paste the requested log block (around the error) and an env diff (redact secrets). I’ll analyze and give exact commands and fixes to run.