Skip to content

Wiki enp

Jump to bottom
pjscruggs edited this page Nov 11, 2026 · 2 revisions

Raknetify2 · Anglish (Oned Riches)

Tongue

Maniplayer

RakNet links Minecraft guests and webthews over the net.

Download · GitHub

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

Eke Webthew

  1. Maniplayer

  2. Eke Webthew

  3. Webthew Link

    Webthew Link
    RakNet · UDP raknet;play.example.com:25565
    TCP play.example.com:25565

  4. Done

  5. Theed Webthew

F3 · Raknetify2

F3
RakNet · UDP At work · MTU 1400
TCP Idle

Velocity / BungeeCord

  1. Guest · Raknetify2 → UDP → Velocity / BungeeCord · Raknetify2
  2. Velocity / BungeeCord → TCP → Webthew
Harbor Rime · 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

Timed out

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

config/raknetify2-compatibility.json

Webthew / Velocity / BungeeCord

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

Simple Voice Chat

Webthew 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

Webthew Link trustedProxies RakNet
192.0.2.10 · PROXY v2 / UDP ["192.0.2.10"] ✓
192.0.2.11 · PROXY v2 / UDP ["192.0.2.10"] ✗
Guest → RakNet / UDP ["192.0.2.10"] ✗

config/raknetify2-proxy-protocol.json

{"trustedProxies":["192.0.2.10"]}

Minecraft ≥ 1.20.5 · /transfer

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

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

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

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

PacketOrdering

Minecraft
ui Kires
entity Boneframe
world_interaction Inholding
effects Specks
chunk Clots

PacketOrdering.java

Unthwear wharve!

Mield Bugs

Home

Raknetify2

Raknetify2 brooks RakNet over UDP for Minecraft maniplayer. It sends packs along sundry paths, each in its own order. If one path loses a pack, the others can keep sending. The game can still answer the player while lost bits are sent anew or chunks are on their way.

Raknetify2 is a fork of Raknetify, first made by ishland. It is kept up on its own. The fork works with newer Minecraft wharves and keeps up the net code, the ties to each loader and the trials that check whether they work together.

First steps

  1. Look over Minecraft and mod working together.
  2. Pick a download and set up it.
  3. Bind with an link such as raknet;play.example.com.

Webthew handbooks

Mod authors can brook the pack ordering joining point to declare dependencies between custom payloads and Minecraft flow.

Links for this work

Raknetify2 brooks the MIT license and keeps the first copyright notices. Its networking implementation builds on Raknetify and netty-raknet.

Setup

Download a release from GitHub Releases. Look over the Minecraft wharve and loader requirements for that release before setting up.

Where you are setting up File Folder
Fabric guest or webthew raknetify2-fabric-*.jar mods
Forge guest or webthew raknetify2-forge-*.jar mods
NeoForge guest or webthew raknetify2-neoforge-*.jar mods
Spigot or Paper webthew raknetify2-spigot-*.jar plugins
Velocity proxy raknetify2-velocity-*.jar plugins
BungeeCord proxy raknetify2-bungee-*.jar plugins

Close the guest or stop the webthew before replacing its JAR. Take out the first Raknetify JAR and any older Raknetify2 JAR from the same setup before adding the new file.

Guest folders belong to the Minecraft instance or modpack you launch. Webthew and proxy folders belong to that webthew or proxy setup. Create the appropriate folder if your loader has not created it yet.

Straight webthew links

  1. Set up the guest mod for your loader.
  2. Set up the matching webthew mod, or the Spigot/Paper add-on on a well-matched webthew.
  3. Follow Firewall and router settings to allow UDP links to the webthew.
  4. Restart the guest and webthew.
  5. Add a webthew link such as raknet;play.example.com or raknet;play.example.com:25565.

Links without the raknet; prefix brook TCP.

Setting up the guest mod alone does not add RakNet help to a remote webthew. The webthew operator must give a RakNet endpoint. Players joining someone else's webthew usually need no inbound router forwarding rules.

Velocity and BungeeCord

Set up the matching proxy add-on and the guest mod. Follow Velocity and BungeeCord for listener settings, backend forwarding, access restrictions, and the link players should brook.

A standalone UDP listener harbor

