[GH-ISSUE #2631] [Feature Request] 增加可以嵌套的用户标签识别 #2097

Closed
opened 2026-05-05 13:20:54 -06:00 by gitea-mirror · 1 comment
Owner

Originally created by @weikychen on GitHub (Oct 21, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2631

Describe the feature request

通过查阅官方文档发现[common]标签下有一个user标签可以用于区分单个内网下的同名服务
如果有几个内网比如A内网有一台RDP服务,B内网有一台SSH服务,需要访问AB内网的机器在C内网中
因为为这几个内网提供服务的公网服务器只有一台,所以当C内网的机器想要通过配置文件嵌套引用时
includes = .\frps\conf.d*.ini
在根目录的frpc.ini的[common]的字段内如果指定了user的值,则只会取第一个的结果,如果不指定,在conf.d/*.ini的各个配置文件中指定,则不再被引用。
是否可以将这个user值下放到每个服务的段内比如[secret_rdp]而不是放在[common]字段内,或[common]字段允许user字段的值成为一个白名单,然后通过每个服务下的user字段的值来确定服务名的合法性。
这样的话,如果C需要同时连接很多内网中的服务,只需要启动一个frpc客户端加载一个主配置文件就可以了,同时服务不光可以用服务名来区分还可以用区域名来区分。(比如增加一个zone字段)

Describe alternatives you've considered

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 @weikychen on GitHub (Oct 21, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2631 ### Describe the feature request 通过查阅官方文档发现[common]标签下有一个user标签可以用于区分单个内网下的同名服务 如果有几个内网比如A内网有一台RDP服务,B内网有一台SSH服务,需要访问AB内网的机器在C内网中 因为为这几个内网提供服务的公网服务器只有一台,所以当C内网的机器想要通过配置文件嵌套引用时 includes = .\frps\conf.d\*.ini 在根目录的frpc.ini的[common]的字段内如果指定了user的值,则只会取第一个的结果,如果不指定,在conf.d/*.ini的各个配置文件中指定,则不再被引用。 是否可以将这个user值下放到每个服务的段内比如[secret_rdp]而不是放在[common]字段内,或[common]字段允许user字段的值成为一个白名单,然后通过每个服务下的user字段的值来确定服务名的合法性。 这样的话,如果C需要同时连接很多内网中的服务,只需要启动一个frpc客户端加载一个主配置文件就可以了,同时服务不光可以用服务名来区分还可以用区域名来区分。(比如增加一个zone字段) ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [x] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others
gitea-mirror 2026-05-05 13:20:54 -06:00
Author
Owner

@github-actions[bot] commented on GitHub (Nov 21, 2021):

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

<!-- gh-comment-id:974732585 --> @github-actions[bot] commented on GitHub (Nov 21, 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#2097
No description provided.