Networks (Velocity / Bungee)

How it fits together

Where	Jar	Job
Proxy	Velocity or Bungee jar	stops banned players at login, before any backend; commands work from the proxy console
Every backend	Paper jar	enforces mutes in chat, commands, signs, books and anvils; /punish menu
Database	one MySQL / MariaDB	shared by all of them

Why the backends are needed

Clients since 1.19.1 send signed chat. A proxy cannot drop such a message without disconnecting the player, so mutes on modern clients have to be enforced on the backend. The proxy alone is enough for bans only.

Setup

1. Create a database and a user in MySQL/MariaDB.
2. On the proxy and on every backend set the same storage block:

storage:
  type: mysql
  host: db.internal
  port: 3306
  database: finexbans
  username: finexbans
  password: '...'
  table-prefix: 'finexbans_'
server-name: 'survival'      # different on each backend — shows up in history

3. Use the same license key everywhere. One key has 3 slots; a proxy plus two backends fits exactly. Bigger networks need a second key.

Sync

With a shared database the plugin polls every 10 seconds for punishments issued elsewhere:

sync:
  interval-seconds: 10

A player banned on survival while playing on skyblock is kicked from skyblock within that interval; a mute given on the proxy reaches the backends the same way, and a mute lifted anywhere is lifted everywhere.

Offline-mode backends

Backends behind an online-mode proxy run with online-mode=false but receive real Mojang UUIDs. Tell the plugin so it resolves never-seen names correctly:

unknown-players:
  online-uuids: true

Permissions on the proxy

Velocity and Bungee check permissions on the proxy, so staff need the finexbans.* nodes in the proxy's LuckPerms too — not only on the backends. If LuckPerms uses separate storage on the proxy, add the groups there as well.