[GH-ISSUE #1929] [FEATURE] vhost_http_port支持独立设置监听地址 #1532

Closed
opened 2026-05-05 12:58:11 -06:00 by gitea-mirror · 14 comments
Owner

Originally created by @san3Xian on GitHub (Aug 2, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/1929

You do NOT have to include this information if this is a FEATURE REQUEST

What version of frp are you using (./frpc -v or ./frps -v)?
[root@frps ]# ./frps -v
0.33.0

希望能够提供参数设置指定vhost_http_port 和 vhost_https_port 的监听地址
方便设置port为8080 和 8443 监听在127.0.0.1
然后由nginx转发流量到frps

Originally created by @san3Xian on GitHub (Aug 2, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/1929 You do NOT have to include this information if this is a FEATURE REQUEST **What version of frp are you using (./frpc -v or ./frps -v)?** [root@frps ]# ./frps -v 0.33.0 希望能够提供参数设置指定vhost_http_port 和 vhost_https_port 的监听地址 方便设置port为8080 和 8443 监听在127.0.0.1 然后由nginx转发流量到frps
Author
Owner

@san3Xian commented on GitHub (Aug 2, 2020):

#specify which address proxy will listen for, default value is same with bind_addr
#proxy_bind_addr = 127.0.0.1
proxy_bind_addr 虽然支持修改proxy的监听地址,但是会影响全部proxy

<!-- gh-comment-id:667653908 --> @san3Xian commented on GitHub (Aug 2, 2020): #specify which address proxy will listen for, default value is same with bind_addr #proxy_bind_addr = 127.0.0.1 proxy_bind_addr 虽然支持修改proxy的监听地址,但是会影响全部proxy
Author
Owner

@Becods commented on GitHub (Aug 2, 2020):

看你的描述,你的环境应该是多ip吧
开启多个frps服务,各自绑定ip即可
当然bind_port就不能相同了
Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue

<!-- gh-comment-id:667666620 --> @Becods commented on GitHub (Aug 2, 2020): 看你的描述,你的环境应该是多ip吧 开启多个frps服务,各自绑定ip即可 当然bind_port就不能相同了 Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue
Author
Owner

@san3Xian commented on GitHub (Aug 2, 2020):

看你的描述,你的环境应该是多ip吧
开启多个frps服务,各自绑定ip即可
当然bind_port就不能相同了
Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue

看你的描述,你是没理解我的意思
让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port

<!-- gh-comment-id:667672471 --> @san3Xian commented on GitHub (Aug 2, 2020): > 看你的描述,你的环境应该是多ip吧 > 开启多个frps服务,各自绑定ip即可 > 当然bind_port就不能相同了 > Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue 看你的描述,你是没理解我的意思 让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port
Author
Owner

@fatedier commented on GitHub (Aug 3, 2020):

Try proxy_bind_addr = 127.0.0.1

https://github.com/fatedier/frp/blob/master/conf/frps_full.ini#L16

<!-- gh-comment-id:667787967 --> @fatedier commented on GitHub (Aug 3, 2020): Try `proxy_bind_addr = 127.0.0.1` https://github.com/fatedier/frp/blob/master/conf/frps_full.ini#L16
Author
Owner

@Becods commented on GitHub (Aug 3, 2020):

看你的描述,你的环境应该是多ip吧
开启多个frps服务,各自绑定ip即可
当然bind_port就不能相同了
Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue

看你的描述,你是没理解我的意思
让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port

我的理解是http/https单独监听127.0.0.1
其他映射绑定其他IP
不知对否

<!-- gh-comment-id:667853635 --> @Becods commented on GitHub (Aug 3, 2020): > > 看你的描述,你的环境应该是多ip吧 > > 开启多个frps服务,各自绑定ip即可 > > 当然bind_port就不能相同了 > > Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue > > 看你的描述,你是没理解我的意思 > 让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port 我的理解是http/https单独监听127.0.0.1 其他映射绑定其他IP 不知对否
Author
Owner

@san3Xian commented on GitHub (Aug 3, 2020):

看你的描述,你的环境应该是多ip吧
开启多个frps服务,各自绑定ip即可
当然bind_port就不能相同了
Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue

看你的描述,你是没理解我的意思
让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port

我的理解是http/https单独监听127.0.0.1
其他映射绑定其他IP
不知对否

是的嘞,开多个frps就要多个frpc了

<!-- gh-comment-id:667857185 --> @san3Xian commented on GitHub (Aug 3, 2020): > > > 看你的描述,你的环境应该是多ip吧 > > > 开启多个frps服务,各自绑定ip即可 > > > 当然bind_port就不能相同了 > > > Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue > > > > > > 看你的描述,你是没理解我的意思 > > 让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port > > 我的理解是http/https单独监听127.0.0.1 > 其他映射绑定其他IP > 不知对否 是的嘞,开多个frps就要多个frpc了
Author
Owner

@Becods commented on GitHub (Aug 3, 2020):

看你的描述,你的环境应该是多ip吧
开启多个frps服务,各自绑定ip即可
当然bind_port就不能相同了
Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue

看你的描述,你是没理解我的意思
让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port

我的理解是http/https单独监听127.0.0.1
其他映射绑定其他IP
不知对否

是的嘞,开多个frps就要多个frpc了

是的
但是在FEATURE未实现/自己魔改的情况下这是最优解
或者可以再加多一层转发,将本地回环的特定端口转发至其他IP

<!-- gh-comment-id:667859246 --> @Becods commented on GitHub (Aug 3, 2020): > > > > 看你的描述,你的环境应该是多ip吧 > > > > 开启多个frps服务,各自绑定ip即可 > > > > 当然bind_port就不能相同了 > > > > Tips: 看见右上那三个点了吗,里边有Edit,可以直接编辑原issue > > > > > > > > > 看你的描述,你是没理解我的意思 > > > 让vhost_http_port 和 vhost_https_port 监听在127.0.0.1,不直接对外提供服务,由nginx对外提供服务,再由nginx将外部流量转发到vhost_http_port / vhost_https_port > > > > > > 我的理解是http/https单独监听127.0.0.1 > > 其他映射绑定其他IP > > 不知对否 > > 是的嘞,开多个frps就要多个frpc了 是的 但是在FEATURE未实现/自己魔改的情况下这是最优解 或者可以再加多一层转发,将本地回环的特定端口转发至其他IP
Author
Owner

@fatedier commented on GitHub (Aug 3, 2020):

先想一想这是不是一个伪需求,是不是真的必须要这么做才能解决问题。

<!-- gh-comment-id:667877437 --> @fatedier commented on GitHub (Aug 3, 2020): 先想一想这是不是一个伪需求,是不是真的必须要这么做才能解决问题。
Author
Owner

@septs commented on GitHub (Aug 4, 2020):

@fatedier vhost_http_port / vhost_https_port 监听 0.0.0.0 确实不合理
对于一个部署在公网的 frps,此时将完全对外暴露

第三者完全可以通过 vhost_http_port 暴露的端口直接发起攻击
绕过所有的前置认证

我认为 vhost_http_port / vhost_https_port 默认状态下应当只能监听 127.0.0.1 (IPv4 localhost) / :: (IPv6 localhost)

<!-- gh-comment-id:668335120 --> @septs commented on GitHub (Aug 4, 2020): @fatedier `vhost_http_port` / `vhost_https_port` 监听 `0.0.0.0` 确实不合理 对于一个部署在公网的 frps,此时将完全对外暴露 第三者完全可以通过 vhost_http_port 暴露的端口直接发起攻击 绕过所有的前置认证 我认为 vhost_http_port / vhost_https_port 默认状态下应当只能监听 `127.0.0.1` (IPv4 localhost) / `::` (IPv6 localhost)
Author
Owner

@fatedier commented on GitHub (Aug 4, 2020):

@septs proxy_bind_addr = 127.0.0.1

https://github.com/fatedier/frp/blob/master/conf/frps_full.ini#L16

可以使用以上配置实现你的需求。

使用 frp 的目的通常是将服务暴露在公网供其他人访问。所以默认状态不会只监听 127.0.0.1 ,这种做法有点本末倒置。通过上面的配置可以实现你的特殊需求。

<!-- gh-comment-id:668401277 --> @fatedier commented on GitHub (Aug 4, 2020): @septs `proxy_bind_addr = 127.0.0.1` https://github.com/fatedier/frp/blob/master/conf/frps_full.ini#L16 可以使用以上配置实现你的需求。 使用 frp 的目的通常是将服务暴露在公网供其他人访问。所以默认状态不会只监听 `127.0.0.1` ,这种做法有点本末倒置。通过上面的配置可以实现你的特殊需求。
Author
Owner

@septs commented on GitHub (Aug 4, 2020):

使用 frp 的目的通常是将服务暴露在公网供其他人访问。

从 by default security 原则上来说这并不合适

<!-- gh-comment-id:668410372 --> @septs commented on GitHub (Aug 4, 2020): > 使用 frp 的目的通常是将服务暴露在公网供其他人访问。 从 by default security 原则上来说这并不合适
Author
Owner

@san3Xian commented on GitHub (Aug 4, 2020):

从一些场景来说,为了安全起见,还有让nginx充当前置的缓存加速组件
所以建议能够单独设置参数让 vhost_http_port / vhost_https_port 监听在特定的地址(127.0.0.1)
当然这也是建议而已
毕竟程序不实现的话,另外配置一下firewalld就好了,没啥

而 proxy_bind_addr 参数会影响非https 或者http类型的proxy,所以不大满足这个需求

<!-- gh-comment-id:668412336 --> @san3Xian commented on GitHub (Aug 4, 2020): 从一些场景来说,为了安全起见,还有让nginx充当前置的缓存加速组件 所以建议能够单独设置参数让 vhost_http_port / vhost_https_port 监听在特定的地址(127.0.0.1) 当然这也是建议而已 毕竟程序不实现的话,另外配置一下firewalld就好了,没啥 而 proxy_bind_addr 参数会影响非https 或者http类型的proxy,所以不大满足这个需求
Author
Owner

@fatedier commented on GitHub (Aug 4, 2020):

@septs frp 不是为了满足某一个特定场景或需求的项目,在你需要绝对安全的时候目前也不建议使用内网穿透的工具,只能说尽量对有类似需求的用户提供这样的选择。如果对这方面有疑问,可以单独另外开一个 issue 描述你的问题。

还有就是,这个项目的描述 A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet,这个是最初也是最核心的能力和目标。

<!-- gh-comment-id:668412664 --> @fatedier commented on GitHub (Aug 4, 2020): @septs frp 不是为了满足某一个特定场景或需求的项目,在你需要绝对安全的时候目前也不建议使用内网穿透的工具,只能说尽量对有类似需求的用户提供这样的选择。如果对这方面有疑问,可以单独另外开一个 issue 描述你的问题。 还有就是,这个项目的描述 `A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet`,这个是最初也是最核心的能力和目标。
Author
Owner

@fatedier commented on GitHub (Aug 4, 2020):

@easyjack
从需求的角度出发,什么场景下需要严格去要求只有 HTTP/HTTPS 的服务要监听在 127.0.0.1 ,而其他的服务都可以监听在其他地址?

从做产品的角度:

  1. 这样的需求是否是通用的需求,能够解决大多数人的问题。
  2. 是否是一个不可替代的需求,不能通过其他方式来完成。
  3. 解决这个需求的成本有多大,更多的参数配置,可能潜在地提高了用户的使用成本和上手的复杂度。

从我个人的角度而言,这个阶段不太希望引入各种琐碎的 feature,很容易让项目成为一个大杂烩,既提高开发者的维护成本,也增加了用户的使用成本。最终某些功能可能只有几个人使用,甚至没有人用,但是持续的维护却需要耗费很多精力。

所以,目前可能更多的是希望做减法,专注核心能力,做一些重构。之后能通过插件的方式开放更多的扩展能力出来,可以由有需求的人来完善。

<!-- gh-comment-id:668417894 --> @fatedier commented on GitHub (Aug 4, 2020): @easyjack 从需求的角度出发,什么场景下需要严格去要求只有 HTTP/HTTPS 的服务要监听在 `127.0.0.1` ,而其他的服务都可以监听在其他地址? 从做产品的角度: 1. 这样的需求是否是通用的需求,能够解决大多数人的问题。 2. 是否是一个不可替代的需求,不能通过其他方式来完成。 3. 解决这个需求的成本有多大,更多的参数配置,可能潜在地提高了用户的使用成本和上手的复杂度。 从我个人的角度而言,这个阶段不太希望引入各种琐碎的 feature,很容易让项目成为一个大杂烩,既提高开发者的维护成本,也增加了用户的使用成本。最终某些功能可能只有几个人使用,甚至没有人用,但是持续的维护却需要耗费很多精力。 所以,目前可能更多的是希望做减法,专注核心能力,做一些重构。之后能通过插件的方式开放更多的扩展能力出来,可以由有需求的人来完善。
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#1532
No description provided.