Sharkord

Troubleshooting

Voice not working, rate limits, failed uploads, disconnects, and the other common problems.

Check, in this order:

  • You are on HTTPS, or on http://localhost. Browsers block media devices anywhere else. See Why HTTPS.
  • The browser has permission to use the microphone and camera for this site.
  • Port 40000 is open in your firewall and router, on both UDP and TCP.
  • If the server is behind NAT, Docker, or a cloud provider, set webRtc.announcedAddress to your public IP or domain in config.ini. Without it, clients may be told to send media to a private address they cannot reach.
  • If you changed webRtc.port, open the new port and restart the server.

Your reverse proxy's address is being rate limited instead of the users behind it. The server logs this once at the point it happens, naming the address to add:

Requests are arriving from 172.18.0.4 with forwarded headers, but that address is
not in server.trustedProxies, so the headers are ignored and every client is rate
limited as one.

Loopback and private ranges are trusted by default, so this normally only comes up when a CDN such as Cloudflare sits in front of your proxy, or when you narrowed the list yourself. See Behind a Proxy.

Large uploads that fail immediately are usually stopped by the reverse proxy, not by Sharkord. Nginx caps request bodies at 1 MB by default; set client_max_body_size 0. See the Nginx guide.

If the error mentions the file size or the quota, it comes from Sharkord itself: per-role upload limits and the server storage quota are set in the server settings.

This is the browser reporting that the WebSocket closed abnormally, almost always a network or proxy problem. Check the proxy's read timeout (Sharkord holds one long-lived connection) and any idle timeout between you and the server.

These issues collect the known cases:

  • Windows: install the Microsoft Visual C++ 2015-2022 Redistributable (x64). Without it the binary exits immediately.
  • Port in use: another process is on 4991. Change server.port, or stop the other process.
  • Permissions: the user running Sharkord must be able to write to its data directory. In Docker, use PUID and PGID to match the owner of the mounted volume.

The file is only read at startup, so restart the server. Sharkord also rewrites the file on every boot: comments and unknown keys are dropped, and a file that fails validation is replaced by the defaults, with the reason logged. Check the console output if a value keeps reverting.

Open the plugin's logs in the server settings; load failures are recorded there with the reason. The usual causes:

  • Plugins are disabled server-wide. Turn them on in the server settings first.
  • The plugin folder name does not match the id in its manifest.json.
  • server/index.js or client/index.js is missing from the plugin folder. Both are required, even if the plugin has no UI.
  • The plugin does not export an onLoad function. A missing onUnload only logs a warning.
  • The manifest's sdkVersion does not match the server's plugin SDK version.
  • onLoad threw, or took longer than 30 seconds.
  • onUpgrade threw. The version on record is left alone, so the migration is retried on the next load rather than running half-applied.

See Installation.

It cannot be recovered. If you still have owner access, grant the roles you need from the server settings. If you do not, the only reset is a fresh data directory, which starts the server from scratch.

Still stuck? Search the issues or ask in discussions. Turning on debug in config.ini makes the server log a lot more, which is worth including in a report.