Skip to content

Wiki enws

Jump to bottom
pjscruggs edited this page Nov 11, 2026 · 1 revision

Raknetify2 · Shakespearean English (Kingdom of England)

Tongue

Theatres

Through RakNet may Minecraft clients and theatres commune.

Fetch · GitHub

Minecraft Raknetify2 Client / Theatre
Fabric mods/raknetify2-fabric-*.jar Client / Theatre
Forge mods/raknetify2-forge-*.jar Client / Theatre
NeoForge mods/raknetify2-neoforge-*.jar Client / Theatre
Spigot / Paper plugins/raknetify2-spigot-*.jar Theatre
Velocity plugins/raknetify2-velocity-*.jar Velocity
BungeeCord plugins/raknetify2-bungee-*.jar BungeeCord

Add Theatre

  1. Theatres

  2. Add Theatre

  3. Theatre Address

    Theatre Address
    RakNet · UDP raknet;play.example.com:25565
    TCP play.example.com:25565

  4. Done

  5. Enter Theatre

F3 · Raknetify2

F3
RakNet · UDP In service · MTU 1400
TCP At rest

Velocity / BungeeCord

  1. Client · Raknetify2 → UDP → Velocity / BungeeCord · Raknetify2
  2. Velocity / BungeeCord → TCP → Theatre
Port Numbah · 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

Father time hath froze

Theatre Address UDP
raknet;play.example.com:25580 play.example.com:25580 → NAT → 192.0.2.10:25570
Theatre · 192.0.2.10 25570/udp

config/raknetify2-compatibility.json

Theatre / Velocity / BungeeCord

JSON
① ② ③ {"mode":"ordered"}
① ∥ ② ∥ ③ {"mode":"multichannel"}

Simple Voice Chat

Theatre 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

PROXY protocol v2 · UDP

Theatre 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"]}

Minecraft ≥ 1.20.5 · /transfer

  1. Theatre A · Fabric / Forge / NeoForge · config/raknetify2-transfers.json

    {"destinations":[{"host":"play.example.com","tcpPort":25565,"udpPort":25570}]}

  2. Theatre B · play.example.com · server.properties → accepts-transfers=true

  3. Theatre A · /transfer play.example.com 25565 Alex → Client (Alex) → RakNet · play.example.com:25570

PacketOrdering

Minecraft
ui At thy choice, then:
entity Restless Skeleton
world_interaction Inventory
effects Motes
chunk Blocks

PacketOrdering.java

Incompatible form!

Report Issues

The first scene

Raknetify2

Raknetify2 conveys the traffic of a Minecraft multiplayer game by RakNet over UDP. Each channel keeps its own order. Should one packet go astray, the other channels may still deliver theirs. Thus may the game answer its players whilst missing data is sent again or chunks are in transit.

Raknetify2 descends from Raknetify, the work of ishland, and is maintained apart. It brings the work to newer versions of Minecraft and keeps the transport, the platform integrations and their trials in good order.

Begin here

  1. Examine Minecraft and mod compatibility.
  2. Select a fetch and install it.
  3. Connect with an address such as raknet;play.example.com.

Directions for the keeper of a theatre

Mod authors can employ the packet ordering interface to declare dependencies between custom payloads and Minecraft traffic.

Books and records

Raknetify2 is issued under the MIT licence and preserves the original notices of copyright. Its networking rests upon Raknetify and netty-raknet.

Setting the stage

Fetch a release from GitHub Releases. Examine the Minecraft version and loader requirements for that release ere installing.

Where the stage is to be set 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 halt the server ere replacing its JAR. Take away the original Raknetify JAR and any older Raknetify2 JAR from the same Setting the stage ere adding the new file.

Client folders belong to the Minecraft instance or modpack thou dost launch. Server and proxy folders belong to that server or proxy Setting the stage. Create the appropriate folder if thy loader hath not created it yet.

Direct server connections

  1. Install the client mod for thy loader.
  2. Furnish the server with the matching mod, or, where the server admits it, with the Spigot/Paper plugin.
  3. Follow Firewall and router configuration to permit UDP connections to the server.
  4. Start anew the client and server.
  5. Add a server address such as raknet;play.example.com or raknet;play.example.com:25565.

Addresses without the raknet; prefix employ TCP.

Installing the client mod alone doth 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.

Velocity and BungeeCord

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 employ.