For a straight Minecraft webthew, set the right Java argument below. Proxy operators should brook the Velocity and BungeeCord listener settings.

Platform Java argument Accepted harbors
Fabric, Forge, or NeoForge webthew -Draknetify.fabric.portOverride=25570 1 through 65534
Spigot or Paper webthew -Draknetify.spigot.portOverride=25570 1 through 65535

Forge and NeoForge brook the shared listener code, so their property name also holds fabric. Replace 25570 with the desired UDP harbor.

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 webthew and allow UDP on the chosen listener harbor. If the outward-facing harbor is also 25570, bind with raknet;play.example.com:25570. If a router translates the harbor, brook its outward-facing harbor in the guest link. The TCP harbor stays at its current value.

On Spigot/Paper, the UDP listener keeps the Minecraft TCP listener's nearby bind link. An unsound override or occupied UDP harbor prevents RakNet from starting. Look over the startup log for the bound UDP link and harbor. Take out the argument and restart to go back to the TCP listener's harbor number.

A router or UDP proxy can also expose a unlike outward-facing UDP harbor and forward it to the current listener without changing the webthew's Java arguments.

Development builds

Open a successful main run in GitHub Actions and download its Artifacts archive. GitHub needs an account to download workflow artifacts. Brook the setup table above to pick a JAR from the archive.

Velocity and BungeeCord

Velocity and BungeeCord sit between players and backend Minecraft webthews. Set up Raknetify2 on the proxy and on each guest that will bind over RakNet.

Raknetify2 guest --UDP--> Velocity or BungeeCord --TCP--> backend webthew

The backend webthews do not need Raknetify2 for this link path. They still need the mods, add-ons, and forwarding help needed by your network. Raknetify2 does not translate Minecraft wharves or change the proxy's account authentication.

Set up the proxy add-on

  1. Make sure that usual TCP links through your proxy work, including authentication and switching between backend webthews.
  2. Stop the proxy and download the matching add-on from GitHub Releases.
  3. Put raknetify2-velocity-*-all.jar or raknetify2-bungee-*-all.jar in the proxy's plugins folder. Take out any older Raknetify or Raknetify2 add-on from that folder.
  4. Set up the appropriate Raknetify2 guest mod brooking the setup handbook.
  5. Look over the listener settings below, restart the proxy, and inspect its log for RakNet listener faults.
  6. Allow outward-facing UDP flow to the proxy and restrict backend gameplay harbors as described in Firewall and router settings.

Brook well-matched Raknetify2 releases on the guest and proxy. Look over Working together before mixing releases.

Velocity

The bind setting in velocity.toml chooses Velocity's Minecraft listening link and TCP harbor. Raknetify2 normally brooks the same harbor number for UDP. The [servers] listings identify the backend webthews. Keep those listings pointed at the backend TCP links. See Velocity's settings reference.

To brook a standalone UDP harbor, add this JVM argument before -jar in Velocity's startup command:

-Draknetify.velocity.portOverride=25570

Replace 25570 with your chosen harbor. This changes the RakNet UDP harbor while retaining Velocity's TCP harbor and backend links. Restart Velocity after changing the argument.

Set up player forwarding on both Velocity and its backends. Brook modern forwarding when the backend software works with it, and keep its forwarding secret private. Follow the backend-specific instructions in Velocity's player knowledge forwarding handbook. Keep the backend firewall restrictions in place alongside forwarding.

BungeeCord

In BungeeCord's config.yml, the host value under each listeners listing identifies a Minecraft listening link and TCP harbor. Raknetify2 normally adds UDP on that harbor number. The servers listings hold backend TCP links. These settings are described in the BungeeCord settings handbook.

For a standalone UDP harbor, add this JVM argument before -jar in BungeeCord's startup command:

-Draknetify.bungee.portOverride=25570

The override belongs to the whole proxy running task. For a settings with multiple Minecraft listeners, look over 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 handbook pairs ip_forward: true on the proxy with settings.bungeecord: true on the backend. Forwarding alone does not prevent someone from binding straight to a backend. Restrict backend access brooking the firewall instructions.

Pick the link players brook

Both proxy overrides take harbors from 1 through 65534. Unsound values are ignored, so check the bound UDP harbor in the startup log. Take out the argument and restart to go back to the Minecraft listener's harbor number.

