[GH-ISSUE #2610] [Feature Request] 服务端新增获取当前服务器可用端口的接口，或者自动分配可用端口在客户端显示

gitea-mirror commented

2026-05-05 13:20:17 -06:00

Owner

Copy link

Originally created by @mijjjj on GitHub (Oct 9, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2610

Describe the feature request

我们现在项目有一个需求就是我们的客户端环境已经有一个跟云端连接的mqtt通道，由于mqtt协议的特性，非常适合用于边缘端设备连接云端使用。但是我们这个设备又有远程管理的需求，于是我们通过mqtt发送给客户端可用服务端端口，但是会有一些问题。我们的服务端与代理服务器并不是同一台设备，无法远程检测端口的占用情况。是否能推出一个服务可以获取到未分配的端口或者说客户端能够不用指定端口就可以连接到服务器并且将连接的端口规则的打印到客户端的日志上

Describe alternatives you've considered

推出一个服务可以获取到未分配的端口或者说客户端能够不用指定端口就可以连接到服务器并且将连接的端口规则的打印到客户端的日志上

Affected area

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

Originally created by @mijjjj on GitHub (Oct 9, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2610 ### Describe the feature request 我们现在项目有一个需求就是我们的客户端环境已经有一个跟云端连接的mqtt通道，由于mqtt协议的特性，非常适合用于边缘端设备连接云端使用。但是我们这个设备又有远程管理的需求，于是我们通过mqtt发送给客户端可用服务端端口，但是会有一些问题。我们的服务端与代理服务器并不是同一台设备，无法远程检测端口的占用情况。是否能推出一个服务可以获取到未分配的端口或者说客户端能够不用指定端口就可以连接到服务器并且将连接的端口规则的打印到客户端的日志上 ### Describe alternatives you've considered 推出一个服务可以获取到未分配的端口或者说客户端能够不用指定端口就可以连接到服务器并且将连接的端口规则的打印到客户端的日志上 ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [X] Client Plugin - [X] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:20:17 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:20:20 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Oct 11, 2021):

remote_port 设置为 0

@fatedier commented on GitHub (Oct 11, 2021): remote_port 设置为 0

gitea-mirror commented

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

Author

Owner

Copy link

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

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 (Nov 11, 2021): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

No Branch/Tag specified