The Dashboard connects to the external-controller API. Failures usually involve the listening address, port, secret, CORS, reverse proxy, or firewall. First verify the control address and port locally, then configure the Dashboard with the same secret. Add HTTPS and access control only after local access works.
How do connection refused, unauthorized, and CORS differ?
connection refused means the interface is unreachable, unauthorized means it responded but authentication failed, and CORS is a browser cross-origin restriction.
- Is external-controller enabled and listening on the correct address?
- Is the port 9090 or the port actually configured by the client?
- Does the secret entered in the Dashboard match the configuration?
- Does the browser console or log show unauthorized, connection refused, or CORS?
Align the control address, port, and secret
- First confirm that the client or core is running
- Open 127.0.0.1 with the control port locally and confirm that the API responds
- Set the Dashboard API address and secret to the current configuration values
- If the port is occupied, change the external-controller port and update the Dashboard(See External Controller, Port Conflict FAQ)
- For remote access, add access control and HTTPS before opening it to a trusted network
9090 is only a common example; use the port in your configuration
An empty secret increases control-interface risk
Do not expose external-controller directly to the public Internet
How to confirm that the Dashboard is restored
- The interface is reachable and authentication works
- The control address returns version information, and the Dashboard can read nodes and connections with the same secret.
- It still reports refused or unauthorized
- Distinguish connection refused from unauthorized, then inspect the listening address, port, secret, and request headers accordingly.