Players bind to the proxy's outward-facing hostname and UDP harbor, for sample raknet;play.example.com:25570. When a router translates harbors, brook its outward-facing UDP harbor in the guest link. Links without the raknet; prefix continue to brook the proxy's TCP listener.

Leave Query, Geyser, and other UDP services on standalone UDP harbors. A unlike TCP harbor does not resolve a UDP socket conflict.

Voice Chat and further UDP forwarding

Simple Voice Chat brooks its own proxy add-on and UDP harbor on Velocity and BungeeCord. Follow the Voice Chat proxy guidance for that setup.

If a standalone UDP relay sits in front of your Minecraft proxy and sends PROXY protocol v2 headers, set up Raknetify2 brooking UDP forwarding and PROXY wire rules. Setting up Velocity or BungeeCord by itself does not need that settings.

Look over the link

Try from outside your nearby network with a Raknetify2 guest. Join through the proxy, switch between the backend webthews you brook, and make sure that player identity and permissions remain correct.

  • If TCP through the proxy works but RakNet times out, look over the proxy's UDP listener, outward-facing harbor, IPv4 and IPv6 routes, and firewall rules.
  • If both transports fail when the proxy binds to a backend, look over that backend's TCP link, access rules, and player forwarding settings.
  • If the proxy tells of an occupied UDP harbor, look over for Query, Geyser, a voice proxy, or another running task bound to it.

For tells of, give both proxy and backend logs from the same link attempt. See Troubleshooting for the wharve knowledge to give.

Firewall and router settings

This handbook is for webthew operators. Raknetify2 needs a working UDP route to the webthew or proxy accepting RakNet links. The starting setting setup brooks the same harbor number as Minecraft's TCP listener.

For players on the same nearby network, brook the webthew's nearby link and allow UDP through its host firewall. Router harbor forwarding is needed when internet flow must cross your router's IPv4 NAT.

Pick the goal and harbor

Straight webthew

Send outward-facing UDP flow to the machine running the Minecraft webthew with Raknetify2. The goal harbor is that webthew's RakNet UDP listener. Allow that harbor in the webthew machine's host firewall. Keep its current TCP route for usual Minecraft links.

For sample, if Raknetify2 listens on UDP 25570, forward the outward-facing UDP harbor to the webthew's nearby link on harbor 25570. The webthew's TCP harbor can stay at 25565. See straight-webthew listener settings to pick a unlike UDP harbor.

Velocity or BungeeCord

Send outward-facing UDP flow to the machine running Velocity or BungeeCord with the Raknetify2 proxy add-on. Brook the proxy's RakNet UDP listener as the forwarding goal. Keep the proxy's current outward-facing TCP route for usual Minecraft links.

The proxy binds to backend Minecraft webthews over TCP. Adding Raknetify2 to the proxy does not need opening backend gameplay UDP harbors to players.

Link Access to allow
Players to the proxy Outward-facing UDP to the RakNet listener, plus the current outward-facing TCP listener
Proxy to backend webthews Backend Minecraft TCP harbors, reachable only from the intended proxy hosts
Players straight to backend gameplay harbors Keep blocked, including through IPv6

When the proxy and backends run straight on a dedicated machine you control, backend listeners can brook loopback links with the proxy set up to reach them there. Across machines, restrict backend TCP access to the proxy hosts brooking a firewall or an isolated private network. Containers and managed hosts need equivalent restrictions for their network layout. See Velocity's backend security handbook and BungeeCord's firewall handbook.

Player forwarding and firewall restrictions work together. Straight backend access can bypass the proxy's login checks. For add-on setup, forwarding settings, and UDP harbor overrides, follow Velocity and BungeeCord.

Outward-facing and nearby harbor numbers

The outward-facing harbor and the listener's harbor can differ when a router translates between them:

Setting Harbor to brook
Guest webthew link Outward-facing UDP harbor
Router forwarding rule's external harbor Outward-facing UDP harbor
Router forwarding rule's internal harbor RakNet listener's UDP harbor
Host firewall's nearby harbor RakNet listener's UDP harbor

IPv4 harbor forwarding

