Can we add support for bedrock clients when using mc-router?

[Knufle]

I've been using the solutions you provide for some time now, both docker-minecraft-server and https://github.com/itzg/mc-router, I'm opening this here because I don't see discussions enabled for mc-router.

I'm running a local vanilla server with paper and just geyser installed because I wanted to have a server where both bedrock and java clients can join, but mc-router is in front of all my servers and I'm not sure it can handle the scenario where you have clients connecting via the same DNS but over different ports, is it possible to do? If it's not implemented I wanted to check with you if I could have a go at implementing it.

Thanks in advance.

[itzg]

I'd have to search around but it's been discussed several times.

Bedrock uses an entirely different protocol and it's not even on TCP like Java edition.

https://wiki.bedrock.dev/servers/raknet

It's certainly implement-able, but would be a major effort.

[itzg]

itzg/mc-router#15

itzg/mc-router#14

itzg/mc-router#189

[Knufle]

Thanks for referencing all of that, honestly I didn't know it was this complicated, I did fix my use case in a simple way though, I have my vanilla server running with mc-router in front of it, they're both in the same internal network so mc-router is able to forward the specific DNS connections to it just fine, and I have the vanilla geyser container exposing 19132 UDP to the internet by attaching it to the bridge network as well, so it is part of two networks which makes it so I can easily join from bedrock clients, with no multiplexing functionality of course, but this is more than enough for my use case. For future reference and for anyone interested, I've read all the issues and wiki links @itzg provided, and I also cloned the mc-router repo and geyser repo locally to use AI to ask some questions. After some back and forth, this was the last reply from the AI I was using with planning mode enabled. Which I ended up thinking would not be a worthwhile implementation, hence why I did what I previously mentioned here.

Yes, that idea is solid, and it is the best near-term option.

Short version:
1. Yes, it would work.
2. Yes, you can identify Bedrock by UDP in this scenario.
3. This is much more realistic than full Bedrock virtual-host multiplexing.

Why it works:
1. Java clients connect over TCP.
2. Bedrock clients connect over UDP (RakNet).
3. So protocol detection can be done at the socket layer:
4. TCP listener handles Java as today.
5. UDP listener forwards Bedrock to one configured backend.

That means no need to parse Bedrock deeply just to decide Java vs Bedrock.

What this feature should be:
1. Add optional Bedrock UDP listen port (default 19132 if enabled).
2. Add one Bedrock target backend setting, for example a Geyser-enabled backend endpoint.
3. Keep existing Java hostname routing unchanged.
4. Document clearly that Bedrock side is single-target only.

What this does not solve:
1. It will not route Bedrock by hostname.
2. It will not select among multiple Bedrock backends.
3. It is protocol split, not Bedrock virtual hosting.

Best practical architecture:
1. One mc-router instance exposing TCP 25565 for Java multiplexing.
2. Same deployment exposes UDP 19132 for Bedrock passthrough.
3. UDP path forwards to one Bedrock-capable backend (often a server with Geyser or a dedicated Bedrock endpoint).
4. Java path keeps all current mapping logic.

Better ideas than this:
1. This is the best low-risk MVP.
2. Second-best is an external dedicated Bedrock router/proxy in front, while mc-router stays Java-focused.
3. Full Bedrock virtual-host multiplexing should be deferred until there is a proven vanilla-compatible early routing signal.

Important operational caveats:
1. UDP is connectionless, so implementation still needs lightweight session tracking for return traffic mapping.
2. Rate limiting and metrics should be added separately for UDP path.
3. Some existing Java-only features (login parsing, per-host webhook details) may not have direct UDP equivalents in MVP.

Recommendation:
1. Proceed with this Bedrock default-backend feature as phase 1.
2. Position it as mixed Java plus Bedrock support, not Bedrock multiplexing.
3. Keep Bedrock multiplexing as a future research track.

If you want, I can now produce a concrete implementation plan for this MVP (config fields, listener lifecycle, session map behavior, tests, and rollout docs) so you can open a high-quality issue or PR plan immediately.

[itzg]

Agreed. What it suggested is not worth implementing. In fact, that suggestion was already discussed. I'm guessing the AI steals existing issue discussion and recycles it as its own "original thought". (I'm not a big fan of AI ...especially after my company just laid off 300 people around me)