[GH-ISSUE #3909] [Feature Request] Allow multiple transports/ports on frpc (in order of preference?)

gitea-mirror commented

2026-05-05 14:00:23 -06:00

Owner

Copy link

Originally created by @gdevenyi on GitHub (Jan 3, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/3909

Describe the feature request

In frps we can specify ports for tcp, kcp and quic, however in frpc.toml we only get to specify a single transport.protocol and serverPort.

It would be nice to be able to specify a comma-separated order of preferred protocols (and corresponding serverPort), that frpc would attempt.

Justification for this is the frpc that UDP protocols may be preferred, however firewalls may not always allow UDP, so a tcp fallback configuration would be nice.

Describe alternatives you've considered

Running multiple frpc daemons with different configs.

Affected area

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

Originally created by @gdevenyi on GitHub (Jan 3, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/3909 ### Describe the feature request In `frps` we can specify ports for tcp, kcp and quic, however in `frpc.toml` we only get to specify a single `transport.protocol` and `serverPort`. It would be nice to be able to specify a comma-separated order of preferred protocols (and corresponding `serverPort`), that `frpc` would attempt. Justification for this is the `frpc` that UDP protocols may be preferred, however firewalls may not always allow UDP, so a tcp fallback configuration would be nice. ### Describe alternatives you've considered Running multiple frpc daemons with different configs. ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror added the

proposal

label 2026-05-05 14:00:23 -06:00

gitea-mirror commented

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

Author

Owner

Copy link

@fatedier commented on GitHub (Jan 4, 2024):

I did not expect a specific scenario that requires this feature.

Consider some potential issues:

Will it affect the retry interval? After the server restarts or network fluctuations, it may take longer to recover.
If we support configuring multiple server addresses in the future, combined with various retry strategies, it could become very complex.

Currently it is not very clear, more thinking is needed.

@fatedier commented on GitHub (Jan 4, 2024): I did not expect a specific scenario that requires this feature. Consider some potential issues: * Will it affect the retry interval? After the server restarts or network fluctuations, it may take longer to recover. * If we support configuring multiple server addresses in the future, combined with various retry strategies, it could become very complex. Currently it is not very clear, more thinking is needed.

gitea-mirror commented

2026-05-05 14:00:26 -06:00

Author

Owner

Copy link

@gdevenyi commented on GitHub (Jan 4, 2024):

Will it affect the retry interval? After the server restarts or network fluctuations, it may take longer to recover.

I would imagine that retry would start at the top and go through order of preference, it would use the retry interval, the user would be responsible for adjusting the interval to handle this.

If we support configuring multiple server addresses in the future, combined with various retry strategies, it could become very complex.

For me, if there were multiple server addresses, I would just consider it as nested orders of preference, first server, iterate through connection types, then second server, iterate through. As long as its explicitly documented what its going to do the config isn't too complex.

@gdevenyi commented on GitHub (Jan 4, 2024): > Will it affect the retry interval? After the server restarts or network fluctuations, it may take longer to recover. I would imagine that retry would start at the top and go through order of preference, it would use the retry interval, the user would be responsible for adjusting the interval to handle this. > If we support configuring multiple server addresses in the future, combined with various retry strategies, it could become very complex. For me, if there were multiple server addresses, I would just consider it as nested orders of preference, first server, iterate through connection types, then second server, iterate through. As long as its explicitly documented what its going to do the config isn't too complex.

gitea-mirror commented

2026-05-05 14:00:27 -06:00

Author

Owner

Copy link

@paolosezart commented on GitHub (Jan 4, 2024):

It would also be nice to be able to connect to alternative frp servers. For example, if one server goes down. All clients connect to one of the alternative FRPS.

@paolosezart commented on GitHub (Jan 4, 2024): It would also be nice to be able to connect to alternative frp servers. For example, if one server goes down. All clients connect to one of the alternative FRPS.

gitea-mirror commented

2026-05-05 14:00:28 -06:00

Author

Owner

Copy link

@gdevenyi commented on GitHub (Jan 4, 2024):

It would also be nice to be able to connect to alternative frp servers. For example, if one server goes down. All clients connect to one of the alternative FRPS.

Seems that was already planned, see https://github.com/fatedier/frp/issues/3909#issuecomment-1876252394 above

@gdevenyi commented on GitHub (Jan 4, 2024): > It would also be nice to be able to connect to alternative frp servers. For example, if one server goes down. All clients connect to one of the alternative FRPS. Seems that was already planned, see https://github.com/fatedier/frp/issues/3909#issuecomment-1876252394 above

gitea-mirror commented

2026-05-05 14:00:29 -06:00

Author

Owner

Copy link

@paolosezart commented on GitHub (Jan 4, 2024):

Seems that was already planned

Thank you very much for your quick response to requests. You are the best!

@paolosezart commented on GitHub (Jan 4, 2024): > Seems that was already planned Thank you very much for your quick response to requests. You are the best!

gitea-mirror commented

2026-05-05 14:00:30 -06:00

Author

Owner

Copy link

@paolosezart commented on GitHub (Jan 14, 2024):

I apologize for my importunity. Is it possible to implement the principle of not switching to an alternative server, but a permanent connection to all available servers? In this case, there is no need to think about priorities. Each client, when connected and during operation, will poll all available servers and receive information about available ports.

@paolosezart commented on GitHub (Jan 14, 2024): I apologize for my importunity. Is it possible to implement the principle of not switching to an alternative server, but a permanent connection to all available servers? In this case, there is no need to think about priorities. Each client, when connected and during operation, will poll all available servers and receive information about available ports.

No Branch/Tag specified