A separate UDP listener port

For a direct Minecraft server, set the appropriate Java argument below. Proxy operators should employ 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 employ 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 ere -jar in the Java command, or in thy host's JVM arguments field. Start anew the server and permit 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, employ 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. Examine the startup log for the bound UDP address and port. Take away the argument and start anew to return to the TCP listener's port number.

A router or UDP proxy may offer another public UDP port and convey its traffic to the present listener. No alteration to the server’s Java arguments is required.

Development builds

Open a successful main run in GitHub Actions and fetch its Artifacts archive. GitHub requires an account to fetch workflow artifacts. Employ the Setting the stage table above to select a JAR from the archive.

Velocity and BungeeCord

Velocity and BungeeCord stand between the players and the backend Minecraft servers. Let Raknetify2 be installed upon the proxy and upon every client that shall connect by RakNet.

Raknetify2 client --UDP--> Velocity or BungeeCord --TCP--> the backend server

The backend servers do not need Raknetify2 for this connection path. They still need the mods, plugins, and forwarding support required by thy network. Raknetify2 doth not translate Minecraft versions or change the proxy's account authentication.

Install the proxy plugin

  1. Make certain that ordinary TCP connections through thy proxy work, including authentication and switching between backend servers.
  2. Halt the proxy and fetch the matching plugin from GitHub Releases.
  3. Put raknetify2-velocity-*-all.jar or raknetify2-bungee-*-all.jar in the proxy's plugins folder. Take away any older Raknetify or Raknetify2 plugin from that folder.
  4. Install the appropriate Raknetify2 client mod by means of the Setting the stage book of directions.
  5. Examine the listener settings below, start anew the proxy, and inspect its log for RakNet listener faults.
  6. Permit public UDP traffic to the proxy and restrict backend gameplay ports as described in Firewall and router configuration.

Employ compatible Raknetify2 releases on the client and proxy. Examine Compatibility ere mixing releases.

Velocity

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. Consult Velocity's configuration reference.

To employ a separate UDP port, add this JVM argument ere -jar in Velocity's startup command:

-Draknetify.velocity.portOverride=25570

Replace 25570 with thy chosen port. This changes the RakNet UDP port whilst retaining Velocity's TCP port and backend addresses. Start anew Velocity after changing the argument.

Configure player forwarding on both Velocity and its backends. Employ modern forwarding when the backend software supports it, and keep its forwarding secret private. Follow the backend-specific directions in Velocity's player information forwarding book of directions. Keep the backend firewall restrictions in place alongside forwarding.

BungeeCord

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 book of directions.

For a separate UDP port, add this JVM argument ere -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, examine the actual RakNet endpoints in the startup log ere adding firewall rules. Start anew BungeeCord after changing the argument.

Preserve account authentication at the proxy. For Spigot backends, BungeeCord's IP forwarding book of directions pairs ip_forward: true on the proxy with settings.bungeecord: true on the backend. Forwarding alone doth not prevent someone from connecting directly to a backend. Restrict backend access by means of the firewall directions.

Select the address players employ

Both proxy overrides accept ports from 1 through 65534. Invalid values are ignored, so verify the bound UDP port in the startup log. Take away the argument and start anew to return to the Minecraft listener's port number.

Players connect to the proxy's public hostname and UDP port, for instance raknet;play.example.com:25570. When a router translates ports, employ its public UDP port in the client address. Addresses without the raknet; prefix continue to employ the proxy's TCP listener.

Leave Query, Geyser, and other UDP services on separate UDP ports. A different TCP port doth not resolve a UDP socket conflict.

Voice Chat and additional UDP forwarding

On Velocity and BungeeCord, Simple Voice Chat hath a proxy plugin and a UDP port of its own. Consult the directions for a Voice Chat proxy when thou dost set it up.

If a separate UDP relay sits in front of thy Minecraft proxy and sends PROXY protocol v2 headers, configure Raknetify2 by means of UDP forwarding and PROXY protocol. Installing Velocity or BungeeCord by itself doth not require that configuration.

Put the connection to the proof

Test from outside thy local network with a Raknetify2 client. Join through the proxy, switch between the backend servers thou usest, and make certain that player identity and permissions remain correct.

  • If TCP through the proxy succeeds but RakNet times out, examine 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, examine that backend's TCP address, access rules, and player forwarding configuration.
  • If the proxy reports an occupied UDP port, examine 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. Consult When the performance falters for the version information to include.