For hosting behind an IPv4 router:

  1. Find the nearby IPv4 link of the machine accepting RakNet links. Brook a DHCP reservation or a suitable static link so the forwarding rule continues to target that machine.
  2. Add a UDP forwarding rule for the outward-facing harbor players will brook.
  3. Set the rule's goal to that machine's nearby link and the RakNet listener's UDP harbor.
  4. Allow inbound UDP on the listener's harbor in the host firewall.

For sample, a webthew listening on UDP harbor 25565 can brook a rule with outward-facing harbor 25565, goal link 192.168.1.100, and goal harbor 25565. Replace the sample link with your webthew's actual nearby link.

Keep the current TCP rule for usual Minecraft links. A TCP forwarding rule alone does not carry UDP.

When forwarding still fails

Look over whether another router or your ISP performs NAT before flow reaches your router. With two routers you control, forwarding must cover both. If your ISP brooks carrier-grade NAT, ask whether it can give a outward-facing IPv4 link or brook a hosting service or tunnel that works with inbound UDP. Your router's forwarding rule cannot set up the ISP's NAT. See TP-Link's harbor forwarding guidance for the outward-facing WAN link requirement.

IPv6 firewall rules

Allow the selected UDP harbor through both the router's IPv6 firewall and the host firewall. Target the IPv6 link of the machine accepting RakNet links.

Look over that the hostname's IPv6 link points to that machine. If its IPv6 link changes, bring up to date the DNS record and any link-specific firewall rules.

A hostname that publishes both IPv4 and IPv6 links needs a working route for each advertised link. Look over both sets of rules when one player can bind and another cannot.

If IPv4 forwarding changes the harbor number, make sure the harbor players enter also reaches the IPv6 listener. An IPv4 harbor translation does not set up the IPv6 route.

Hosting providers and tunnels

The provider or tunnel must help UDP on the outward-facing endpoint you give players. Look over its harbor allocations and network firewall rules as well as the webthew's own firewall.

If an further UDP proxy forwards guest links brooking PROXY protocol v2, follow UDP forwarding and PROXY wire rules and restrict access to the receiving UDP listener to the trusted proxy.

Look over the link

Bind from outside the webthew's nearby network with an newer Raknetify2 guest, brooking an link such as raknet;play.example.com:25565. Brook the outward-facing UDP harbor in this link.

Brook a real RakNet link to check the route. A UDP scan that receives no response can tell of an inconclusive result because a working service may discard an unfamiliar probe. Nmap's UDP scan handbook explains this working.

A successful TCP link confirms only the TCP route. If RakNet times out, look over the listener, forwarding goal, UDP harbor, and firewall rules brooking the troubleshooting handbook.

Working together

Look over working together for the particular release you download. The development branch can contain help that has not appeared in a release yet.

Minecraft and Java wharves

Minecraft and Java wharves · English

The Java requirement declared by Raknetify2 is its minimum. Minecraft or the loader may need a newer runtime. Pick a Java wharve that satisfies all three.

Guest and webthew wharves

Brook the same Raknetify2 release on the guest and the webthew or proxy accepting its link when possible. Look over the release notes before mixing releases. Encrypted RakNet links need help for the authenticated encryption wire rules at both ends. First Raknetify and Raknetify2 builds from before that wire rules was introduced cannot make these encrypted links to newer peers.

Raknetify2 carries Minecraft's current game wire rules. Binding unlike Minecraft wharves needs a well-matched wire rules translation setup.

Other mods

Other mods · English

For a failure in a larger modpack, follow the troubleshooting handbook. Give the complete mod wharves in your tell of.

Ordered mode

Ordered mode

Normally, Raknetify2 lets standalone pack channels continue while one channel waits for missing bits. Ordered mode puts all Minecraft packs on one channel, so a missing pack holds up every later pack 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 flow moving throughout that wait.

Enabling ordered mode

  1. Set up a Raknetify2 build that works with ordered mode on the webthew or proxy accepting RakNet links and on each RakNet guest.

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

  3. Add the following:

    {"mode": "ordered"}

  4. Restart the webthew or proxy.

Guests follow the webthew’s setting on its own. Players do not need to create a settings file or change their RakNet webthew link.

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

Proxy setups

When players bind through Velocity or BungeeCord, set up ordered mode on that proxy, even if the anti-cheat runs on a backend webthew.

The policy applies across backend switches. In ordered mode, the proxy forwards backend keepalive asks to the real guest instead of answering them locally.

