Online agent, failing live panels

Confirm which path is failing

An Online record means the agent registered with signaling. A live panel also needs a working browser-to-agent RPC transport.

1. Open Info or Console and record the visible error.
2. Check whether other live panels fail on the same server.
3. Compare another accessible server from the same browser.
4. Check agent connection logs near the failure time.

If the agent is offline, use offline recovery first.

Check network access

Allow the signaling WebSocket host and the required application endpoints. A proxy must support WebSockets. For WebRTC, check STUN and TURN access using network requirements.

Direct WebRTC, TURN-relayed WebRTC, and the signaling relay are separate paths. A relayed connection can be a valid working connection. Use a small live read to verify the result.

For a required direct connection

If your network needs predictable ports, set:

restrictPorts: true
webrtcMinPort: 10000
webrtcMaxPort: 10010

Allow and, where needed, forward the complete inclusive range for TCP and UDP. The address must lead to the agent host, not an unrelated reverse proxy.

If the advertised public address is wrong, set advertisePublicAddress: true and publicAddress to the correct forwarded address. Do not copy an example IP into production.

Apply file changes with enderdash reload on a supported runtime or restart the standalone process. Reopen the panel and verify fresh data.

Distinguish transport from action permissions

If only one action fails while other live reads work, investigate that action's platform permissions, runtime capability, and input. Opening more ports will not fix a Kubernetes Forbidden response or an unwritable file.

See the connection model for the complete path. Include sanitized logs and the failed operation in a support report.