Firewall and router configuration

This book of directions is for server operators. Raknetify2 requires 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, employ the server's local address and permit UDP through its host firewall. Router port forwarding is needed when internet traffic must cross thy router's IPv4 NAT.

Select the destination and port

Direct server

Send public UDP traffic to the machine running the Minecraft server with Raknetify2. The destination port is that server's RakNet UDP listener. Permit that port in the server machine's host firewall. Keep its existing TCP route for ordinary Minecraft connections.

For instance, 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. Consult direct-server listener settings to select a different UDP port.

Velocity or BungeeCord

Send public UDP traffic to the machine running Velocity or BungeeCord with the Raknetify2 proxy plugin. Employ 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 doth not require opening backend gameplay UDP ports to players.

Connection Access to permit
Players to the proxy Public UDP to the RakNet listener, together with the public TCP listener already in service
Proxy to backend servers The TCP ports of the backend Minecraft servers, which the appointed proxy hosts alone may reach
Players directly to backend gameplay ports Keep blocked, including through IPv6

When the proxy and backends run directly on a dedicated machine thou control, backend listeners can employ loopback addresses with the proxy configured to reach them there. Across machines, restrict backend TCP access to the proxy hosts by means of a firewall or an isolated private network. Containers and managed hosts need equivalent restrictions for their network layout. Consult Velocity's backend security book of directions and BungeeCord's firewall book of directions.

Player forwarding and firewall restrictions work together. Direct backend access can bypass the proxy's login examines. For plugin Setting the stage, forwarding settings, and UDP port overrides, follow Velocity and BungeeCord.

Public and local port numbers

Where a router translates between ports, the public port may bear a number different from that of the listener:

Setting Port to employ
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

IPv4 port forwarding

For hosting behind an IPv4 router:

  1. Find the local IPv4 address of the machine accepting RakNet connections. Employ a DHCP reservation or a suitable static address so the forwarding rule continues to target that machine.
  2. Add a UDP forwarding rule for the public port players will employ.
  3. Let the rule point to the local address of that machine and to the UDP port where RakNet listens.
  4. Permit inbound UDP on the listener's port in the host firewall.

For instance, a server listening on UDP port 25565 can employ a rule with public port 25565, destination address 192.168.1.100, and destination port 25565. Replace the instance address with thy server's actual local address.

Keep the existing TCP rule for ordinary Minecraft connections. A TCP forwarding rule alone doth not carry UDP.

When forwarding still fails

Examine whether another router or thy ISP performs NAT ere traffic reaches thy router. With two routers thou control, forwarding must cover both. If thy ISP uses carrier-grade NAT, ask whether it can provide a public IPv4 address or employ a hosting service or tunnel that supports inbound UDP. Thy router's forwarding rule cannot configure the ISP's NAT. Consult TP-Link's port forwarding guidance for the public WAN address condition.

IPv6 firewall rules

Permit 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.

Examine 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 requires a working route for each advertised address. Examine 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 doth not configure the IPv6 route.

Hosting providers and tunnels

The provider or tunnel must support UDP on the public endpoint thou give players. Examine its port allocations and network firewall rules as well as the server's own firewall.

If an additional UDP proxy forwards client addresses by means of PROXY protocol v2, follow UDP forwarding and PROXY protocol and restrict access to the receiving UDP listener to the trusted proxy.

Put the connection to the proof

Connect from outside the server's local network with an updated Raknetify2 client, by means of an address such as raknet;play.example.com:25565. Employ the public UDP port in this address.

Employ a real RakNet connection to verify the route. A UDP scan that receives no response can give an account of an inconclusive result because a working service may discard an unfamiliar probe. Nmap's UDP scan documentation explains this behavior.

A successful TCP connection confirms only the TCP route. If RakNet times out, examine the listener, forwarding destination, UDP port, and firewall rules by means of the When the performance falters book of directions.

Compatibility

Examine compatibility for the particular release thou dost fetch. The development branch can contain support that hath not appeared in a release yet.

Minecraft and Java versions

For Fabric, fetch compatibility.json from the same release as the JAR. Examine thy Minecraft version in gameVersions, thereupon examine the relevant entry under runtimes for its depends requirements. This JSON file is a reference document and doth not must go in the mods folder.

