[GH-ISSUE #3142] [Feature Request] STCP模式能否支持2个不同user名的客户端之间连接 #2518

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

Originally created by @zhufeng on GitHub (Oct 22, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3142

Describe the feature request

通过翻之前的issue,发现作者有提到,

stcp client and visitor should be the same user.

假定有1个frps和2个frpc(frpc1和frpc2)且各自有跑服务,在2个frpc中分别定义了user名为frpc1和frpc2,如果需要在frpc2上作为visitor访问frpc1的stcp服务,此时无论如何都无法访问,因为frp2作为visitor访问frpc1.stcp时会变成frpc2.frpc1.stcp,这样会直接报错导致无法访问:

start new visitor connection error: custom listener for [frpc2.frpc1.stcp] doesn't exist

#927

Describe alternatives you've considered

是否可以考虑在role=visitor时直接忽略user的配置,因为在visitor模式下可以直接指定server_name = frpc1.stcp,而不会受frpc1是否配置了user的影响。

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
Originally created by @zhufeng on GitHub (Oct 22, 2022). Original GitHub issue: https://github.com/fatedier/frp/issues/3142 ### Describe the feature request 通过翻之前的issue,发现作者有提到, > stcp client and visitor should be the same user. 假定有1个frps和2个frpc(frpc1和frpc2)且各自有跑服务,在2个frpc中分别定义了user名为frpc1和frpc2,如果需要在frpc2上作为visitor访问frpc1的stcp服务,此时无论如何都无法访问,因为frp2作为visitor访问frpc1.stcp时会变成frpc2.frpc1.stcp,这样会直接报错导致无法访问: > start new visitor connection error: custom listener for [frpc2.frpc1.stcp] doesn't exist #927 ### Describe alternatives you've considered 是否可以考虑在role=visitor时直接忽略user的配置,因为在visitor模式下可以直接指定server_name = frpc1.stcp,而不会受frpc1是否配置了user的影响。 ### 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:37:27 -06:00
Author
Owner

@github-actions[bot] commented on GitHub (Nov 22, 2022):

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

<!-- gh-comment-id:1322840887 --> @github-actions[bot] commented on GitHub (Nov 22, 2022): 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#2518
No description provided.