[GH-ISSUE #3227] Can't load balance to frpc instances on the same machine over https

gitea-mirror commented

2026-05-05 13:40:01 -06:00

Owner

Copy link

Originally created by @yasmoradi on GitHub (Dec 24, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3227

Bug Description

I've one laptop that is connected to 2 wifi networks at the same time thanks to an additional wifi dongle
I'm running 2 instances of frpc in which the first one uses the first network and 2nd one uses 2nd network
Using this approach I can accelerate transfer speed between frps which is hosted on public VPS and my locally hosted HTTP service on my laptop
I was able to achieve this using TCP, but after switching to HTTPS, the first instance successfully starts but the 2nd one gets the following error:

start error: router config conflict

If I run frpc clients in reverse order, I'll get the same error from the 2nd frpc instance no matter which one is the last instance.

frpc Version

0.46.0

frps Version

0.46.0

System Architecture

windows/amd64 for client and linux/amd64 for the server

Configurations

frps.ini

[common]
bind_addr = 0.0.0.0
subdomain_host = some-domain.com
bind_port = 443
vhost_https_port = 443
dashboard_port = 7070
dashboard_user = admin
dashboard_pwd = ?!?!
dashboard_tls_mode = true
dashboard_tls_cert_file = /etc/letsencrypt/live/some-domain.com/cert.pem
dashboard_tls_key_file = /etc/letsencrypt/live/some-domain.com/privkey.pem
authentication_method = token
token = ?!?!

frpc.ini

[common]
server_addr = some-domain.com
server_port = 443
authentication_method = token
token = ?!?!

[st]
type = https
local_ip = localhost
local_port = 5001
subdomain = st
group = bridge
group_key = ?!?!

Logs

No response

Steps to reproduce

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 @yasmoradi on GitHub (Dec 24, 2022). Original GitHub issue: https://github.com/fatedier/frp/issues/3227 ### Bug Description I've one laptop that is connected to 2 wifi networks at the same time thanks to an additional wifi dongle I'm running 2 instances of `frpc` in which the first one uses the first network and 2nd one uses 2nd network Using this approach I can accelerate transfer speed between `frps` which is hosted on public VPS and my locally hosted HTTP service on my laptop I was able to achieve this using TCP, but after switching to HTTPS, the first instance successfully starts but the 2nd one gets the following error: `start error: router config conflict` If I run `frpc` clients in reverse order, I'll get the same error from the 2nd `frpc` instance no matter which one is the last instance. ### frpc Version 0.46.0 ### frps Version 0.46.0 ### System Architecture windows/amd64 for client and linux/amd64 for the server ### Configurations `frps.ini` [common] bind_addr = 0.0.0.0 subdomain_host = some-domain.com bind_port = 443 vhost_https_port = 443 dashboard_port = 7070 dashboard_user = admin dashboard_pwd = ?!?! dashboard_tls_mode = true dashboard_tls_cert_file = /etc/letsencrypt/live/some-domain.com/cert.pem dashboard_tls_key_file = /etc/letsencrypt/live/some-domain.com/privkey.pem authentication_method = token token = ?!?! `frpc.ini` [common] server_addr = some-domain.com server_port = 443 authentication_method = token token = ?!?! [st] type = https local_ip = localhost local_port = 5001 subdomain = st group = bridge group_key = ?!?! ### Logs _No response_ ### Steps to reproduce _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:40:01 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:40:05 -06:00

Author

Owner

Copy link

@Becods commented on GitHub (Dec 25, 2022):

https://github.com/fatedier/frp/issues/1328 https://github.com/fatedier/frp/issues/2736

Routing conflicts, custom_domains cannot be repeated.

@Becods commented on GitHub (Dec 25, 2022): https://github.com/fatedier/frp/issues/1328 https://github.com/fatedier/frp/issues/2736 Routing conflicts, `custom_domains` cannot be repeated.

gitea-mirror commented

2026-05-05 13:40:06 -06:00

Author

Owner

Copy link

@yasmoradi commented on GitHub (Dec 25, 2022):

Thanks for the reply
I'm doing my best to understand as best as possible
I'm not using such a thing as custom_domains
How can I achieve the goal I've?
Do I have to use 2 different domains?
)":

@yasmoradi commented on GitHub (Dec 25, 2022): Thanks for the reply I'm doing my best to understand as best as possible I'm not using such a thing as `custom_domains` How can I achieve the goal I've? Do I have to use 2 different domains? )":

gitea-mirror commented

2026-05-05 13:40:07 -06:00

Author

Owner

Copy link

@Becods commented on GitHub (Dec 25, 2022):

Thanks for the reply
I'm doing my best to understand as best as possible
I'm not using such a thing as custom_domains
How can I achieve the goal I've?
Do I have to use 2 different domains?
)":

Yes, using two different domains.

@Becods commented on GitHub (Dec 25, 2022): > Thanks for the reply I'm doing my best to understand as best as possible I'm not using such a thing as `custom_domains` How can I achieve the goal I've? Do I have to use 2 different domains? )": Yes, using two different domains.

gitea-mirror commented

2026-05-05 13:40:08 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Dec 27, 2022):

@ysmoradi From here

Load balancing is supported by group.
This feature is only available for types tcp, http, tcpmux now.

Load balancer isn't supported for https now.

@fatedier commented on GitHub (Dec 27, 2022): @ysmoradi From [here](https://github.com/fatedier/frp#load-balancing) > Load balancing is supported by group. This feature is only available for types tcp, http, tcpmux now. Load balancer isn't supported for https now.

gitea-mirror commented

2026-05-05 13:40:09 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Jan 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 (Jan 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