For Forge, NeoForge, and Spigot/Paper, examine the version requirements declared by the artifact and its fetch listing. Support on one loader doth not establish support on another.

The Java condition declared by Raknetify2 is its minimum. Minecraft or the loader may require a newer runtime. Select a Java version that satisfies all three.

Client and server versions

Employ the same Raknetify2 release on the client and the server or proxy accepting its connection when possible. Examine the release notes ere mixing releases. Encrypted RakNet connections require support for the authenticated encryption protocol at both ends. Original Raknetify and Raknetify2 builds from ere that protocol was introduced cannot make these encrypted connections to updated peers.

Raknetify2 carries the game protocol that Minecraft already employs. To join two different versions of Minecraft, thou must provide a fitting protocol translator.

Other mods

The build workflow includes compatibility examines involving Polymer, Krypton, PacketFixer, and Fast IP Ping. Those examines cover the versions and combinations selected by the workflow. Examine a release's associated build results when investigating a particular combination.

For a failure in a larger modpack, follow the When the performance falters book of directions. Include the complete mod versions in thy give an account of.

Ordered mode

Ordered mode

Normally, Raknetify2 lets independent packet channels continue whilst 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.

Enabling ordered mode

  1. Both the server or proxy that accepts RakNet connections and every RakNet client must have a build of Raknetify2 that can perform ordered mode.

  2. Create config/raknetify2-compatibility.json relative to that server or proxy’s working directory. Create the config directory if it doth not exist.

  3. Add what followeth:

    {"mode": "ordered"}

  4. Start anew the server or proxy.

Clients follow the server’s setting automatically. Players do not must create a configuration file or change their RakNet server address.

All Minecraft packets employ one reliable ordered channel in each direction, including bundle delimiters and world transitions.

Proxy setups

When the players enter by Velocity or BungeeCord, set ordered mode upon that proxy, though the anti-cheat itself be on a backend server.

Changing backends doth not change this rule. In ordered mode the proxy passes the keepalive requests of the backend to the actual client, leaving the answering to that client.

Checking the setting

When the first RakNet connection is made, the console gives this account:

Raknetify2 compatibility: ordered (updated clients required, genuine acknowledgements)

If the compatibility exchange succeeds, the log likewise records ordered compatibility negotiated, followed by the address of the peer.

Keep anti-cheat examines enabled and validate thy particular setup.

Older clients

RakNet clients that do not support ordered mode cannot connect to a server requiring it. Update Raknetify2 on those clients, or connect by means of the server or proxy’s normal TCP address and port without the raknet; prefix.

Returning to multichannel mode

Change the file to:

{"mode": "multichannel"}

Thereupon start anew the server or proxy. Taking away the file also restores multichannel mode after a start anew.

Configuration problems

The file shall hold but one setting, named mode, whose value must be either "ordered" or "multichannel". Take heed of capital and small letters.

Invalid or unreadable configuration rejects RakNet connections. Correct the file and start anew the process.

If the console still reports multichannel, examine that the file is in the working directory of the server or proxy accepting the RakNet connection, thereupon start anew that process.

Automatic transfers

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. Examine that thy Raknetify2 release supports the Minecraft version and loader at each end.

Equip both the sending server and the client with Raknetify2. Their destination must have a fitting RakNet listener and must admit incoming Minecraft transfers.

These settings govern the transfers sent by the three mod loaders named above. The plugins for Spigot/Paper, Velocity and BungeeCord read no such transfers file.

Configure the sending server

Create config/raknetify2-transfers.json in the sending server's directory:

{
  "destinations": [
    {
      "host": "play.example.com",
      "tcpPort": 25565,
      "udpPort": 25570
    }
  ]
}

Replace the instance hostname and ports with thy destination's values, thereupon start anew the sending server. Additional destinations go in the same array.

Field Meaning
host The hostname or IP address to which the player goes, with neither a transport prefix nor a port
tcpPort Destination port in the original transfer request
udpPort The public RakNet port to which the client shall turn after transfer

The TCP and UDP port numbers can be equal. If a router translates the UDP port, employ the public port in this file. Write ports as JSON numbers.

Send transfers to the destination's ordinary hostname and TCP port. Raknetify2 examines 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.

The match is made upon the hostname and the TCP port in the transfer request. Differences in capital letters, a final DNS dot and equivalent spellings of IPv6 are accounted for. No DNS lookup enters into the match: two distinct hostnames that resolve to one address must therefore have separate entries. Wildcards are not admitted.