Checking the setting

On the first RakNet link, the console tells of:

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

A successful working together exchange also logs ordered compatibility negotiated, followed by the peer’s link.

Keep the anti-cheat checks on and try them with your own setup.

Older guests

RakNet guests that do not help ordered mode cannot bind to a webthew requiring it. Bring up to date Raknetify2 on those guests, or bind brooking the webthew or proxy’s normal TCP link and harbor without the raknet; prefix.

Returning to multichannel mode

Change the file to:

{"mode": "multichannel"}

Then restart the webthew or proxy. Removing the file also restores multichannel mode after a restart.

Settings problems

The file must hold one setting alone, named mode. Its worth must be either "ordered" or "multichannel". Great and small letters are read differently.

Unsound or unreadable settings turns away RakNet links. Correct the file and restart the running task.

If the console still tells of multichannel, look over that the file is in the working directory of the webthew or proxy accepting the RakNet link, then restart that running task.

Self-acting handoffs

Fabric, Forge, and NeoForge webthews can choose RakNet when transferring a capable guest to a set up goal. This brooks Minecraft's native handoff help, introduced in Java Edition 1.20.5. Look over that your Raknetify2 release works with the Minecraft wharve and loader at each end.

Set up Raknetify2 on the sending webthew and guest. The goal must give a well-matched RakNet listener and take incoming Minecraft handoffs.

This settings applies to handoffs sent by the three mod loaders above. The Spigot/Paper, Velocity, and BungeeCord add-ons do not read this handoffs file.

Set up the sending webthew

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

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

Replace the sample hostname and harbors with your goal's values, then restart the sending webthew. Further goals go in the same array.

Field Meaning
host Goal hostname or IP link, without a transport prefix or harbor
tcpPort Goal harbor in the first handoff ask
udpPort Outward-facing RakNet harbor the transferred guest should contact

The TCP and UDP harbor numbers can be equal. If a router translates the UDP harbor, brook the outward-facing harbor in this file. Write harbors as JSON numbers.

Send handoffs to the goal's usual hostname and TCP harbor. Raknetify2 checks whether the guest advertises self-acting-handoff help. For a capable guest and a matching goal, it chooses the set up UDP harbor. Other guests and unmatched goals keep the first handoff link.

Matching brooks the hostname and TCP harbor from the handoff ask. Hostname capitalization, a final DNS dot, and equivalent IPv6 spelling are normalized. DNS lookups do not participate in matching, so two unlike hostnames that resolve to the same link need standalone listings. Wildcard listings are unsupported.

Goal setup

For a goal brooking Minecraft's server.properties, set accepts-transfers=true and restart it. A goal proxy may have its own handoff setting. Minecraft's starting setting turns away incoming handoffs, even when a normal straight join works.

The goal's RakNet listener, outward-facing UDP forwarding, and host firewall must already be set up. The sending webthew's handoffs file chooses the link sent to a guest.

If the goal’s hostname lists both IPv4 and IPv6 links, check both paths. First try binding straight to the goal with RakNet. Only then look into a self-acting handoff.

Keep any goal login or admission checks in place. This settings does not grant players access or replace webthew authentication.

Settings faults and disabling

Missing fields, unknown fields, unsound harbors, and duplicate goals cause a settings fault throughout initialization. Brook the webthew log to identify the fault, correct the JSON, and restart.

To turn off self-acting choice, take out the settings file or brook {"destinations": []}, then restart the sending webthew. Its handoff asks will keep their first links.

UDP forwarding and PROXY wire rules

A UDP proxy can forward RakNet flow and preserve the first guest link brooking PROXY protocol v2. Turn on this feature when an upstream UDP proxy sends those headers to your listener. Usual router harbor forwarding does not need it.

On the webthew or Minecraft proxy receiving the forwarded UDP flow, create config/raknetify2-proxy-protocol.json:

{
  "trustedProxies": ["192.0.2.10"]
}

Replace the sample with the UDP proxy's actual spring IP link or a CIDR range you control. The link must match what the receiving listener sees after any intervening NAT. IPv4 and IPv6 literals are accepted. DNS hostnames are turned away. Restart the receiving webthew or proxy.

