Voice (PlasmoVoice / SimpleVoiceChat) issues

Voice modules have three classic failure modes. All look like “voice chat silently doesn’t work” — but the cause is almost always one of these three.

For setup, see PlasmoVoice integration and SimpleVoiceChat integration.

Symptom: voice connects but no audio (or no connect at all)

Walk through this list in order.

1. Docker UDP port mapping

If the backend (Velocity / BungeeCord) runs in Docker, the UDP voice port must be explicitly mapped to the host. Forgetting this is the #1 cause of “voice silently doesn’t work”.

services:
  velocity:
    ports:
      - "25577:25577"
      - "24454:24454/udp"   # <-- UDP! Bind a UDP port, not just TCP.
      # Or for PlasmoVoice:
      # - "60606:60606/udp"

A correct voice_host with a missing Docker UDP mapping looks like everything is configured, but no UDP packet reaches the proxy.

2. voice_host mismatch

The voice plugin’s voice_host value must be identical on the Velocity/BungeeCord proxy and on every Spigot backend. Only the listening port may differ.

If one of your Spigot backends has a slightly different voice_host, voice will work for players on the matching backends and silently fail for the others.

Check every Spigot’s plugin config:

voice_host=voice.example.com   # SAME everywhere

3. Backend firewall blocks the UDP port

The voice UDP port must be allowed from the IF IP ranges. UFW / iptables / cloud-provider firewall — all three layers.

Symptom: panel module backend uses the wrong port

The voice module backend on the panel takes the proxy plugin’s listening port, not the per-Spigot port. If you put a Spigot port there, the routing breaks.

Fix: open the panel → Backends → edit the voice module → update the port to the Velocity/BungeeCord plugin’s listening UDP port.

Symptom: voice works on direct connection, fails through IF

• Dedicated IP CNAME wrong at registrar.
• Backend firewall hasn’t been updated for IF ranges.
• Docker UDP mapping missing (see above).

Direct connection bypasses all of these, which is why it works — the IF path doesn’t.

Symptom: voice module suddenly stopped after subscription renewal

Same root cause as Bedrock: billing has been observed to wrongly flag the dedicated IP for cancellation during renewal. The dedicated IP needs to be re-enabled platform-side.

Fix: open a support ticket on Discord.

Diagnostic recipe

1. 1

   Check Docker

   If you use Docker, list the published ports and confirm the UDP voice port is there:

   bash

   $ docker port velocityClick to copy

   25577/tcp -> 0.0.0.0:25577

   24454/udp -> 0.0.0.0:24454

   If the UDP port is missing, add the mapping and recreate the container.

2. 2

   Check voice_host parity

   Grep voice_host across every plugin config:

   bash

   $ grep -r voice_host /minecraft/Click to copy

   /minecraft/velocity/plugins/PlasmoVoice/config.toml: voice_host = "voice.example.com"

   /minecraft/lobby/plugins/PlasmoVoice/config.toml: voice_host = "voice.example.com"

   /minecraft/survival/plugins/PlasmoVoice/config.toml: voice_host = "voice.example.com"

   Every value must match.

3. 3

   Check the firewall

   Confirm the UDP port is open from IF ranges (substitute the IF range from the announcement channel):

   iptables bash Copy

   iptables -L INPUT -n | grep 24454
   

   Should show ACCEPT rules from the IF subnets.

4. 4

   Check the panel backend

   On the panel’s Backends page, edit the voice module backend. The address should be the proxy’s IP and the proxy plugin’s listening port — not the per-Spigot port.

Common one-line diagnoses

What’s next