Repository navigation
Wiki en au
- Home
- Installation
- Velocity and BungeeCord
- Firewall and router configuration
- Compatibility
- Ordered mode
- Automatic transfers
- UDP forwarding and PROXY protocol
- Simple Voice Chat
- Troubleshooting
- Mod integration
- UDP proxies
RakNet networking for Minecraft clients and servers.
| Minecraft | Raknetify2 | Client / Server |
|---|---|---|
| Fabric | mods/raknetify2-fabric-*.jar |
Client / Server |
| Forge | mods/raknetify2-forge-*.jar |
Client / Server |
| NeoForge | mods/raknetify2-neoforge-*.jar |
Client / Server |
| Spigot / Paper | plugins/raknetify2-spigot-*.jar |
Server |
| Velocity | plugins/raknetify2-velocity-*.jar |
Velocity |
| BungeeCord | plugins/raknetify2-bungee-*.jar |
BungeeCord |
-
Multiplayer
-
Add Server
-
Server Address
Server Address RakNet · UDP raknet;play.example.com:25565TCP play.example.com:25565 -
Done
-
Join Server
| F3 | |
|---|---|
| RakNet · UDP | Active · MTU 1400 |
| TCP | Inactive |
- Client · Raknetify2 → UDP → Velocity / BungeeCord · Raknetify2
- Velocity / BungeeCord → TCP → Server
| Port Number · UDP | Java | |
|---|---|---|
| Fabric / Forge / NeoForge | 1–65534 | -Draknetify.fabric.portOverride=25570 |
| Spigot / Paper ≥ 0.1.0-beta.1.431 | 1–65535 | -Draknetify.spigot.portOverride=25570 |
| Velocity | 1–65534 | -Draknetify.velocity.portOverride=25570 |
| BungeeCord | 1–65534 | -Draknetify.bungee.portOverride=25570 |
| Server Address | UDP |
|---|---|
raknet;play.example.com:25580 |
play.example.com:25580 → NAT → 192.0.2.10:25570
|
Server · 192.0.2.10
|
25570/udp |
Server / Velocity / BungeeCord
| JSON | |
|---|---|
| ① ② ③ | {"mode":"ordered"} |
| ① ∥ ② ∥ ③ | {"mode":"multichannel"} |
| Server | Raknetify2 · UDP 25565 | Simple Voice Chat |
|---|---|---|
| Fabric / Forge / NeoForge |
config/raknetify2-voicechat.json · {"enabled":true}
|
config/voicechat/voicechat-server.properties · port=-1
|
| Spigot / Paper |
config/raknetify2-voicechat.json · {"enabled":true}
|
plugins/voicechat/voicechat-server.properties · port=-1
|
Simple Voice Chat · Velocity / BungeeCord
| Server Address | trustedProxies |
RakNet |
|---|---|---|
192.0.2.10 · PROXY v2 / UDP |
["192.0.2.10"] |
✓ |
192.0.2.11 · PROXY v2 / UDP |
["192.0.2.10"] |
✗ |
| Client → RakNet / UDP | ["192.0.2.10"] |
✗ |
config/raknetify2-proxy-protocol.json
{"trustedProxies":["192.0.2.10"]}-
Server A · Fabric / Forge / NeoForge ·
config/raknetify2-transfers.json{"destinations":[{"host":"play.example.com","tcpPort":25565,"udpPort":25570}]} -
Server B ·
play.example.com·server.properties→accepts-transfers=true -
Server A ·
/transfer play.example.com 25565 Alex→ Client (Alex) → RakNet ·play.example.com:25570
| Minecraft | |
|---|---|
ui |
Options |
entity |
Skeleton |
world_interaction |
Inventory |
effects |
Particles |
chunk |
Blocks |
- Fabric ·
compatibility.json·gameVersions/runtimes/depends - Forge / NeoForge / Spigot / Paper · GitHub Releases
Raknetify2 uses RakNet over UDP for Minecraft multiplayer. It separates traffic into ordering channels so that packet loss on one channel can leave unrelated traffic flowing. This can keep interactions responsive while the connection is recovering missing data or transferring chunks.
Raknetify2 is an independently maintained fork of Raknetify, originally developed by ishland. The fork adds support for newer Minecraft versions and maintains the transport, platform integrations, and compatibility tests.
- Check Minecraft and mod compatibility.
- Choose a download and install it.
- Connect with an address such as
raknet;play.example.com.
- Velocity and BungeeCord
- Firewall and router configuration
- Automatic transfers
- UDP forwarding and PROXY protocol
- Sharing a UDP port with Simple Voice Chat
- Troubleshooting and bug reports
Mod authors can use the packet ordering interface to declare dependencies between custom payloads and Minecraft traffic.
Raknetify2 uses the MIT licence and retains the original copyright notices. Its networking implementation builds on Raknetify and netty-raknet.
Download a release from GitHub Releases. Check the Minecraft version and loader requirements for that release before installing.
| Where you are installing | File | Folder |
|---|---|---|
| Fabric client or server | raknetify2-fabric-*.jar |
mods |
| Forge client or server | raknetify2-forge-*.jar |
mods |
| NeoForge client or server | raknetify2-neoforge-*.jar |
mods |
| Spigot or Paper server | raknetify2-spigot-*.jar |
plugins |
| Velocity proxy | raknetify2-velocity-*.jar |
plugins |
| BungeeCord proxy | raknetify2-bungee-*.jar |
plugins |
Close the client or stop the server before replacing its JAR. Remove the original Raknetify JAR and any older Raknetify2 JAR from the same installation before adding the new file.
Client folders belong to the Minecraft instance or modpack you launch. Server and proxy folders belong to that server or proxy installation. Create the appropriate folder if your loader has not created it yet.
- Install the client mod for your loader.
- Install the matching server mod, or the Spigot/Paper plugin on a compatible server.
- Follow Firewall and router configuration to allow UDP connections to the server.
- Restart the client and server.
- Add a server address such as
raknet;play.example.comorraknet;play.example.com:25565.
Addresses without the raknet; prefix use TCP.
Installing the client mod alone does not add RakNet support to a remote server. The server operator must provide a RakNet endpoint. Players joining someone else's server usually need no inbound router forwarding rules.
Install the matching proxy plugin and the client mod. Follow Velocity and BungeeCord for listener settings, backend forwarding, access restrictions, and the address players should use.
For a direct Minecraft server, set the appropriate Java argument below. Proxy operators should use the Velocity and BungeeCord listener settings.
| Platform | Java argument | Accepted ports |
|---|---|---|
| Fabric, Forge, or NeoForge server | -Draknetify.fabric.portOverride=25570 |
1 through 65534
|
| Spigot or Paper server | -Draknetify.spigot.portOverride=25570 |
1 through 65535
|
Forge and NeoForge use the shared listener code, so their property name also contains fabric. Replace 25570 with the desired UDP port.
Spigot / Paper ≥ 0.1.0-beta.1.431
Add the argument before -jar in the Java command, or in your host's JVM arguments field. Restart the server and allow UDP on the chosen listener port. If the public port is also 25570, connect with raknet;play.example.com:25570. If a router translates the port, use its public port in the client address. The TCP port stays at its existing value.
On Spigot/Paper, the UDP listener keeps the Minecraft TCP listener's local bind address. An invalid override or occupied UDP port prevents RakNet from starting. Check the startup log for the bound UDP address and port. Remove the argument and restart to return to the TCP listener's port number.
A router or UDP proxy can also expose a different public UDP port and forward it to the existing listener without changing the server's Java arguments.
Open a successful main run in GitHub Actions and download its Artifacts archive. GitHub requires an account to download workflow artifacts. Use the installation table above to choose a JAR from the archive.
Velocity and BungeeCord sit between players and backend Minecraft servers. Install Raknetify2 on the proxy and on each client that will connect over RakNet.
Raknetify2 client --UDP--> Velocity or BungeeCord --TCP--> backend server
The backend servers do not need Raknetify2 for this connection path. They still need the mods, plugins, and forwarding support required by your network. Raknetify2 does not translate Minecraft versions or change the proxy's account authentication.
- Confirm that ordinary TCP connections through your proxy work, including authentication and switching between backend servers.
- Stop the proxy and download the matching plugin from GitHub Releases.
- Put
raknetify2-velocity-*-all.jarorraknetify2-bungee-*-all.jarin the proxy'spluginsfolder. Remove any older Raknetify or Raknetify2 plugin from that folder. - Install the appropriate Raknetify2 client mod using the installation guide.
- Check the listener settings below, restart the proxy, and inspect its log for RakNet listener errors.
- Allow public UDP traffic to the proxy and restrict backend gameplay ports as described in Firewall and router configuration.
Use compatible Raknetify2 releases on the client and proxy. Check Compatibility before mixing releases.
The bind setting in velocity.toml selects Velocity's Minecraft listening address and TCP port. Raknetify2 normally uses the same port number for UDP. The [servers] entries identify the backend servers. Keep those entries pointed at the backend TCP addresses. See Velocity's configuration reference.
To use a separate UDP port, add this JVM argument before -jar in Velocity's startup command:
-Draknetify.velocity.portOverride=25570
Replace 25570 with your chosen port. This changes the RakNet UDP port while retaining Velocity's TCP port and backend addresses. Restart Velocity after changing the argument.
Configure player forwarding on both Velocity and its backends. Use modern forwarding when the backend software supports it, and keep its forwarding secret private. Follow the backend-specific instructions in Velocity's player information forwarding guide. Keep the backend firewall restrictions in place alongside forwarding.
In BungeeCord's config.yml, the host value under each listeners entry identifies a Minecraft listening address and TCP port. Raknetify2 normally adds UDP on that port number. The servers entries hold backend TCP addresses. These settings are described in the BungeeCord configuration guide.
For a separate UDP port, add this JVM argument before -jar in BungeeCord's startup command:
-Draknetify.bungee.portOverride=25570
The override belongs to the whole proxy process. For a configuration with multiple Minecraft listeners, check the actual RakNet endpoints in the startup log before adding firewall rules. Restart BungeeCord after changing the argument.
Preserve account authentication at the proxy. For Spigot backends, BungeeCord's IP forwarding guide pairs ip_forward: true on the proxy with settings.bungeecord: true on the backend. Forwarding alone does not prevent someone from connecting directly to a backend. Restrict backend access using the firewall instructions.
Both proxy overrides accept ports from 1 through 65534. Invalid values are ignored, so verify the bound UDP port in the startup log. Remove the argument and restart to return to the Minecraft listener's port number.
Players connect to the proxy's public hostname and UDP port, for example raknet;play.example.com:25570. When a router translates ports, use its public UDP port in the client address. Addresses without the raknet; prefix continue to use the proxy's TCP listener.
Leave Query, Geyser, and other UDP services on separate UDP ports. A different TCP port does not resolve a UDP socket conflict.
Simple Voice Chat uses its own proxy plugin and UDP port on Velocity and BungeeCord. Follow the Voice Chat proxy guidance for that setup.
If a separate UDP relay sits in front of your Minecraft proxy and sends PROXY protocol v2 headers, configure Raknetify2 using UDP forwarding and PROXY protocol. Installing Velocity or BungeeCord by itself does not require that configuration.
Test from outside your local network with a Raknetify2 client. Join through the proxy, switch between the backend servers you use, and confirm that player identity and permissions remain correct.
- If TCP through the proxy works but RakNet times out, check the proxy's UDP listener, public port, IPv4 and IPv6 routes, and firewall rules.
- If both transports fail when the proxy connects to a backend, check that backend's TCP address, access rules, and player forwarding configuration.
- If the proxy reports an occupied UDP port, check for Query, Geyser, a voice proxy, or another process bound to it.
For reports, include both proxy and backend logs from the same connection attempt. See Troubleshooting for the version information to include.
This guide is for server operators. Raknetify2 needs a working UDP route to the server or proxy accepting RakNet connections. The default setup uses the same port number as Minecraft's TCP listener.
For players on the same local network, use the server's local address and allow UDP through its host firewall. Router port forwarding is needed when internet traffic must cross your router's IPv4 NAT.
Send public UDP traffic to the machine running the Minecraft server with Raknetify2. The destination port is that server's RakNet UDP listener. Allow that port in the server machine's host firewall. Keep its existing TCP route for ordinary Minecraft connections.
For example, if Raknetify2 listens on UDP 25570, forward the public UDP port to the server's local address on port 25570. The server's TCP port can stay at 25565. See direct-server listener settings to choose a different UDP port.
Send public UDP traffic to the machine running Velocity or BungeeCord with the Raknetify2 proxy plugin. Use the proxy's RakNet UDP listener as the forwarding destination. Keep the proxy's existing public TCP route for ordinary Minecraft connections.
The proxy connects to backend Minecraft servers over TCP. Adding Raknetify2 to the proxy does not require opening backend gameplay UDP ports to players.
| Connection | Access to allow |
|---|---|
| Players to the proxy | Public UDP to the RakNet listener, plus the existing public TCP listener |
| Proxy to backend servers | Backend Minecraft TCP ports, reachable only from the intended proxy hosts |
| Players directly to backend gameplay ports | Keep blocked, including through IPv6 |
When the proxy and backends run directly on a dedicated machine you control, backend listeners can use loopback addresses with the proxy configured to reach them there. Across machines, restrict backend TCP access to the proxy hosts using a firewall or an isolated private network. Containers and managed hosts need equivalent restrictions for their network layout. See Velocity's backend security guide and BungeeCord's firewall guide.
Player forwarding and firewall restrictions work together. Direct backend access can bypass the proxy's login checks. For plugin installation, forwarding settings, and UDP port overrides, follow Velocity and BungeeCord.
The public port and the listener's port can differ when a router translates between them:
| Setting | Port to use |
|---|---|
| Client server address | Public UDP port |
| Router forwarding rule's external port | Public UDP port |
| Router forwarding rule's internal port | RakNet listener's UDP port |
| Host firewall's local port | RakNet listener's UDP port |
For hosting behind an IPv4 router:
- Find the local IPv4 address of the machine accepting RakNet connections. Use a DHCP reservation or a suitable static address so the forwarding rule continues to target that machine.
- Add a UDP forwarding rule for the public port players will use.
- Set the rule's destination to that machine's local address and the RakNet listener's UDP port.
- Allow inbound UDP on the listener's port in the host firewall.
For example, a server listening on UDP port 25565 can use a rule with public port 25565, destination address 192.168.1.100, and destination port 25565. Replace the example address with your server's actual local address.
Keep the existing TCP rule for ordinary Minecraft connections. A TCP forwarding rule alone does not carry UDP.
Check whether another router or your ISP performs NAT before traffic reaches your router. With two routers you control, forwarding must cover both. If your ISP uses carrier-grade NAT, ask whether it can provide a public IPv4 address or use a hosting service or tunnel that supports inbound UDP. Your router's forwarding rule cannot configure the ISP's NAT. See TP-Link's port forwarding guidance for the public WAN address requirement.
Allow the selected UDP port through both the router's IPv6 firewall and the host firewall. Target the IPv6 address of the machine accepting RakNet connections.
Check that the hostname's IPv6 address points to that machine. If its IPv6 address changes, update the DNS record and any address-specific firewall rules.
A hostname that publishes both IPv4 and IPv6 addresses needs a working route for each advertised address. Check both sets of rules when one player can connect and another cannot.
If IPv4 forwarding changes the port number, make sure the port players enter also reaches the IPv6 listener. An IPv4 port translation does not configure the IPv6 route.
The provider or tunnel must support UDP on the public endpoint you give players. Check its port allocations and network firewall rules as well as the server's own firewall.
If an additional UDP proxy forwards client addresses using PROXY protocol v2, follow UDP forwarding and PROXY protocol and restrict access to the receiving UDP listener to the trusted proxy.
Connect from outside the server's local network with an updated Raknetify2 client, using an address such as raknet;play.example.com:25565. Use the public UDP port in this address.
Use a real RakNet connection to verify the route. A UDP scan that receives no response can report an inconclusive result because a working service may discard an unfamiliar probe. Nmap's UDP scan documentation explains this behaviour.
A successful TCP connection confirms only the TCP route. If RakNet times out, check the listener, forwarding destination, UDP port, and firewall rules using the troubleshooting guide.
Check compatibility for the particular release you download. The development branch can contain support that has not appeared in a release yet.
For Fabric, download compatibility.json from the same release as the JAR. Check your Minecraft version in gameVersions, then check the relevant entry under runtimes for its depends requirements. This JSON file is a reference document and does not need to go in the mods folder.
For Forge, NeoForge, and Spigot/Paper, check the version requirements declared by the artifact and its download listing. Support on one loader does not establish support on another.
The Java requirement declared by Raknetify2 is its minimum. Minecraft or the loader may require a newer runtime. Choose a Java version that satisfies all three.
Use the same Raknetify2 release on the client and the server or proxy accepting its connection when possible. Check the release notes before mixing releases. Encrypted RakNet connections require support for the authenticated encryption protocol at both ends. Original Raknetify and Raknetify2 builds from before that protocol was introduced cannot make these encrypted connections to updated peers.
Raknetify2 carries Minecraft's existing game protocol. Connecting different Minecraft versions requires a compatible protocol translation setup.
The build workflow includes compatibility checks involving Polymer, Krypton, PacketFixer, and Fast IP Ping. Those checks cover the versions and combinations selected by the workflow. Check a release's associated build results when investigating a particular combination.
For a failure in a larger modpack, follow the troubleshooting guide. Include the complete mod versions in your report.
Normally, Raknetify2 lets independent packet channels continue while one channel waits for missing data. Ordered mode puts all Minecraft packets on one channel, so a missing packet holds up every later packet in that direction until it is retransmitted. This preserves the order expected by some anti-cheat software, but gives up Raknetify2’s ability to keep unrelated game traffic moving during that wait.
-
Install a Raknetify2 build that supports ordered mode on the server or proxy accepting RakNet connections and on each RakNet client.
-
Create
config/raknetify2-compatibility.jsonrelative to that server or proxy’s working directory. Create theconfigdirectory if it does not exist. -
Add the following:
{"mode": "ordered"} -
Restart the server or proxy.
Clients follow the server’s setting automatically. Players do not need to create a configuration file or change their RakNet server address.
All Minecraft packets use one reliable ordered channel in each direction, including bundle delimiters and world transitions.
When players connect through Velocity or BungeeCord, configure ordered mode on that proxy, even if the anti-cheat runs on a backend server.
The policy applies across backend switches. In ordered mode, the proxy forwards backend keepalive requests to the real client instead of answering them locally.
On the first RakNet connection, the console reports:
Raknetify2 compatibility: ordered (updated clients required, genuine acknowledgements)
A successful compatibility exchange also logs ordered compatibility negotiated, followed by the peer’s address.
Keep anti-cheat checks enabled and validate your particular setup.
RakNet clients that do not support ordered mode cannot connect to a server requiring it. Update Raknetify2 on those clients, or connect using the server or proxy’s normal TCP address and port without the raknet; prefix.
Change the file to:
{"mode": "multichannel"}Then restart the server or proxy. Removing the file also restores multichannel mode after a restart.
The file must contain exactly one setting named mode, with either "ordered" or "multichannel" as its value. The values are case-sensitive.
Invalid or unreadable configuration rejects RakNet connections. Correct the file and restart the process.
If the console still reports multichannel, check that the file is in the working directory of the server or proxy accepting the RakNet connection, then restart that process.
Fabric, Forge, and NeoForge servers can select RakNet when transferring a capable client to a configured destination. This uses Minecraft's native transfer support, introduced in Java Edition 1.20.5. Check that your Raknetify2 release supports the Minecraft version and loader at each end.
Install Raknetify2 on the sending server and client. The destination must provide a compatible RakNet listener and accept incoming Minecraft transfers.
This configuration applies to transfers sent by the three mod loaders above. The Spigot/Paper, Velocity, and BungeeCord plugins do not read this transfers file.
Create config/raknetify2-transfers.json in the sending server's directory:
{
"destinations": [
{
"host": "play.example.com",
"tcpPort": 25565,
"udpPort": 25570
}
]
}Replace the example hostname and ports with your destination's values, then restart the sending server. Additional destinations go in the same array.
| Field | Meaning |
|---|---|
host |
Destination hostname or IP address, without a transport prefix or port |
tcpPort |
Destination port in the original transfer request |
udpPort |
Public RakNet port the transferred client should contact |
The TCP and UDP port numbers can be equal. If a router translates the UDP port, use the public port in this file. Write ports as JSON numbers.
Send transfers to the destination's ordinary hostname and TCP port. Raknetify2 checks whether the client advertises automatic-transfer support. For a capable client and a matching destination, it selects the configured UDP port. Other clients and unmatched destinations keep the original transfer address.
Matching uses the hostname and TCP port from the transfer request. Hostname capitalisation, a final DNS dot, and equivalent IPv6 spelling are normalised. DNS lookups do not participate in matching, so two different hostnames that resolve to the same address need separate entries. Wildcard entries are unsupported.
For a destination using Minecraft's server.properties, set accepts-transfers=true and restart it. A destination proxy may have its own transfer setting. Minecraft's default rejects incoming transfers, even when a normal direct join works.
The destination's RakNet listener, public UDP forwarding, and host firewall must already be configured. The sending server's transfers file selects the address sent to a client.
Check both the destination's IPv4 and IPv6 routes when its hostname publishes both address types. Test an ordinary direct RakNet connection to the destination before investigating automatic transfer behaviour.
Keep any destination login or admission checks in place. This configuration does not grant players access or replace server authentication.
Missing fields, unknown fields, invalid ports, and duplicate destinations cause a configuration error during initialisation. Use the server log to identify the error, correct the JSON, and restart.
To disable automatic selection, remove the configuration file or use {"destinations": []}, then restart the sending server. Its transfer requests will keep their original addresses.
A UDP proxy can forward RakNet traffic and preserve the original client address using PROXY protocol v2. Enable this feature when an upstream UDP proxy sends those headers to your listener. Ordinary router port forwarding does not require it.
On the server or Minecraft proxy receiving the forwarded UDP traffic, create config/raknetify2-proxy-protocol.json:
{
"trustedProxies": ["192.0.2.10"]
}Replace the example with the UDP proxy's actual source IP address or a CIDR range you control. The address must match what the receiving listener sees after any intervening NAT. IPv4 and IPv6 literals are accepted. DNS hostnames are rejected. Restart the receiving server or proxy.
Configure the forwarding proxy to send PROXY protocol v2 headers for UDP. Raknetify2 accepts forwarded client addresses only from the listed sources. Direct RakNet connections without those headers are rejected while this configuration is enabled. The TCP listener keeps its existing configuration.
Each listed proxy is trusted to supply client addresses. Restrict access to the backend UDP port in its firewall so only the intended proxy can reach it. Keep the trusted ranges as narrow as your network allows.
The file must contain only trustedProxies, with at least one entry. An empty array is an error. An invalid file prevents the RakNet listener from starting.
To return to direct UDP connections, remove the file and restart the listener. Update the upstream forwarding behaviour and firewall rules for the new route at the same time.
If connections fail after enabling this feature, check the proxy's actual source address at the backend, the configured trusted range, and whether the proxy emits UDP PROXY protocol v2 headers.
For Minecraft proxy installation and backend configuration, follow Velocity and BungeeCord.
Raknetify2 can share its server UDP listener with Simple Voice Chat on Fabric, Forge, NeoForge, Spigot, and Paper.
Install Simple Voice Chat on the server and on each client that wants voice chat. Follow its server setup guide for the rest of its configuration.
Use the server's top-level config directory for Raknetify2's file, including on Spigot/Paper. Simple Voice Chat's own file remains in the platform-specific location below.
-
Create
config/raknetify2-voicechat.jsonin the server directory with this content:{"enabled": true} -
Set
port=-1in Simple Voice Chat's server configuration. On modded servers, this isconfig/voicechat/voicechat-server.properties. On Spigot/Paper, it isplugins/voicechat/voicechat-server.properties. -
Leave
bind_addressempty when there is one matching RakNet listener. If the server has multiple listeners on that UDP port, set it to the local address of the listener you want to share. -
Restart the server and run
/voicechat test <PLAYERNAME>for a connected player.
If the RakNet listener uses a different port from Minecraft, set the voice port to that local UDP port explicitly instead of using -1. For example, a RakNet listener on local UDP port 25570 needs port=25570.
Set voice_host when clients need a different public address or port. For a router forwarding public UDP 25580 to local UDP 25570, use port=25570 and voice_host=play.example.com:25580. The public address belongs in voice_host. The bind_address setting selects a local listener.
Raknetify2 supplies the shared UDP socket through Simple Voice Chat's API. Simple Voice Chat handles voice authentication and encryption. Players can use voice chat with either TCP or RakNet gameplay connections.
Keep Query and Geyser on separate UDP ports. The shared socket integration supports Simple Voice Chat only.
The integration does not share a voice-proxy socket on Velocity or BungeeCord. Follow Simple Voice Chat's proxy setup guide and give the voice proxy its own UDP port. With the official voice proxy plugin, set any public voice_host override in the proxy's voice configuration. That plugin ignores backend servers' voice_host settings.
For a generic UDP tunnel, set voice_host to the public hostname and UDP port that forwards to this server.
If the log reports No RakNet listener matches the voice bind address and port, confirm that RakNet started successfully and that the voice port and bind address match its local listener.
If it reports Multiple RakNet listeners match the voice bind address, choose a specific matching local address in bind_address and restart.
Only one Simple Voice Chat plugin can supply its UDP socket. If startup reports that another plugin already supplies a socket, choose which socket integration to use.
To disable Raknetify2's integration, set {"enabled": false} in its voice configuration or remove that file. Give Simple Voice Chat a separate UDP port, update its firewall or forwarding rules, and restart the server.
Check these in order:
- The client has the correct Raknetify2 mod for its loader and Minecraft version.
- The server or proxy accepting the connection has Raknetify2 installed and started without a listener error.
- The address starts with
raknet;and uses the public UDP port. - The hosting provider, router, and host firewall all allow UDP on that port.
- The hostname's IPv4 and IPv6 addresses lead to the intended host and have working firewall rules.
A successful TCP connection confirms only the TCP route. Follow Firewall and router configuration to check UDP forwarding and IPv6 access. If PROXY protocol is enabled, clients must reach the listener through a configured trusted proxy.
Check for another process using the UDP port. Query, Geyser, and other UDP services need their own ports. Simple Voice Chat can use the shared-port integration.
You can choose another local UDP port using the direct-server listener settings or the Velocity and BungeeCord settings. Check the version requirement for the Spigot/Paper setting. Changing only a router's public port leaves the local socket conflict in place.
Connect directly to the destination using its raknet; address. If that fails, fix the destination listener or network route first.
If direct connections work, check whether the destination accepts incoming transfers. A Minecraft server using server.properties needs accepts-transfers=true. Direct joins do not test this setting.
Then compare the transfer hostname and TCP port with config/raknetify2-transfers.json on the sending server. Confirm that the file was loaded after a restart and that the client supports automatic RakNet transfers. See Automatic transfers.
Check the Raknetify2 versions at both ends of the connection. Update the client and the server or proxy together when a release changes the encrypted protocol. Preserve the server's authentication settings while investigating.
Record which action triggers the failure, such as opening an inventory, receiving a resource pack, changing worlds, or spawning an entity. Compare the same action over TCP and RakNet using a separate test installation when practical.
Some custom payloads depend on the order of vanilla packets. Mod authors can declare these dependencies through the packet ordering interface.
Open an issue in the Raknetify2 issue tracker and include:
- Minecraft, Java, loader, and Raknetify2 versions on both ends.
- Server and proxy software versions, including any UDP forwarding proxy.
- Other installed mods and their versions.
- Steps to reproduce the problem and what you expected to happen.
- Whether the same steps work over TCP.
- Relevant client, server, and proxy log excerpts from the same attempt.
Remove access tokens, passwords, and other private information before uploading logs. Preserve the exception messages and stack traces needed to diagnose the problem.
Raknetify2 lets mods declare which Minecraft traffic must remain ordered with their custom payloads. Use this when handling a payload requires an entity, chunk, inventory, or other state established by earlier packets.
| Group | Related traffic |
|---|---|
ui |
World-independent menus and interactions |
entity |
Entity spawn, removal, and movement |
world_interaction |
Inventories and other world-dependent interactions |
effects |
Sounds and particles |
chunk |
Terrain, block, and lighting updates |
All groups retain reliable ordered delivery within their channel. Packets in different groups can arrive in a different relative order. Choose the group matching the payload's dependency.
Add a provider under the raknetify:packet_channels entrypoint in your mod's fabric.mod.json. The provider implements Consumer<BiConsumer<String, String>> using JDK types. It receives a registrar that accepts a custom payload identifier and an ordering group.
Merge this entry into your existing metadata, replacing the class name with your provider's fully qualified name:
{
"entrypoints": {
"raknetify:packet_channels": [
"com.example.mod.OrderingProvider"
]
}
}Retain the rest of your fabric.mod.json, including its existing entrypoints. This is a fragment of the metadata file.
For example, an entity movement extension can register example:entity_path with the entity group. The PacketOrdering API documentation includes the provider implementation.
Fabric leaves this entrypoint uninvoked when Raknetify2 is absent. Providers should declare identifiers and groups during initialisation without relying on another mod having finished its own initialisation.
Forge and NeoForge mods, and server or proxy plugins, can call PacketOrdering.register(identifier, group) during initialisation when Raknetify2 is available. The class is com.ishland.raknetify.api.PacketOrdering. Register before accepting player connections, and keep optional integration code from loading Raknetify2 classes when the dependency is absent.
Declarations apply to new connections. Existing connections retain the rules they received at setup. Repeating an identical declaration is allowed. Conflicting groups for the same identifier are rejected.
Payload identifiers must use a valid custom namespace. The minecraft namespace is reserved. The endpoint-wide limit is 128 declarations, including built-in rules and registrations from other mods. Identifiers can contain up to 255 ASCII characters using the API's namespaced identifier syntax.
Updated RakNet peers exchange declarations during connection setup. A server or proxy can use a peer's declaration when it has no local rule for that payload. Local rules take precedence, and a peer's declarations remain scoped to that connection.
See UDP forwarding and PROXY protocol for UDP relays and forwarded client addresses.
For Minecraft proxy setup, see Velocity and BungeeCord.