Destination setup

For a destination by means of Minecraft's server.properties, set accepts-transfers=true and start anew it. A destination proxy may have its own transfer setting. Minecraft's default rejects incoming transfers, even when a normal direct join succeeds.

The destination's RakNet listener, public UDP forwarding, and host firewall must first be configured. The sending server's transfers file selects the address sent to a client.

Examine both the destination's IPv4 and IPv6 routes when its hostname publishes both address types. Test an ordinary direct RakNet connection to the destination ere investigating automatic transfer behavior.

Keep any destination login or admission examines in place. This configuration doth not grant players access or replace server authentication.

Configuration faults and disabling

Missing fields, unknown fields, invalid ports, and duplicate destinations cause a configuration fault during initialization. Employ the server log to identify the fault, correct the JSON, and start anew.

To disable automatic selection, take away the configuration file or employ {"destinations": []}, thereupon start anew the sending server. Its transfer requests will keep their original addresses.

UDP forwarding and PROXY protocol

A UDP proxy can forward RakNet traffic and preserve the original client address by means of PROXY protocol v2. Enable this feature when an upstream UDP proxy sends those headers to thy listener. Ordinary router port forwarding doth not require it.

Upon the server or Minecraft proxy to which the UDP traffic is forwarded, make the file config/raknetify2-proxy-protocol.json:

{
  "trustedProxies": ["192.0.2.10"]
}

Replace the instance with the UDP proxy's actual source IP address or a CIDR range thou control. The address must match what the receiving listener sees after any intervening NAT. IPv4 and IPv6 literals are accepted. DNS hostnames are rejected. Start anew 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 whilst this configuration is enabled. The TCP listener keeps its existing configuration.

Trust and access

Every proxy here named is trusted to supply the addresses of clients. Order the backend firewall so that the appointed proxy alone may reach the backend UDP port. Grant thy trust to the narrowest address ranges that thy network permits.

The file must contain only trustedProxies, with at least one entry. An empty array is an fault. An invalid file prevents the RakNet listener from starting.

To return to direct UDP connections, take away the file and start anew the listener. Update the upstream forwarding behavior and firewall rules for the new route at the same time.

If connections fail after enabling this feature, examine 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 Setting the stage and backend configuration, follow Velocity and BungeeCord.

Simple Voice Chat

On Fabric, Forge, NeoForge, Spigot and Paper, Simple Voice Chat may share the server’s Raknetify2 UDP listener.

Install Simple Voice Chat on the server and on each client that wants voice chat. Follow its server setup book of directions for the rest of its configuration.

Employ 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.

Share the gameplay port

  1. Within the server directory make config/raknetify2-voicechat.json, and write therein:

    {"enabled": true}

  2. Set port=-1 in the server settings of Simple Voice Chat. For modded servers these lie in config/voicechat/voicechat-server.properties, for Spigot/Paper, in plugins/voicechat/voicechat-server.properties.

  3. Leave bind_address empty when there is one matching RakNet listener. If the server hath multiple listeners on that UDP port, set it to the local address of the listener thou wouldst to share.

  4. Start anew 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 by means of -1. For instance, a RakNet listener on local UDP port 25570 requires 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, employ 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 employ voice chat with either TCP or RakNet gameplay connections.

Other UDP services and proxies

Let Query and Geyser have separate UDP ports. Of the voice services, Simple Voice Chat alone may share this socket.

The integration doth not share a voice-proxy socket on Velocity or BungeeCord. Follow Simple Voice Chat's proxy setup book of directions 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 general UDP tunnel, give voice_host the public hostname and UDP port whence the traffic is sent to this server.

Disable sharing or resolve a socket conflict

If the log reports No RakNet listener matches the voice bind address and port, make certain 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, select a specific matching local address in bind_address and start anew.

One alone Simple Voice Chat plugin can supply its UDP socket. If startup reports that another plugin already supplies a socket, select which socket integration to employ.

To disable Raknetify2's integration, set {"enabled": false} in its voice configuration or take away that file. Give Simple Voice Chat a separate UDP port, update its firewall or forwarding rules, and start anew the server.

When the performance falters

TCP succeeds but RakNet times out

