¶ Dedicated Voting Proxy
Development-build feature:
DedicatedVotingProxyis not available in the latest public release, VotingPlugin 7.1.1. It requires a 7.1.2-SNAPSHOT development build containing merged commit6867c488(PR #1551) and its backend-presence foundation fromc916763e(PR #1550). Release users will not have this setting yet.
Use this mode when players connect through multiple regional or player-facing proxies, but one separate proxy should receive votes and coordinate VotingPlugin for the entire network.
The dedicated voting proxy does not need local players. Backend servers report their online-player and current-server state through the configured VotingPlugin communication method so the dedicated proxy can route votes, cached rewards, vote parties, broadcasts, and status requests correctly.
¶ When to use it
Use a dedicated voting proxy when all of these are true:
- one central BungeeCord or Velocity proxy runs VotingPlugin and receives votes;
- regional/player-facing proxies route Minecraft players but do not run VotingPlugin;
- every participating backend runs the same compatible VotingPlugin development build;
- the dedicated proxy and backends share one SQL database and table configuration;
- the dedicated proxy and backends communicate through
MYSQL,REDIS,MQTT, orSOCKETS.
This is different from Multi-Proxy Setup. MultiProxySupport coordinates multiple VotingPlugin proxies. Dedicated mode instead keeps VotingPlugin on one central proxy while the regional proxies remain outside VotingPlugin's vote-delivery path.
¶ Requirements
- Install the same compatible development build on the dedicated proxy and every backend.
- Run VotifierPlus or NuVotifier on the dedicated proxy in the standard layout.
- Configure the same non-
PLUGINMESSAGINGBungeeMethodon the dedicated proxy and every backend. - Give each backend a unique
Servervalue inBungeeSettings.yml; it must match the server name configured on the dedicated proxy. - Configure the shared SQL database required by normal VotingPlugin proxy setups.
- Secure the selected communication transport and allow connections only between participating hosts.
PLUGINMESSAGINGcannot be used for dedicated-proxy routing. It depends on the player-facing proxy's native player/server state and does not carry the backend presence snapshots required by a proxy with no local players. If dedicated mode is enabled withPLUGINMESSAGING, VotingPlugin logs a severe configuration error and falls back to normal proxy routing.
¶ Dedicated proxy configuration
In the dedicated proxy's bungeeconfig.yml:
# Development builds containing merged PR #1551 only
DedicatedVotingProxy: true
# Choose one: MYSQL, REDIS, MQTT, or SOCKETS
BungeeMethod: MQTT
# Normal routing behavior is preserved; choose the behavior you want
SendVotesToAllServers: false
Configure the matching transport section and the normal Database section in the same file. See the method-specific guides:
Enable DedicatedVotingProxy on one central voting proxy only. Do not enable it on regional proxies.
¶ Backend configuration
On every backend, configure BungeeSettings.yml with the same method and a unique server name. For example:
UseBungeecord: true
BungeeMethod: MQTT
Server: lobby
MQTT:
ClientID: lobby
BrokerURL: "tcp://mqtt.internal.example:1883"
Username: 'votingplugin'
Password: 'replace-with-a-secret'
Prefix: ''
Also configure the shared SQL storage in backend Config.yml. Follow the selected method guide for its complete proxy and backend settings. In particular, every MQTT instance needs a unique ClientID, and socket endpoints must match the proxy's SpigotServers entries.
¶ Regional proxy configuration
Regional/player-facing proxies continue routing players normally, but they do not participate in VotingPlugin routing:
- do not install or run VotingPlugin on the regional proxies;
- do not forward the same Votifier vote through a regional proxy as well as the dedicated proxy;
- do not configure
DedicatedVotingProxyon them; - keep their normal Minecraft backend routing independent from VotingPlugin's selected communication transport.
¶ Vote routing behavior
Dedicated mode changes where VotingPlugin obtains online-player and current-server state. It does not replace the normal SendVotesToAllServers setting.
| Setting | Behavior in dedicated mode |
|---|---|
SendVotesToAllServers: true |
Preserves normal fan-out behavior and sends the vote to every eligible backend. Existing cache and WaitForUserOnline rules still apply. |
SendVotesToAllServers: false |
A player confirmed online is routed to their reported current backend. An unknown or offline player follows the existing online-vote cache path until presence confirms them. |
BlockedServers, WhiteListedServers, WaitForUserOnline, backend ProcessRewards, proxy broadcasts, and the normal totals settings continue to affect processing. Dedicated mode does not make every backend execute rewards unless the existing settings select that behavior.
¶ Backend presence and recovery
For MYSQL, REDIS, MQTT, and SOCKETS, each backend reports its lifecycle and player presence through the same selected communication path:
- backends announce start, stop, player login, player logout, and periodic heartbeats;
- the dedicated proxy requests a fresh presence resynchronization shortly after startup;
- complete snapshots restore the known online players for each backend;
- a backend that stops reporting is eventually treated as unavailable;
- presence state is memory-only, so players are temporarily unknown after a dedicated-proxy restart until fresh backend snapshots arrive;
- when a completed snapshot confirms players who were already online, VotingPlugin runs its existing login/cache-draining path so voter-keyed cached rewards are released.
The current implementation starts its resynchronization request five seconds after proxy startup, performs presence maintenance every 30 seconds, and treats a silent backend as unavailable after 90 seconds. These timings describe the development implementation and may change before release.
¶ Security model
Dedicated presence adds no separate presence password, secret file, or persistence file. Each backend's unique configured Server name is its identity inside the selected communication system. Therefore, every participant with access to that transport must be trusted not to impersonate another backend.
- Keep Redis, MQTT, MySQL, and socket listeners on private networks, VPNs, or strict firewall allowlists.
- Require dedicated credentials with the minimum necessary permissions.
- Use TLS or a trusted private tunnel when traffic crosses hosts or untrusted networks.
- Do not publish database, broker, socket, or encryption credentials in screenshots or logs.
- For
SOCKETS, keep the generated/shared encryption key private and follow Sockets.
¶ Migration checklist
- Back up the proxy and backend VotingPlugin configuration and data.
- Install a development build containing commits
c916763eand6867c488on the dedicated proxy and every backend. - Choose and secure one supported non-plugin-messaging transport.
- Configure the shared database, transport, backend names, and
SpigotServersmapping. - Set
DedicatedVotingProxy: trueonly on the central proxy. - Set
SendVotesToAllServersfor the intended normal reward-routing behavior. - Remove duplicate VotingPlugin/Votifier vote ingress from regional proxies.
- Restart the dedicated proxy and every backend; this feature is not intended to be enabled by a partial reload.
¶ Validation
Test both routing modes before production use:
- Run
/votingpluginproxy statuson the dedicated proxy and confirm each expected backend responds while it has players online. - Run
/votingpluginproxy vote <player> <site>with a player online and confirm the selected backend behavior. - Test an offline or unknown player and confirm the vote is cached, then delivered after presence confirms the player.
- Test with
SendVotesToAllServersboth enabled and disabled if you may use both modes. - Restart the dedicated proxy while players remain online, allow the startup snapshot to complete, and verify cached rewards drain without requiring another player reconnect.
- Send one real vote through VotifierPlus/NuVotifier to validate the public listener and the complete delivery path.
¶ Troubleshooting
| Symptom | Check |
|---|---|
| Severe warning says dedicated routing requires another method | Replace PLUGINMESSAGING with MYSQL, REDIS, MQTT, or SOCKETS on the dedicated proxy and all backends. |
| Players are unknown immediately after proxy startup | Wait for the startup resynchronization and verify backend lifecycle/snapshot messages reach the dedicated proxy. Presence is intentionally not loaded from disk. |
| One backend never becomes available | Verify its unique Server name, matching proxy server entry, selected method, credentials, prefix/topic/database, and firewall rules. |
| MQTT clients repeatedly disconnect | Give the dedicated proxy and every backend a unique ClientID. |
| Votes or broadcasts are duplicated | Ensure the vote enters VotingPlugin once, regional proxies do not run VotingPlugin, Votifier forwarding is not duplicating delivery, and SendVotesToAllServers matches the intended behavior. |
| Offline rewards remain cached after recovery | Confirm the backend appears in status, a complete presence snapshot is accepted, the player is reported on the correct backend, and all instances contain merged PRs #1550 and #1551. |