Set up the forwarding proxy to send PROXY protocol v2 headers for UDP. Raknetify2 takes forwarded guest links only from the listed springs. Straight RakNet links without those headers are turned away while this settings is enabled. The TCP listener keeps its current settings.

Trust and access

Each named proxy is trusted to give the links of guests. Set the backend firewall so that only the chosen proxy can reach the backend UDP harbor. Keep the trusted ranges as small as the network will allow.

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

To go back to straight UDP links, take out the file and restart the listener. Bring up to date the upstream forwarding working and firewall rules for the new route at the same time.

If links fail after enabling this feature, look over the proxy's actual spring link at the backend, the set up trusted range, and whether the proxy emits UDP PROXY protocol v2 headers.

For Minecraft proxy setup and backend settings, follow Velocity and BungeeCord.

Simple Voice Chat

Raknetify2 can share its webthew UDP listener with Simple Voice Chat on Fabric, Forge, NeoForge, Spigot, and Paper.

Set up Simple Voice Chat on the webthew and on each guest that wants voice chat. Follow its webthew setup handbook for the rest of its settings.

Brook the webthew's top-step 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 harbor

  1. Create config/raknetify2-voicechat.json in the webthew directory with this content:

    {"enabled": true}

  2. Set port=-1 in Simple Voice Chat's webthew settings. On modded webthews, this is config/voicechat/voicechat-server.properties. On Spigot/Paper, it is plugins/voicechat/voicechat-server.properties.

  3. Leave bind_address empty when there is one matching RakNet listener. If the webthew has multiple listeners on that UDP harbor, set it to the nearby link of the listener you want to share.

  4. Restart the webthew and run /voicechat test <PLAYERNAME> for a bound player.

If the RakNet listener brooks a unlike harbor from Minecraft, set the voice port to that nearby UDP harbor explicitly instead of brooking -1. For sample, a RakNet listener on nearby UDP harbor 25570 needs port=25570.

Set voice_host when guests need a unlike outward-facing link or harbor. For a router forwarding outward-facing UDP 25580 to nearby UDP 25570, brook port=25570 and voice_host=play.example.com:25580. The outward-facing link belongs in voice_host. The bind_address setting chooses a nearby listener.

Raknetify2 supplies the shared UDP socket through Simple Voice Chat's API. Simple Voice Chat handles voice authentication and encryption. Players can brook voice chat with either TCP or RakNet gameplay links.

Other UDP services and proxies

Keep Query and Geyser on standalone UDP harbors. The shared socket integration works with Simple Voice Chat only.

The integration does not share a voice-proxy socket on Velocity or BungeeCord. Follow Simple Voice Chat's proxy setup handbook and give the voice proxy its own UDP harbor. With the official voice proxy add-on, set any outward-facing voice_host override in the proxy's voice settings. That add-on ignores backend webthews' voice_host settings.

For a generic UDP tunnel, set voice_host to the outward-facing hostname and UDP harbor that forwards to this webthew.

Turn off sharing or resolve a socket conflict

If the log tells of No RakNet listener matches the voice bind address and port, make sure that RakNet started successfully and that the voice harbor and bind link match its nearby listener.

If it tells of Multiple RakNet listeners match the voice bind address, pick a specific matching nearby link in bind_address and restart.

Only one Simple Voice Chat add-on can supply its UDP socket. If startup tells of that another add-on already supplies a socket, pick which socket integration to brook.

To turn off Raknetify2's integration, set {"enabled": false} in its voice settings or take out that file. Give Simple Voice Chat a standalone UDP harbor, bring up to date its firewall or forwarding rules, and restart the webthew.

Troubleshooting

TCP works but RakNet times out

Look over these in order:

  1. The guest has the correct Raknetify2 mod for its loader and Minecraft wharve.
  2. The webthew or proxy accepting the link has Raknetify2 set up and started without a listener fault.
  3. The link starts with raknet; and brooks the outward-facing UDP harbor.
  4. The hosting provider, router, and host firewall all allow UDP on that harbor.
  5. The hostname's IPv4 and IPv6 links lead to the intended host and have working firewall rules.

A successful TCP link confirms only the TCP route. Follow Firewall and router settings to look over UDP forwarding and IPv6 access. If PROXY wire rules is enabled, guests must reach the listener through a set up trusted proxy.

Link already in brook

