[GH-ISSUE #2297] 建议支持frp客户端自定义连接多个frp服务器 #1825

Closed
opened 2026-05-05 13:10:42 -06:00 by gitea-mirror · 14 comments
Owner

Originally created by @xinjiajuan on GitHub (Mar 12, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2297

这是一个很有建设意义的想法,我遇到的问题在于一个本地服务器,但是一个服务器运行着很多个网站,但是对于不同网站需要不同的网络环境(服务器的地理位置、网络带宽、网络环境、硬件配置等),所以对于这种情况,单对单(一个公网服务器和一个客户端)的解决方案已经不能满足使用要求,在此提出支持一个客户端可以连接多个frp服务器。

详细的思考与方案:
对于ini配置文件,每一个端口穿透都使用[xxx]这种字段(我不知道叫啥,就用字段表示吧)表示,那么这种就是一个字段就是一个端口的穿透,那么可不可以在[xxx]字段中设置一个新的参数,来自定义这个端口连接的frp服务器呢?我想开发者应该可以做得到。
对于多种情况,如果不使用自定义字段的自定义frp服务器设置,那么也可以在[common]也设置一个新参数,来表示这个配置文件中整个所有的字段是否需要自定义,如果需要自定义,那么在[common]中添加有关自定义frp的参数,[common]就可以不需要填写服务器的地址相关信息,就需要每个[xxx]字段后面添加[common]中原先需要设置的服务器地址等参数。
当然也可以不需要把[common]字段的内容给全部改了,可以搞一个自定义参数给[xxx]中,那么运行时自动检查[xxx]字段中是否有自定义参数,如果有,那么使用自定义参数中的服务器配置,如果没有自定义参数,那么就默认使用[common]里给的服务器配置。

只是个人的想法,本人学识浅薄,如有得罪之处请各位大佬批评与指正,如觉得我的建议可以或者开发者愿意设计这样一个可以支持连接多个frp服务器的frp新版本,那望请采纳。

Originally created by @xinjiajuan on GitHub (Mar 12, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2297 <!-- From Chinese to English by machine translation, welcome to revise and polish. --> 这是一个很有建设意义的想法,我遇到的问题在于一个本地服务器,但是一个服务器运行着很多个网站,但是对于不同网站需要不同的网络环境(服务器的地理位置、网络带宽、网络环境、硬件配置等),所以对于这种情况,单对单(一个公网服务器和一个客户端)的解决方案已经不能满足使用要求,在此提出支持一个客户端可以连接多个frp服务器。 <!--A clear and concise description of the solution you want. --> 详细的思考与方案: **对于ini配置文件,每一个端口穿透都使用`[xxx]`这种字段(我不知道叫啥,就用字段表示吧)表示,那么这种就是一个字段就是一个端口的穿透,那么可不可以在[xxx]字段中设置一个新的参数,来自定义这个端口连接的frp服务器呢?我想开发者应该可以做得到。** 对于多种情况,如果不使用自定义字段的自定义frp服务器设置,那么也可以在[common]也设置一个新参数,来表示这个配置文件中整个所有的字段是否需要自定义,如果需要自定义,那么在[common]中添加有关自定义frp的参数,[common]就可以不需要填写服务器的地址相关信息,就需要每个[xxx]字段后面添加[common]中原先需要设置的服务器地址等参数。 当然也可以不需要把[common]字段的内容给全部改了,可以搞一个自定义参数给[xxx]中,那么运行时自动检查[xxx]字段中是否有自定义参数,如果有,那么使用自定义参数中的服务器配置,如果没有自定义参数,那么就默认使用[common]里给的服务器配置。 <!--A clear and concise description of any alternative solutions or features you have considered. --> 只是个人的想法,本人学识浅薄,如有得罪之处请各位大佬批评与指正,如觉得我的建议可以或者开发者愿意设计这样一个可以支持连接多个frp服务器的frp新版本,那望请采纳。 <!--Implementation steps for the solution you want. --> <!--Make a clear and concise description of the application scenario of the solution you want. -->
gitea-mirror 2026-05-05 13:10:42 -06:00
Author
Owner

@micoya commented on GitHub (Mar 14, 2021):

是不是多开几个客户端就可以解决了。

<!-- gh-comment-id:798851598 --> @micoya commented on GitHub (Mar 14, 2021): 是不是多开几个客户端就可以解决了。
Author
Owner

@xinjiajuan commented on GitHub (Mar 14, 2021):

是不是多开几个客户端就可以解决了。

我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化

<!-- gh-comment-id:798855813 --> @xinjiajuan commented on GitHub (Mar 14, 2021): > 是不是多开几个客户端就可以解决了。 我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化
Author
Owner

@fatedier commented on GitHub (Mar 15, 2021):

是不是多开几个客户端就可以解决了。

我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化

相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。

<!-- gh-comment-id:799072911 --> @fatedier commented on GitHub (Mar 15, 2021): > > 是不是多开几个客户端就可以解决了。 > > 我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化 相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。
Author
Owner

@xinjiajuan commented on GitHub (Mar 15, 2021):

是不是多开几个客户端就可以解决了。

我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化

相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。

所以有什么解决方案吗?对于需要连多个服务器的情况

<!-- gh-comment-id:799126022 --> @xinjiajuan commented on GitHub (Mar 15, 2021): > > > 是不是多开几个客户端就可以解决了。 > > > > > > 我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化 > > 相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。 所以有什么解决方案吗?对于需要连多个服务器的情况
Author
Owner

@kissingers commented on GitHub (Mar 16, 2021):

多开是可以的,我建2个服务器在不同地方,重要的映射,我开2个电脑,每个电脑开2个客户端做成2个服务,这样任何时候都可以保证可以连。

<!-- gh-comment-id:799967293 --> @kissingers commented on GitHub (Mar 16, 2021): 多开是可以的,我建2个服务器在不同地方,重要的映射,我开2个电脑,每个电脑开2个客户端做成2个服务,这样任何时候都可以保证可以连。
Author
Owner

@BI7PRK commented on GitHub (Mar 17, 2021):

是不是多开几个客户端就可以解决了。

我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化

相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。

考虑实现备份服务器机制吗?当主服务器尝试连接失败到指定阈值时,就连接上备份服务器。

<!-- gh-comment-id:800820111 --> @BI7PRK commented on GitHub (Mar 17, 2021): >>> 是不是多开几个客户端就可以解决了。 >> >> 我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化 > > 相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。 考虑实现备份服务器机制吗?当主服务器尝试连接失败到指定阈值时,就连接上备份服务器。
Author
Owner

@xinjiajuan commented on GitHub (Mar 17, 2021):

我开两个frpc,其中后开的那个会报错,明明名称没有重复的,但是提示已经被用过了。
[e9f1c7f250938fc9.Tunnel_8773] start error: proxy name [e9f1c7f250938fc9.Tunnel_8773] is already in use

<!-- gh-comment-id:800824421 --> @xinjiajuan commented on GitHub (Mar 17, 2021): 我开两个frpc,其中后开的那个会报错,明明名称没有重复的,但是提示已经被用过了。 [e9f1c7f250938fc9.Tunnel_8773] start error: proxy name [e9f1c7f250938fc9.Tunnel_8773] is already in use
Author
Owner

@kissingers commented on GitHub (Mar 22, 2021):

是不是多开几个客户端就可以解决了。

我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化

相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。

考虑实现备份服务器机制吗?当主服务器尝试连接失败到指定阈值时,就连接上备份服务器。

实际上是2个都连的,不过有2个服务器,重要的地方找2台服务器,一个只连A服务器,一个只连B服务器。都能实现所有功能。不过你要2个公网服务器。我一个公司的,一个自家路由器 K2P刷老毛子加动态域名实现。

<!-- gh-comment-id:803737794 --> @kissingers commented on GitHub (Mar 22, 2021): > > > > 是不是多开几个客户端就可以解决了。 > > > > > > > > > 我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化 > > > > > > 相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。 > > 考虑实现备份服务器机制吗?当主服务器尝试连接失败到指定阈值时,就连接上备份服务器。 实际上是2个都连的,不过有2个服务器,重要的地方找2台服务器,一个只连A服务器,一个只连B服务器。都能实现所有功能。不过你要2个公网服务器。我一个公司的,一个自家路由器 K2P刷老毛子加动态域名实现。
Author
Owner

@xinjiajuan commented on GitHub (Mar 22, 2021):

是不是多开几个客户端就可以解决了。

我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化

相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。

考虑实现备份服务器机制吗?当主服务器尝试连接失败到指定阈值时,就连接上备份服务器。

实际上是2个都连的,不过有2个服务器,重要的地方找2台服务器,一个只连A服务器,一个只连B服务器。都能实现所有功能。不过你要2个公网服务器。我一个公司的,一个自家路由器 K2P刷老毛子加动态域名实现。

我开两个frpc,其中后开的那个会报错,明明名称没有重复的,但是提示已经被用过了。
[e9f1c7f250938fc9.Tunnel_8773] start error: proxy name [e9f1c7f250938fc9.Tunnel_8773] is already in use

是,那现在我遇到了这个问题,是哪里错了吗,proxy name并没有使用重复的 @kissingers

<!-- gh-comment-id:803793827 --> @xinjiajuan commented on GitHub (Mar 22, 2021): > > > > > 是不是多开几个客户端就可以解决了。 > > > > > > > > > > > > 我试过,看样子不行,而且同时要管理两个frpc程序可能会把事情复杂化 > > > > > > > > > 相对于在代码中维护,在外部其实更简单一些,尽量遵循单一功能的原则,先做好自身功能的优化。 > > > > > > 考虑实现备份服务器机制吗?当主服务器尝试连接失败到指定阈值时,就连接上备份服务器。 > > 实际上是2个都连的,不过有2个服务器,重要的地方找2台服务器,一个只连A服务器,一个只连B服务器。都能实现所有功能。不过你要2个公网服务器。我一个公司的,一个自家路由器 K2P刷老毛子加动态域名实现。 > 我开两个frpc,其中后开的那个会报错,明明名称没有重复的,但是提示已经被用过了。 > [e9f1c7f250938fc9.Tunnel_8773] start error: proxy name [e9f1c7f250938fc9.Tunnel_8773] is already in use 是,那现在我遇到了这个问题,是哪里错了吗,proxy name并没有使用重复的 @kissingers
Author
Owner

@kingtu commented on GitHub (Apr 27, 2021):

期望实现这样的功能

<!-- gh-comment-id:827408979 --> @kingtu commented on GitHub (Apr 27, 2021): 期望实现这样的功能
Author
Owner

@github-actions[bot] commented on GitHub (Jun 12, 2021):

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

<!-- gh-comment-id:859969548 --> @github-actions[bot] commented on GitHub (Jun 12, 2021): Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.
Author
Owner

@xinjiajuan commented on GitHub (Jun 12, 2021):

所以这个建议是否采纳呢?

<!-- gh-comment-id:860001842 --> @xinjiajuan commented on GitHub (Jun 12, 2021): 所以这个建议是否采纳呢?
Author
Owner

@iakihsoug commented on GitHub (Jul 13, 2021):

可以使用多个frpc配置: frpc2server1.ini frpc2server2.ini
两个配置文件使用不同的 server_addr
sudo systemctl start frpc@frpc2server1
sudo systemctl start frpc@frpc2server2

<!-- gh-comment-id:878833209 --> @iakihsoug commented on GitHub (Jul 13, 2021): 可以使用多个frpc配置: `frpc2server1.ini` `frpc2server2.ini` 两个配置文件使用不同的 `server_addr` `sudo systemctl start frpc@frpc2server1` `sudo systemctl start frpc@frpc2server2`
Author
Owner

@github-actions[bot] commented on GitHub (Aug 13, 2021):

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

<!-- gh-comment-id:898063983 --> @github-actions[bot] commented on GitHub (Aug 13, 2021): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#1825
No description provided.