How to set up NuVotifier and test it, step by step

NuVotifier is the plugin that receives votes from server lists. You install it on your server or your proxy, open one TCP port, and give each list your address, the port and either a v1 public key or a v2 token. It hands out no rewards by itself, so you also need a reward plugin such as VotingPlugin, and you should test the whole path once before you tell players to /vote.

We wrote this from both ends of the wire. serverlist.net sends votes to 95 listings right now, and for this guide we ran NuVotifier on a fresh Paper 26.3 server and a Velocity 4.2 proxy, sent it good votes and deliberately broken ones, and copied what the console printed. Every log line quoted below came from that setup, with tokens and addresses swapped for examples.

1. Put nuvotifier.jar in your plugins folder and restart.
2. Note the port (8192 by default), the token and the public key that NuVotifier generates.
3. Open that port for TCP on your host or firewall.
4. Add the address, port and token (or key) to your serverlist.net listing.
5. Send a test from the Votifier tester and watch the console.
6. Install VotingPlugin and give the ServerList.net vote site a reward.

What NuVotifier does and does not do

NuVotifier listens on a TCP port. When a list connects, it reads one vote message, checks it with your key or token, and fires a vote event inside the server. A vote carries four things: the list's service name (ours is ServerList.net), the username the player typed, the voter's IP address and a timestamp.

What it does not do matters just as much:

• It gives no rewards. A reward plugin listens for the event and pays out.
• It does not check that the player exists. The list validates names, and the reward plugin decides what to do with unknown ones.
• It uses TCP only. A port opened for UDP alone leaves Votifier unreachable.
• It sends nothing back to a v1 list, which changes how you test.

The official release is still 2.7.3 from July 2021, one jar for Paper, Spigot, BungeeCord, Velocity and Sponge. In our test it loaded and received votes on Paper 26.3 and Velocity 4.2.0 unchanged. On Java 25 it prints a block of warnings that includes WARNING: sun.misc.Unsafe::objectFieldOffset has been called by. That is about a future Java change, not an error, and votes kept working.

The official release does not support Folia. The maintained fork azuvotifier does (version 3.3.6, November 2025) and speaks the same protocol, so lists treat it like NuVotifier.

v1 key or v2 token

Lists can talk to NuVotifier in two protocol versions, and you can leave both switched on.

Anyone holding your v1 public key can create a valid vote, since encrypting with it is the whole protocol, so never paste it in a public channel. And whether a v1 key matched shows up in your console and nowhere else.

On serverlist.net, use v2. Keep v1 enabled while other lists you use still need it. As of 18 October 2026, 97 of our 218 listings had Votifier configured, 68 with a v1 key and 29 with a v2 token (live: 68 and 27).

Install on Paper

1. Download nuvotifier.jar from the NuVotifier GitHub releases page or its SpigotMC page and put it in your server's plugins folder.

2. Start the server. On first start NuVotifier prints your token and where it listens:

   [Votifier] Your default NuVotifier token is e4qk2v9m1r7t0p5s3a8d6f2h1j.
   [Votifier] Votifier enabled on socket /0.0.0.0:8192.

3. Stop the server and open plugins/Votifier/config.yml. Without its comments, the default looks like this:

   host: 0.0.0.0
   port: 8192
   disable-v1-protocol: false
   tokens:
     default: e4qk2v9m1r7t0p5s3a8d6f2h1j
   forwarding:
     method: none
     pluginMessaging:
       channel: nuvotifier:votes

4. Check host. It defaults to the server-ip in server.properties, or 0.0.0.0 when that is empty. On our test server server-ip was 127.0.0.1, so NuVotifier quietly listened on 127.0.0.1:8192, where no list could ever reach it. Read the Votifier enabled on socket line after every restart. It should show 0.0.0.0 or an address the internet can reach.

5. Set port to the port your host gives you. It must be a free TCP port and cannot be your game port.

6. Leave disable-v1-protocol: false unless every list you use supports v2.

7. Restart the server fully. In our test, a token removed from config.yml kept working after /nvreload until the next restart, so do not trust a reload after you change tokens.

NuVotifier looks up the token by the list's service name and falls back to default. A separate token per list sounds tidy, but it does not work for any service name with a dot in it, ours included. Paper reads ServerList.net: under tokens as a section called ServerList with a key net inside. Velocity's TOML reader keeps the quotes around "ServerList.net" as part of the name, and without quotes the config does not load at all. Either way the lookup misses and NuVotifier checks our vote against default, so if you gave us the separate token, every vote fails as an invalid signature. Give us the default token. The v1 keys are in plugins/Votifier/rsa/, and only public.key ever leaves your server.

