[GH-ISSUE #4800] [Feature Request] frps clustering

gitea-mirror commented

2026-05-05 14:25:38 -06:00

Owner

Copy link

Originally created by @adyanth on GitHub (May 20, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4800

Describe the feature request

I would like to deploy multiple frps servers at different locations, have the frpc connect to the nearest ones, but allow the users connect to connect to whichever frps is near to them but still reach the frpc.

To say differently, allow frps to talk to each other and route traffic between them to reach the client.

User -> frps A -> frps B -> frpc

This would also prevent a single point of failure by having multiple frps instances, and the clients should be able to connect to an active one in case the preferred one goes down.

Describe alternatives you've considered

I think something ad hoc might be done by running an frpc where the frps B is running in the above example, but not sure if it would work

User -> frps A -> (frpc, frpsB) -> frpc

Affected area

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

Originally created by @adyanth on GitHub (May 20, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4800 ### Describe the feature request I would like to deploy multiple `frps` servers at different locations, have the `frpc` connect to the nearest ones, but allow the users connect to connect to whichever `frps` is near to them but still reach the `frpc`. To say differently, allow `frps` to talk to each other and route traffic between them to reach the client. User -> frps A -> frps B -> frpc This would also prevent a single point of failure by having multiple frps instances, and the clients should be able to connect to an active one in case the preferred one goes down. ### Describe alternatives you've considered I think something ad hoc might be done by running an frpc where the frps B is running in the above example, but not sure if it would work User -> frps A -> (frpc, frpsB) -> frpc ### Affected area - [ ] Docs - [ ] Installation - [x] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror added the

proposal

label 2026-05-05 14:25:38 -06:00

gitea-mirror commented

2026-05-05 14:25:40 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (May 20, 2025):

This is a relatively complex feature, and there are no plans for it at the moment.
Different types of protocols and proxies may require special handling.

@fatedier commented on GitHub (May 20, 2025): This is a relatively complex feature, and there are no plans for it at the moment. Different types of protocols and proxies may require special handling.

gitea-mirror commented

2026-05-05 14:25:41 -06:00

Author

Owner

Copy link

@adyanth commented on GitHub (May 20, 2025):

I agree. Issue could be up for tracking in the future, or if you don't think it is feasible to be implemented in frp, feel free to close!

@adyanth commented on GitHub (May 20, 2025): I agree. Issue could be up for tracking in the future, or if you don't think it is feasible to be implemented in frp, feel free to close!

gitea-mirror commented

2026-05-05 14:25:42 -06:00

Author

Owner

Copy link

@jjhesk commented on GitHub (Jun 27, 2025):

up for discussion,
plan 1, this is actually a CDN that given each frps an unique IP or domain. client can actually switch between them.
plan 2, given this convention as auto reconnection mechanism, all frpcs to route from the nearby peer for stable traffic, looks like the middle layer is the actualy CDN that allow the visited frps to choose from different nodes.

@jjhesk commented on GitHub (Jun 27, 2025): up for discussion, plan 1, this is actually a CDN that given each frps an unique IP or domain. client can actually switch between them. plan 2, given this convention as auto reconnection mechanism, all frpcs to route from the nearby peer for stable traffic, looks like the middle layer is the actualy CDN that allow the visited frps to choose from different nodes.

No Branch/Tag specified