Look over for another running task brooking the UDP harbor. Query, Geyser, and other UDP services need their own harbors. Simple Voice Chat can brook the shared-harbor integration.

You can pick another nearby UDP harbor brooking the straight-webthew listener settings or the Velocity and BungeeCord settings. Look over the wharve requirement for the Spigot/Paper setting. Changing only a router's outward-facing harbor leaves the nearby socket conflict in place.

Joining works but handoffs fail

Bind straight to the goal brooking its raknet; link. If that fails, fix the goal listener or network route first.

If straight links work, look over whether the goal takes incoming handoffs. A Minecraft webthew brooking server.properties needs accepts-transfers=true. Straight joins do not try this setting.

Then compare the handoff hostname and TCP harbor with config/raknetify2-transfers.json on the sending webthew. Make sure that the file was loaded after a restart and that the guest works with self-acting RakNet handoffs. See Self-acting handoffs.

Encryption or wire rules faults

Look over the Raknetify2 wharves at both ends of the link. Bring up to date the guest and the webthew or proxy together when a release changes the encrypted wire rules. Preserve the webthew's authentication settings while investigating.

Mod-specific failures

Record which action triggers the failure, such as opening an inventory, receiving a means pack, changing worlds, or spawning an entity. Compare the same action over TCP and RakNet brooking a standalone try setup when practical.

Some custom payloads depend on the order of vanilla packs. Mod authors can declare these dependencies through the pack ordering joining point.

Tell of a bug

Open an fault in the Raknetify2 Bugbook and give:

  • Minecraft, Java, loader, and Raknetify2 wharves on both ends.
  • Webthew and proxy software wharves, including any UDP forwarding proxy.
  • Other set up mods and their wharves.
  • The steps that bring on the fault again and what you thought would happen.
  • Whether the same steps work over TCP.
  • Relevant guest, webthew, and proxy log excerpts from the same attempt.

Take out access tokens, passwords, and other private knowledge before uploading logs. Preserve the exception messages and stack traces needed to diagnose the problem.

Mod integration

Raknetify2 lets mods declare which Minecraft flow must remain ordered with their custom payloads. Brook this when handling a payload needs an entity, chunk, inventory, or other state established by earlier packs.

Ordering groups

Group Related flow
ui World-standalone 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 changes

All groups keep reliable ordered delivery within their channel. Packs in unlike groups can arrive in a unlike relative order. Pick the group matching the payload's dependency.

By choice Fabric integration

Add a provider under the raknetify:packet_channels entrypoint in your mod's fabric.mod.json. The provider implements Consumer<BiConsumer<String, String>> brooking JDK types. It receives a registrar that takes a custom payload name and an ordering group.

Merge this listing into your current metadata, replacing the class name with your provider's fully qualified name:

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

Keep the rest of your fabric.mod.json, including its current entrypoints. This is a fragment of the metadata file.

For sample, an entity movement extension can register example:entity_path with the entity group. The PacketOrdering API handbook holds the provider implementation.

Fabric leaves this entrypoint uninvoked when Raknetify2 is absent. Providers should declare names and groups throughout initialization without relying on another mod having finished its own initialization.

Registration working

Forge and NeoForge mods, and webthew or proxy add-ons, can call PacketOrdering.register(identifier, group) throughout initialization when Raknetify2 is available. The class is com.ishland.raknetify.api.PacketOrdering. Register before accepting player links, and keep by choice integration code from loading Raknetify2 classes when the dependency is absent.

Declarations apply to new links. Current links keep the rules they received at setup. Repeating an identical declaration is allowed. Conflicting groups for the same name are turned away.

Payload names must brook a sound custom namespace. The minecraft namespace is reserved. The endpoint-wide limit is 128 declarations, including built-in rules and registrations from other mods. Names can contain up to 255 ASCII characters brooking the API's namespaced name syntax.

Newer RakNet peers exchange declarations throughout link setup. A webthew or proxy can brook a peer's declaration when it has no nearby rule for that payload. Nearby rules take precedence, and a peer's declarations remain scoped to that link.

UDP proxies

See UDP forwarding and PROXY wire rules for UDP relays and forwarded guest links.

To set up a Minecraft proxy, look under Velocity and BungeeCord.

English (US)

Clone this wiki locally