kind-family-60542
02/27/2026, 3:57 PMerror: "Get "<https://dialpad-agentic-prod-bw8727ri.livekit.cloud/rtc/validate?version=2.10.0&protocol=16&&auto_subscribe=1&sdk=go&os=linux>": dial tcp 161.115.180.66:443: i/o timeout"
httpResponse: null
What's the reason? did anything change recently?tall-airline-16756
02/27/2026, 3:57 PMtall-airline-16756
02/27/2026, 3:57 PM<https://dialpad-agentic-prod-bw8727ri.livekit.cloud/rtc/validate>
That error points to a network connectivity problem between your Go process and the LiveKit Cloud endpoint, not a token generation bug in the SDK. Below are clear checks and actions to help identify and resolve it.
1) Quick connectivity checks (run from the same host/container where your app runs)
• Test HTTPS reachability:
curl -v <https://dialpad-agentic-prod-bw8727ri.livekit.cloud/rtc/validate>
• Test TCP to port 443:
telnet dialpad-agentic-prod-bw8727ri.livekit.cloud 443
• Verify DNS:
nslookup dialpad-agentic-prod-bw8727ri.livekit.cloud
If any of these fail or hang, the issue is network/DNS related.
2) Common root causes to inspect
• Outbound traffic to *.livekit.cloud (TCP 443) is blocked by a firewall, security group, corporate gateway, or cloud provider rules.
• A proxy, NAT, or deep-packet-inspection appliance is interfering with TLS/SNI.
• Transient routing or DNS resolution problems from your environment.
• Local iptables/container network rules blocking outbound connections.
3) Immediate mitigation steps
• Ensure outbound access to port 443 for *.livekit.cloud from the host running your Go app.
• If you use an HTTP proxy, make sure your Go HTTP client is configured to use it.
• If you have strict egress rules, whitelist the LiveKit hostname(s) or underlying IPs used by your region.
• Restart the host/container network stack or DNS resolver if you suspect transient issues.
• Add simple retry with exponential backoff around token/network calls to recover from short-lived network blips.
4) Media-specific note This error occurs during signaling/validation (HTTPS). For media connectivity problems you can additionally force TURN (relay) via your WebRTC config to help in restrictive networks, but that won’t fix the HTTPS timeout itself.
5) If you want, I can help further — please share:
• Whether these timeouts are coming from a single host or multiple hosts/regions.
• Results of the curl/telnet/nslookup commands above (success/failure and any output).
• Whether your environment is behind a corporate proxy, firewall, or cloud egress filter.
Once you share those details I’ll guide you through next steps tailored to your environment.