Install on a Velocity or BungeeCord network

On a network, votes arrive at the proxy, the one address lists know. Install the same nuvotifier.jar on the proxy and on every backend that should receive votes. The proxy's config is plugins/nuvotifier/config.toml on Velocity and plugins/NuVotifier/config.yml on BungeeCord.

Forwarding votes to backend servers

Plugin messaging is the simple choice for one proxy. Votes travel to the backends over a player's own connection.

On the proxy (config.toml on Velocity):

host = "0.0.0.0"
port = 8192

[forwarding]
method = "pluginMessaging"

[forwarding.pluginMessaging]
channel = "nuvotifier:votes"
cache = "file"
onlySendToJoinedServer = false

On each backend (plugins/Votifier/config.yml), turn off the backend's own listener with port -1 and switch forwarding on:

port: -1
forwarding:
  method: pluginMessaging
  pluginMessaging:
    channel: nuvotifier:votes

Plugin messages need a connected player, so a backend with nobody online gets its votes later: the proxy caches them (in a file by default, for up to 10 days) and passes them on when someone joins. By default every backend receives every vote, so if each one runs a reward plugin, the voter is paid on each. Use onlySendToJoinedServer = true with a joinedServerFallback server, excludedServers, or VotingPlugin's own proxy setup.

Proxy forwarding sends each vote over the network to the backend's own NuVotifier, signed with the backend's token. It needs no players online but has no cache: a vote that still fails after five retries is dropped. This is the setup we tested. On each backend, give NuVotifier its own port, copy its default token and set disable-v1-protocol: true. On the proxy:

[forwarding]
method = "proxy"

[forwarding.proxy.survival]
address = "10.0.0.12"
port = 8193
token = "the survival backend's default token"

Add one block per backend. The name is only a label. In our test, a v1 and a v2 vote sent to the proxy both reached Paper as v2 votes within a second:

[nuvotifier]: Successfully forwarded vote Vote (from:ServerList.net username:Steve address:203.0.113.7 timeStamp:1792283636000 additionalData:null) to /127.0.0.1:8192.

Then we put a wrong token in the proxy's backend entry. The list still received {"status":"ok"} from the proxy, while the backend rejected every copy and the proxy kept retrying:

[nuvotifier]: Unable to send vote to /127.0.0.1:8192. Will retry sending in 1 second(s).
[nuvotifier]: Unable to send vote to /127.0.0.1:8192. Will retry sending in 2 second(s).

So on a network, a green test proves only the proxy. Check a backend console too. With either method, firewall the backends so only the proxy can reach their game and Votifier ports, or anyone could feed them fake votes.

Open the port

Votifier needs one TCP port that the internet can reach.

• Game server hosts. Add a second port in your panel (often an allocation under a Network tab) and set NuVotifier's port to it. Keep host: 0.0.0.0.
• A VPS or dedicated server. Open it in the firewall, for example sudo ufw allow 8192/tcp, and in your provider's network firewall if there is one.
• Docker. Publish it next to the game port, for example -p 8192:8192.
• DDoS protection. Services that protect the game address usually forward only the Minecraft port, so point Votifier at the machine's own IP. Of the 97 listings with Votifier on 18 October 2026, 68 used a different host for Votifier than for the game, 49 of them a plain IP address.

Most servers end up on a port other than 8192. On the same date only 19 of those 97 used the default (live: 18), across 70 different ports in total. Two used 25575, the default RCON port, which works only while RCON is off or moved.

To check the port from outside, run this from another machine or network:

nc -v 203.0.113.10 8192

NuVotifier greets every connection with a line like VOTIFIER 2 mmdin5k3bh10u2fommgp3hahkv. If you see it, the port is open and NuVotifier is behind it. On Windows, PowerShell's Test-NetConnection 203.0.113.10 -Port 8192 shows TcpTestSucceeded : True for an open port, without the greeting.

Add the details to your serverlist.net listing

When you add a server, the Votes step asks for Votifier. For a listing you already have, open it from the dashboard and use its Voting tab. Both have the same four parts.

1. Where Votifier listens. Enter the host that reaches Votifier, often the server's IP rather than the address players use, and the Votifier port, not the game port. Check port knocks on that port and reads the Votifier greeting without sending a vote, so you see at once whether the port is open and whether NuVotifier or classic Votifier answers.
2. Key or token. Choose NuVotifier token and paste your default token, or choose Votifier public key and paste the whole contents of public.key. The default 2048-bit key is a single line of 392 characters starting with MIIBIjANBgkq. Never paste private.key.
3. Your reward plugin. This part shows the line VotingPlugin needs, covered below.
4. Test vote. Send one before you publish or save.

