[GH-ISSUE #585] 是否考虑由服务端来控制反弹的端口 #455

New issue

Closed

opened 2026-05-05 12:17:35 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 12:17:35 -06:00

Owner

Originally created by @abxuz on GitHub (Jan 2, 2018).
Original GitHub issue: https://github.com/fatedier/frp/issues/585

我们有一些物联网设备分散在许多没有公网地址的场所需要进行远程管理维护，随着设备的增加场所的变多，由客户端侧来配置反弹的端口会出现端口管理以及名称管理上的麻烦，也有只要拿到配置文件就可以随意在其他设备上反弹我服务器上的端口问题。所以我想作者会不会考虑加一种模式在S端配置好各种能反弹的端口和名称信息，客户端来连接的时候如果是允许的端口和名称就允许反弹，否则就拒绝，这样服务器的管理与安全都比较合适一点。

Originally created by @abxuz on GitHub (Jan 2, 2018). Original GitHub issue: https://github.com/fatedier/frp/issues/585 我们有一些物联网设备分散在许多没有公网地址的场所需要进行远程管理维护，随着设备的增加场所的变多，由客户端侧来配置反弹的端口会出现端口管理以及名称管理上的麻烦，也有只要拿到配置文件就可以随意在其他设备上反弹我服务器上的端口问题。所以我想作者会不会考虑加一种模式在S端配置好各种能反弹的端口和名称信息，客户端来连接的时候如果是允许的端口和名称就允许反弹，否则就拒绝，这样服务器的管理与安全都比较合适一点。

gitea-mirror closed this issue

2026-05-05 12:17:36 -06:00

gitea-mirror commented

2026-05-05 12:17:41 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 17, 2018):

以前的 issue 里有提到过，主要是安全性方面的考虑，增加这样的功能，相当于本地所有端口都有可能被暴露在公网上。
作为一个开源项目，有各种层次的使用者，懂技术的，不懂技术的，不是所有人都能自己维护这样的功能的安全性，且我也不能确保这个程序没有漏洞会被其他人利用。如果一旦有问题，可能造成的后果也是比较严重的。

@fatedier commented on GitHub (Jan 17, 2018): 以前的 issue 里有提到过，主要是安全性方面的考虑，增加这样的功能，相当于本地所有端口都有可能被暴露在公网上。作为一个开源项目，有各种层次的使用者，懂技术的，不懂技术的，不是所有人都能自己维护这样的功能的安全性，且我也不能确保这个程序没有漏洞会被其他人利用。如果一旦有问题，可能造成的后果也是比较严重的。

gitea-mirror referenced this issue

2026-05-05 14:37:34 -06:00

[PR #455] [CLOSED] frpc: support --vhost-http-port,--vhost-https-port,--privilege-token … #4199