How to Set Up NuVotifier for Vote Rewards (and Fix Votes Not Received)

NuVotifier is the piece in the middle: a player votes for you on the listing, the list opens a connection to your server, and NuVotifier receives that vote and passes it on. The part that trips up almost everyone is what NuVotifier doesn't do — it never gives a reward by itself. It receives the vote and authenticates it, then fires an internal event. A separate reward plugin has to be listening for that event to actually thank the player in-game. Install only NuVotifier and your votes will arrive and nothing will happen.

So a working setup is two plugins, not one: NuVotifier to receive, and a reward plugin to act. You install NuVotifier, hand the list your key or token, point it at the right host and port, then test. Votes are what move you up the live monthly board, so this is worth getting right — here's how the rankings and voting work if you want the full picture of what those votes feed into.

What NuVotifier actually does (and what it doesn't)

NuVotifier is the maintained successor to classic Votifier. It runs on Bukkit, Spigot, and Paper, and on proxies like BungeeCord and Velocity, going back to Minecraft 1.7.2. The flow is straightforward once you see it laid out: the server list opens a TCP connection to your server's Votifier port, sends a signed message saying a player voted, NuVotifier verifies that message, and then it fires an event inside your server.

That event is where the second plugin comes in. A vote-listener plugin — VotingPlugin, SuperbVote, and UltimateVotes are the common ones — listens for the event NuVotifier fires and grants the reward. NuVotifier does not include any listeners by default, so without one of these installed the vote is received and verified and then nothing reaches the player.

Install NuVotifier and generate keys

Drop the NuVotifier .jar into your server's plugins/ folder and restart. On that first start it writes its config and generates an RSA key pair at plugins/(Nu)Votifier/rsa/ — a public.key and a private.key. Those two only work as a matched pair, so don't separate them or hand-edit either one. The public key is the one you'll hand out; the private key stays on your server and never leaves it.

The config lives at plugins/Votifier/config.yml. The fields that matter are host (your server's public IP, or 0.0.0.0 to bind every interface), port (8192 by default), and the tokens block under default, which holds the auto-generated v2 token. Before you do anything else, check your startup log and confirm NuVotifier enabled and bound to the port. If it failed to bind — usually because something else is already on that port — nothing downstream can work, and you'll be debugging the wrong half of the chain later.

NuVotifier (v2 token) vs classic Votifier (v1 RSA key)

There are two ways the list authenticates a vote, and you pick one. They are not interchangeable, and mixing them up is one of the top reasons setups fail.

• v2 / token is NuVotifier's own method. You copy a short secret token string out of config.yml and paste it on your listing. It's HMAC-signed and the server sends back a real success-or-failure reply, so when something's wrong it's much easier to see. Use this where the list supports it.
• v1 / classic RSA is the older method. You copy the full contents of plugins/(Nu)Votifier/rsa/public.key into your listing, and the list encrypts the vote with that key. There's no acknowledgement reply, so a list can't truly confirm the vote was processed — it can only confirm it sent one.

Whichever you pick, the mode on the listing has to match the mode in your config. A v1 listing needs the public key; a v2 listing needs the token. Paste the exact contents with no extra spaces and no truncation. For classic v1 this site requires a real 2048-bit RSA public key and will reject anything that isn't one, which is the standard the wire format is built around. Your private.key and your token are secrets — never paste them anywhere public.

Enter your server on the listing and add a reward plugin

On your owner dashboard, fill in three things. The Votifier host is a hostname or IP with no Minecraft port appended — just the address. The Votifier port is that separate 4–5 digit port, 8192 by default, and it is not your Minecraft game port. Then either the v2 token or the v1 public key, matching the mode you set on the server.

That host has to be an address the list can actually reach from the public internet. localhost won't work, and neither will your LAN IP like 192.168.x.x — those only mean anything on your own machine or network. The list is connecting from outside, so it needs your public address.

The Votifier port is not the game port. Java's game port is 25565 and Bedrock's is 19132; the Votifier port defaults to 8192 and is a separate thing. The game port doesn't belong in either the host or the Votifier port field.

Now install one reward plugin and configure what it hands out. Pick a single listener — running two means both react to the same vote, and players get rewarded twice or the plugins fight over it. Once it's wired up, it helps to look at the board you're actually trying to climb, like the live Survival rankings, so you can see where the votes land.

Test the handshake

There are two separate tests, and they check different halves of the chain. Run both so you know which half is at fault if something breaks.

The list's built-in Test Vote button sends a real test vote to the config you saved and travels the full network path to your server. Click it and watch your server console for the vote arriving. This is checking the network and auth path — does a vote from the outside actually reach NuVotifier and pass verification.

Your listener plugin also has a local test command, and that checks the reward path instead. On Bukkit, Spigot, or Paper it's /testvote <player>; on a Velocity or BungeeCord proxy it's /ptestvote. That command fires a vote internally without any network involved, so it proves the reward side works on its own.

A clean run means the console logs the received vote and the reward fires. If the Test Vote from the site dispatches but no reward shows up, you've just isolated the problem to the listener plugin, not NuVotifier — NuVotifier did its job and the reward plugin didn't act on it.

Votes not received: working through it

Almost every "votes not received" comes down to a closed port or a credential that doesn't match. Work down this list in order.

• The Votifier port isn't open to the internet. This is the number one cause. Port 8192 (or whatever you set) has to be reachable from outside. Open it in the OS firewall — Windows Firewall, or ufw/iptables on Linux — and if you're self-hosting behind a router, port-forward it through your NAT. On a managed or shared host you usually have to ask them to open it for you.
• Could not decrypt data (is your key correct?) in the log. This is a v1 key mismatch: the public key on the listing doesn't match the key on your server. Re-copy the contents of public.key exactly and paste it again.
• No log output at all. The vote never reached NuVotifier. That's a firewall or port problem, a wrong host or port on the listing, or NuVotifier failing to bind on startup. Try setting host to 0.0.0.0 so it binds every interface, and re-check the startup log to confirm it actually bound.
• Connection reset by host. An OS firewall is closing the connection. Connection reset by peer is different — the remote closed early, which can be a v1 protocol hiccup, and switching to v2 often clears it.
• The vote is logged but no reward appears. NuVotifier received it fine; the reward side didn't act. Either no listener plugin is installed, or the one you have is misconfigured.
• Line endings on config.yml. If you edited the file on Windows, save it with Unix (LF) line endings. Windows CRLF endings can break the YAML parsing and leave you debugging a config that looks correct but won't load.

FAQ

Why do my Bedrock (Geyser) players' votes not give rewards?

If you run Geyser with Floodgate, Bedrock usernames carry a prefix — often a special character like . or *. A lot of server lists won't match a name with those characters, so the vote arrives but never lands on the right player, and no reward fires. Tell Bedrock players to enter their name without the prefix when they vote on the site. If you can, set Floodgate's username-prefix to something list-friendly like _b_ instead of a special character, which tends to fix the matching for everyone at once.

Where does the vote count actually update — on my server or on the listing?

On the listing. The vote is recorded against your server on the site the moment a player votes, and that's what feeds the monthly ranking. NuVotifier and your reward plugin are a separate path that only handles the in-game thank-you. So a player's vote can count toward your rank even if your reward plugin is misconfigured and nothing shows up in-game — the missing reward is a server-side problem, not a lost vote.