Your token and key are stored encrypted. Each vote is saved first and delivered right after in the background, failed deliveries are retried, and every attempt shows in the delivery log on that tab. Our previous system kept no delivery results, so we will add a breakdown of the most common failures here once the new log holds a full month.

Test with the Votifier tester

The Votifier tester sends one real vote, with a username you choose, to the address you enter. It asks for a captcha and allows five tests per IP address every ten minutes. For v2 it shows NuVotifier's own answer, {"status":"ok"} or an error from the table below. For v1 it can only show that it connected and sent the vote, so confirm in your console.

A delivered vote starts a console line like this one, which then lists the service name, username, address and timestamp of the vote:

[Votifier] Got a protocol v2 vote record from /203.0.113.7:50480

If the next lines say A vote was received, but you don't have any listeners available to listen for it., delivery works and only the reward plugin is missing.

The console command testvote skips the network, key and token and fires a vote event inside your server, so it tests rewards, not delivery. Extra details must be written as key=value:

testvote Steve serviceName=ServerList.net

Typed as testvote Alex ServerList.net 127.0.0.1, it put 127.0.0.1 in the username field and kept the service name TestVote. On a proxy the command is ptestvote.

Hook up rewards with VotingPlugin

VotingPlugin is the actively maintained choice (7.1.1, July 2026). SuperbVote, still named in NuVotifier's setup guide, was last updated in December 2020.

1. Put VotingPlugin.jar in plugins next to NuVotifier and restart.

2. Send a test vote. VotingPlugin creates a site for any new service name on its own:

   [VotingPlugin] Received a vote from service site 'ServerList.net' by player 'Steve'!
   [VotingPlugin] VoteSite with service site 'ServerList.net' does not exist, attempting to generate...

3. Open plugins/VotingPlugin/VoteSites.yml, find the generated ServerList_net entry and give it a reward. A finished entry looks like this:

   VoteSites:
     ServerList_net:
       Enabled: true
       Name: 'ServerList.net'
       ServiceSite: 'ServerList.net'
       VoteURL: 'https://serverlist.net/server/your-server/vote'
       VoteDelay: 24h
       DisplayItem:
         Material: 'DIAMOND'
         Amount: 1
       Rewards:
         Commands:
         - 'eco give %player% 250'
         Messages:
           Player: '&aThanks for voting on ServerList.net!'

   ServiceSite must match exactly. VoteDelay: 24h matches our rolling 24-hour cooldown, so /vote next shows the right time. eco give assumes an economy plugin such as EssentialsX.

4. Reload with /av reload and vote again with the name of a player who has joined your server.

That last step catches almost everyone. With default settings VotingPlugin ignores votes for names it has never seen:

[VotingPlugin] Player Steve has not joined before, disregarding vote. Reason: unknown-user. Set AllowUnjoined to true to accept.

Test with your own name, or set AllowUnjoined: true in Config.yml. For a player who was offline, VotingPlugin broadcast the vote at once but held the command reward, which by default it hands out when the player next joins.

• Bedrock players. With Geyser and Floodgate, Bedrock names carry a prefix, a dot by default, so a Bedrock player must vote as .Steve for the reward to find them. In the last 30 days 6% of all votes on serverlist.net came from Bedrock names, so mention the prefix in your /vote message. The Geyser guide covers the prefix setting.
• Networks. VotingPlugin's proxy mode is set up in BungeeSettings.yml. Give every backend a unique server name there and keep VoteSites.yml the same on all of them.

What players see on their side, and what to tell them when a reward goes missing, is in why Minecraft servers ask you to vote.

Errors and what they mean

Every message in code format came from our test rig. "List" means what a v2 list, or our tester, receives back.

When errors arrive in a burst, NuVotifier stops printing them after the fifth within two seconds, so send one test at a time.

FAQ

Which port should Votifier use? Any free TCP port your host lets you open. 8192 is only the default. It cannot be your game port, and avoid 25575 if you use RCON.

Do I need v2? No, we accept both. v2 is better where a list supports it: votes cannot be replayed, and the list can show you the exact error. Keep v1 on for lists that only send v1.

Why do some lists only support v1? v1 is the original Votifier protocol that every list implemented years ago. v2 came with NuVotifier, and each list has to add it separately.

Is it worth the setup? Nearly all voting happens where Votifier is set up. In the last 30 days, 99.7% of all votes on serverlist.net went to listings with Votifier configured. In the 30 days to 18 October 2026 that was 15,443 of 15,477 votes, while 11 listings without Votifier shared the remaining 34. Votes also feed your position on the list, which the guide to your first 100 players puts in context.