Configuration

A proxied setup has two sides to configure: each backend's own SocketSVC config, and the relay plugin's config.yml on the proxy.

Backend configuration複製段落連結

On every backend server's plugins/SocketSVC/config.yml (or config/socketsvc-server.yml for a server mod):

bind-address: 127.0.0.1   # or a private address the proxy machine can reach
port: 24456                 # internal only; unique per backend if co-located
public-host: voice.example.com   # or public-url: wss://voice.example.com

• bind-address/port no longer need to be reachable by players directly — only the relay needs to reach them. If several backends run on the same machine, give each a unique port.
• public-host/public-url must point at the relay's public address, not the backend's own.

These are the same, already-existing fields described in Server configuration; nothing about the backend plugin or mod itself changes for proxy mode. Apply the change with /ssvc-server reload on each backend.

Relay configuration複製段落連結

Drop socketsvc-proxy-<version>.jar into your proxy's plugins/ folder — the same jar works whether that proxy is Velocity or BungeeCord/Waterfall. On first run it writes a default config.yml into its data folder. A filled-in example:

listen:
  bind-address: "0.0.0.0"
  port: 24455          # the ONE public port for the whole network

connect-timeout-ms: 5000

servers:
  survival: "127.0.0.1:24456"   # matches the proxy's own server name
  creative: "127.0.0.1:24457"   # -> that backend's internal voice address

server-list-advert: true   # badge this network in the multiplayer server list

metrics:
  enabled: true   # anonymous, aggregate usage only - never player identities or voice data

Server names複製段落連結

The servers keys must match the server names already used in velocity.toml / BungeeCord's own config.yml (the same names players switch between with /server). Each value is the corresponding backend's internal bind-address:port from Backend configuration, written as "host:port".

Server list badge複製段落連結

With server-list-advert on (the default), a player running the SocketSVC client mod sees a microphone badge beside this network's row in their multiplayer server list, in the margin to the left of it, before joining.

The relay has to be the one to send it. Players ping the proxy, and each backend's own voice listener is internal and never answers a server-list ping, so a backend's own server-list-advert does nothing on a proxied network.

The marker is an empty component appended to the MOTD carrying only a style insertion, which has no rendering of its own — a vanilla client sees exactly the MOTD it would have seen. It is advisory: an MOTD plugin that rebuilds the description from a plain string drops it and the badge simply does not appear; nothing else changes. /ssvc-proxy reload applies a change, and the mechanism is the same one described under Server list badge for a standalone server.

Metrics複製段落連結

metrics.enabled uses the same FastStats SDK, version and project token as the Paper server plugin's own metrics (metrics.enabled in the server's config.yml). Set it to false to opt out; it takes effect on the next proxy start, not on /ssvc-proxy reload.

Firewall and TLS複製段落連結

Only the relay's listen.port needs to be open in your firewall — the per-backend voice ports stay internal. For wss://, put an external reverse proxy or tunnel in front of listen.port and set the backends' public-url to that wss:// address; the relay itself only speaks plain ws://.

Updates複製段落連結

The relay is the single public voice port for a whole network, so it never replaces itself: it reports, and an administrator installs with /ssvc-proxy update confirm (permission socketsvc.proxy.admin.update, falling back to operators).

updates:
  enabled: true
  channel: release
  endpoint: ''         # blank uses the deploy SocketSVC ships with
  notify-admins: true  # tell holders of socketsvc.proxy.admin.update when they connect

/ssvc-proxy update checks and prints a confirmation panel, confirm downloads and verifies it, and list shows every build on the channel. The verified jar is staged under the plugin's data folder and swapped in as the proxy shuts down; updates/apply.log records what happened.