Examine these in order:

  1. The client hath the correct Raknetify2 mod for its loader and Minecraft version.
  2. The server or proxy accepting the connection hath Raknetify2 installed and started without a listener fault.
  3. The address beginneth with raknet; and pointeth to the public UDP port.
  4. The hosting provider, router, and host firewall all permit UDP on that port.
  5. Both addresses of the hostname, IPv4 and IPv6, lead to the appointed host, and its firewall permits the traffic on each.

A successful TCP connection confirms only the TCP route. Follow Firewall and router configuration to examine UDP forwarding and IPv6 access. If PROXY protocol is enabled, clients must reach the listener through a configured trusted proxy.

Address already in employ

Examine for another process by means of the UDP port. Query, Geyser, and other UDP services need their own ports. Simple Voice Chat can employ the shared-port integration.

Thou canst select another local UDP port by means of the direct-server listener settings or the Velocity and BungeeCord settings. Examine the version condition for the Spigot/Paper setting. Changing only a router's public port leaves the local socket conflict in place.

Joining succeeds but transfers fail

Connect directly to the destination by means of its raknet; address. If that fails, fix the destination listener or network route first.

If direct connections work, examine whether the destination accepts incoming transfers. A Minecraft server by means of server.properties requires accepts-transfers=true. Direct joins do not test this setting.

Thereupon compare the transfer hostname and TCP port with config/raknetify2-transfers.json on the sending server. Make certain that the file was loaded after a start anew and that the client supports automatic RakNet transfers. Consult Automatic transfers.

Encryption or protocol faults

Examine 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 whilst investigating.

Mod-specific failures

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 by means of a separate test Setting the stage when practical.

Certain custom payloads depend upon the order in which the vanilla packets arrive. Mod authors may declare that dependence by means of the packet ordering interface.

Report a fault

Open an issue in the Raknetify2 Register of faults and include:

  • The versions of Minecraft, Java, the loader and Raknetify2 at either end.
  • Which versions the server and proxy run, including the version of any proxy that forwards UDP.
  • Other installed mods and their versions.
  • Steps to reproduce the problem and what thou expected to happen.
  • Whether the same steps work over TCP.
  • Passages from the client, server and proxy logs that bear upon the same attempt.

Take away access tokens, passwords, and other private information ere uploading logs. Preserve the exception messages and stack traces needed to diagnose the problem.

Mod integration

Raknetify2 lets mods declare which Minecraft traffic must remain ordered with their custom payloads. Employ this when handling a payload requires an entity, chunk, inventory, or other state established by earlier packets.

Ordering groups

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. Select the group matching the payload's dependency.

Optional Fabric integration

Add a provider under the raknetify:packet_channels entrypoint in thy mod's fabric.mod.json. The provider implements Consumer<BiConsumer<String, String>> by means of JDK types. It receives a registrar that accepts a custom payload identifier and an ordering group.

Merge this entry into thy existing metadata, replacing the class name with thy provider's fully qualified name:

{
  "entrypoints": {
    "raknetify:packet_channels": [
      "com.example.mod.OrderingProvider"
    ]
  }
}

Retain the rest of thy fabric.mod.json, including its existing entrypoints. This is a fragment of the metadata file.

For instance, an entity movement extension can register example:entity_path with the entity group. The PacketOrdering API documentation includes the provider implementation.

In the absence of Raknetify2, Fabric calls no such entrypoint. During startup let each provider declare its identifiers and groups, without presuming that another mod hath finished its own preparations.

Registration behavior

Forge and NeoForge mods, and server or proxy plugins, can call PacketOrdering.register(identifier, group) during initialization when Raknetify2 is available. The class is com.ishland.raknetify.api.PacketOrdering. Register ere accepting player connections, and keep optional integration code from loading Raknetify2 classes when the dependency is absent.

A declaration governs connections yet to be made. Those already established keep the rules that they first received. The same declaration may be made again. Two conflicting groups for one identifier shall be rejected.

Payload identifiers must employ 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 by means of the API's namespaced identifier syntax.

Updated RakNet peers exchange declarations during connection setup. A server or proxy can employ a peer's declaration when it hath no local rule for that payload. Local rules take precedence, and a peer's declarations remain scoped to that connection.

UDP proxies

Consult UDP forwarding and PROXY protocol for UDP relays and forwarded client addresses.

For Minecraft proxy setup, consult Velocity and BungeeCord.

English (US)

Clone this wiki locally