Connection problems

First record the exact error and whether it occurs before connecting, during login, or after chat is already working. A voice failure after successful login follows a different path from a failed control connection.

Check the saved address and identity

Confirm the host and port with the owner. Starling’s maintained deployment uses 64738/TCP for control and 64738/UDP for voice. A web address that opens the administration site is not necessarily the Mumble listener. Select the same certificate identity previously registered on that server.

DNS, timeout, or connection refused

On Windows PowerShell, substitute the owner’s host name:

Resolve-DnsName voice.example.org
Test-NetConnection voice.example.org -Port 64738

On Linux or macOS:

nslookup voice.example.org
nc -vz voice.example.org 64738

Result	Next action
Name does not resolve	Correct the name or ask the owner to fix DNS. Record whether IPv4, IPv6, or both records are returned.
TCP test fails	Ask the owner to check the listener, published port, routing, and firewall. A refusal often means nothing is accepting the connection; a timeout does not identify which network device dropped it.
TCP succeeds but login fails	Continue with credentials, identity, and the displayed certificate/login error. A TCP success does not prove the application handshake succeeded.
Chat works but voice does not	Use the UDP/TCP comparison in Audio problems.

The server owner can check the Compose deployment with:

docker compose ps
docker compose logs --since=10m gateway voice
docker compose config

Check that services are running and the intended TCP and UDP ports are published. If the port is customized, use the same number in the client, firewall, and container mapping. Keep internal gRPC listeners private. See Ports and networking.

Password or account rejected

Do not repeatedly guess passwords. Ask the owner whether the prompt is a server password, registered-user password, or SuperUser login. A registered account can be tied to a client certificate; changing the username alone does not restore that identity. Compare the identity selected in the connection entry with Settings, Identities.

For a new Starling instance, use SuperUser and first login. For a migrated instance, verify the imported account and target instance rather than registering a replacement over it.

Certificate fingerprint changed

Record the host, port, and displayed fingerprint and verify it with the owner. A replaced TLS certificate or a lost data volume can legitimately cause a change, but the dialog cannot establish that by itself. The owner should compare the running gateway certificate with its backup. Preserve the TLS files during upgrades.

Connected, then disconnected

Record how long the session lasted and whether it happens while idle, during voice, or during uploads. Compare the client log and gateway log at the same timestamp. Check whether every member disconnected or only this device. Do not reset identities or delete application data to diagnose a recurring disconnect.

Server fails before it can accept clients

Run docker compose logs for the failing service and read the first startup error. Unknown TOML keys, missing TLS files, storage permissions, and unavailable internal endpoints require different fixes. Compare the configuration with your Starling release’s TOML reference. Do not expose more ports to fix a configuration parse error.

Attach the displayed error, resolved IPs, TCP test result, client/server versions, timestamp, and relevant logs to a bug report. Remove passwords and tokens from exported Compose configuration before sharing it.