[GH-ISSUE #4664] [Feature Request] TCP Port Multiplexer for Minecraft Java

gitea-mirror commented

2026-05-05 14:21:48 -06:00

Owner

Copy link

Originally created by @hlvs-apps on GitHub (Feb 9, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4664

Describe the feature request

I have implemented a new TCP port multiplexer for Minecraft Java servers and would like to propose adding it to frp. Before submitting a PR, I want to confirm whether this feature aligns with the project's goals.

Background & Motivation

Currently, frp supports only one TCP port multiplexer: HTTP CONNECT. However, Minecraft Java’s protocol is handshake-based and similar to the PROXY protocol, allowing frp to inspect initial packets and determine how to route connections.

This implementation is inspired by itzg/mc-router and enables routing multiple Minecraft Java servers over a single TCP port. This would be useful for users who want to host multiple servers without requiring separate exposed ports.

Implementation Details

Inspects the initial Minecraft handshake packet.
Extracts the requested server address and port from the packet.
Routes the connection to the appropriate backend based on predefined mappings.
Falls back to default routing if no match is found.

Use Case

A user wants to expose multiple Minecraft Java servers through a single tcp port on different subdomains and route players based on the handshake data.

Next Steps

Would this feature be suitable for inclusion in frp? Let me know if you have any feedback or concerns!

Describe alternatives you've considered

No response

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @hlvs-apps on GitHub (Feb 9, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4664 ### Describe the feature request I have implemented a new TCP port multiplexer for Minecraft Java servers and would like to propose adding it to frp. Before submitting a PR, I want to confirm whether this feature aligns with the project's goals. ## Background & Motivation Currently, frp supports only one TCP port multiplexer: HTTP CONNECT. However, Minecraft Java’s protocol is handshake-based and similar to the PROXY protocol, allowing frp to inspect initial packets and determine how to route connections. This implementation is inspired by [itzg/mc-router](https://github.com/itzg/mc-router) and enables routing multiple Minecraft Java servers over a single TCP port. This would be useful for users who want to host multiple servers without requiring separate exposed ports. ## Implementation Details - Inspects the initial Minecraft handshake packet. - Extracts the requested server address and port from the packet. - Routes the connection to the appropriate backend based on predefined mappings. - Falls back to default routing if no match is found. ## Use Case - A user wants to expose multiple Minecraft Java servers through a single tcp port on different subdomains and route players based on the handshake data. ## Next Steps Would this feature be suitable for inclusion in frp? Let me know if you have any feedback or concerns! ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [x] Others

gitea-mirror closed this issue

2026-05-05 14:21:50 -06:00

gitea-mirror commented

2026-05-05 14:21:51 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 10, 2025):

Thanks for the detailed feature request. While the idea is interesting, I'm concerned about adding application-specific (Minecraft) logic to frp.

I'd prefer a more generalized approach that could potentially benefit other applications. Unless we can find a way to implement this in a generic manner, or identify common patterns of protocols, I'm hesitant to include it. I'm open to further discussion, mainly focusing on the generalized solution.

@fatedier commented on GitHub (Feb 10, 2025): Thanks for the detailed feature request. While the idea is interesting, I'm concerned about adding application-specific (Minecraft) logic to frp. I'd prefer a more generalized approach that could potentially benefit other applications. Unless we can find a way to implement this in a generic manner, or identify common patterns of protocols, I'm hesitant to include it. I'm open to further discussion, mainly focusing on the generalized solution.

gitea-mirror commented

2026-05-05 14:21:52 -06:00

Author

Owner

Copy link

@hlvs-apps commented on GitHub (Feb 10, 2025):

Thank you for the feedback! I understand the hesitation in adding application-specific logic to frp. At this point, I'm not planning to explore a more generalized solution myself. However, if the plugin system evolves further—potentially with something like hashicorp/go-plugin—it might provide a way to implement this in a more modular fashion.

I'll go ahead and close this issue as "Not Planned." Appreciate the discussion!

@hlvs-apps commented on GitHub (Feb 10, 2025): Thank you for the feedback! I understand the hesitation in adding application-specific logic to frp. At this point, I'm not planning to explore a more generalized solution myself. However, if the plugin system evolves further—potentially with something like [hashicorp/go-plugin](https://github.com/hashicorp/go-plugin)—it might provide a way to implement this in a more modular fashion. I'll go ahead and close this issue as "Not Planned." Appreciate the discussion!

gitea-mirror commented

2026-05-05 14:21:53 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 10, 2025):

However, if the plugin system evolves further—potentially with something like hashicorp/go-plugin—it might provide a way to implement this in a more modular fashion.

Planned, but it's a long-term feature.

@fatedier commented on GitHub (Feb 10, 2025): > However, if the plugin system evolves further—potentially with something like [hashicorp/go-plugin](https://github.com/hashicorp/go-plugin)—it might provide a way to implement this in a more modular fashion. Planned, but it's a long-term feature.

No Branch/Tag specified