[GH-ISSUE #3631] [Feature Request] Ability to configure failover

gitea-mirror commented

2026-05-05 13:52:18 -06:00

Owner

Copy link

Originally created by @vithurshanselvarajah on GitHub (Sep 25, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3631

Describe the feature request

Some of my servers have multiple uplinks so have multiple potential routes to take in the event of a failure.

Is there a way we can enable a fail over option? so config similar to below.

Node 1

[common]
server_port = 7003
token = sanitized
log_file = /root/frpc/frpc.log
log_max_days = 3
server_addr = demo.url.sanitized

[sanitized-80]
type = http
server_order = 1
local_ip = 127.0.0.1
local_port = 80
use_encryption = false
use_compression = true
custom_domains = demo.url.sanitized

[sanitized-443]
type = https
server_order = 1
local_ip = 127.0.0.1
local_port = 443
use_encryption = false
use_compression = true
custom_domains = demo.url.sanitized

Node 2

[common]
server_port = 7003
token = sanitized
log_file = /root/frpc/frpc.log
log_max_days = 3
server_addr = demo.url.sanitized

[sanitized-80]
type = http
server_order = 2
local_ip = 127.0.0.1
local_port = 80
use_encryption = false
use_compression = true
custom_domains = demo.url.sanitized

[sanitized-443]
type = https
server_order = 2
local_ip = 127.0.0.1
local_port = 443
use_encryption = false
use_compression = true
custom_domains = demo.url.sanitized

so the lower number for server_order is always used first. If a connection cannot be achieved it then fails over to the next one. This would give excellent DR capabilities to this amazing utility.

Describe alternatives you've considered

Configuring a load balancer in front of the server frp so it can decide which route to take using roundrobin algo. But this would mean setting up two independent frp environments which is a lot of work in terms of management and increases odds of failure / troubleshooting issues.

Affected area

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

Originally created by @vithurshanselvarajah on GitHub (Sep 25, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3631 ### Describe the feature request Some of my servers have multiple uplinks so have multiple potential routes to take in the event of a failure. Is there a way we can enable a fail over option? so config similar to below. Node 1 [common] server_port = 7003 token = sanitized log_file = /root/frpc/frpc.log log_max_days = 3 server_addr = demo.url.sanitized [sanitized-80] type = http server_order = 1 local_ip = 127.0.0.1 local_port = 80 use_encryption = false use_compression = true custom_domains = demo.url.sanitized [sanitized-443] type = https server_order = 1 local_ip = 127.0.0.1 local_port = 443 use_encryption = false use_compression = true custom_domains = demo.url.sanitized Node 2 [common] server_port = 7003 token = sanitized log_file = /root/frpc/frpc.log log_max_days = 3 server_addr = demo.url.sanitized [sanitized-80] type = http server_order = 2 local_ip = 127.0.0.1 local_port = 80 use_encryption = false use_compression = true custom_domains = demo.url.sanitized [sanitized-443] type = https server_order = 2 local_ip = 127.0.0.1 local_port = 443 use_encryption = false use_compression = true custom_domains = demo.url.sanitized so the lower number for server_order is always used first. If a connection cannot be achieved it then fails over to the next one. This would give excellent DR capabilities to this amazing utility. ### Describe alternatives you've considered Configuring a load balancer in front of the server frp so it can decide which route to take using roundrobin algo. But this would mean setting up two independent frp environments which is a lot of work in terms of management and increases odds of failure / troubleshooting issues. ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:52:18 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

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

Author

Owner

Copy link

@fatedier commented on GitHub (Sep 26, 2023):

https://github.com/fatedier/frp#load-balancing

Does this feature help? Combine with the health check function.

@fatedier commented on GitHub (Sep 26, 2023): https://github.com/fatedier/frp#load-balancing Does this feature help? Combine with the [health check](https://github.com/fatedier/frp#service-health-check) function.

gitea-mirror commented

2026-05-05 13:52:22 -06:00

Author

Owner

Copy link

@vithurshanselvarajah commented on GitHub (Sep 26, 2023):

@fatedier i previously saw this but was unsure if this works when there is https enabled?

@vithurshanselvarajah commented on GitHub (Sep 26, 2023): @fatedier i previously saw this but was unsure if this works when there is https enabled?

gitea-mirror commented

2026-05-05 13:52:23 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Sep 26, 2023):

Only for tcp, http, tcpmux, https is not support.

This is not within the short-term plan, but it will be considered for support later.

@fatedier commented on GitHub (Sep 26, 2023): Only for `tcp, http, tcpmux`, `https` is not support. This is not within the short-term plan, but it will be considered for support later.

gitea-mirror commented

2026-05-05 13:52:24 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Oct 27, 2023):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Oct 27, 2023): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

No Branch/Tag specified