[GH-ISSUE #2042] 希望server端增加一个本地http反代功能 #1624

New issue

Closed

opened 2026-05-05 13:02:20 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

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

Owner

Originally created by @raisin8010 on GitHub (Oct 30, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/2042

例如
bind_port=7000
vhost_https_port=443

但是我这个server自己也有一个nginx的服务在443

目前我是通过nginx->frp c->frp s的方法实现
但是经过这么多层转发性能可能会下降，而且需要本地额外启动一个frp c。

能否在frp s上直接集成一个反代功能？根据域名分流到本地nginx的流量。

Originally created by @raisin8010 on GitHub (Oct 30, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/2042 例如 bind_port=7000 vhost_https_port=443 但是我这个server自己也有一个nginx的服务在443 目前我是通过nginx->frp c->frp s的方法实现但是经过这么多层转发性能可能会下降，而且需要本地额外启动一个frp c。能否在frp s上直接集成一个反代功能？根据域名分流到本地nginx的流量。

gitea-mirror

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

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:02:23 -06:00

Author

Owner

@Becods commented on GitHub (Oct 30, 2020):

建议直接使用nginx代理frps的https流量
有合适的替代方法可能会导致该issue被列为低优先级甚至被驳回

frp 自身的核心代码不会再引入过多的这一类的能力，而是更多的以框架的形式来提供基础能力，通过插件来完善整体生态和满足部分用户的定制化需求

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

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

@Becods commented on GitHub (Oct 30, 2020): 建议直接使用nginx代理frps的https流量有合适的替代方法可能会导致该issue被列为低优先级甚至被驳回 >frp 自身的核心代码不会再引入过多的这一类的能力，而是更多的以框架的形式来提供基础能力，通过插件来完善整体生态和满足部分用户的定制化需求 >从我个人的角度而言，这个阶段不太希望引入各种琐碎的 feature，很容易让项目成为一个大杂烩，既提高开发者的维护成本，也增加了用户的使用成本。最终某些功能可能只有几个人使用，甚至没有人用，但是持续的维护却需要耗费很多精力。 >所以，目前可能更多的是希望做减法，专注核心能力，做一些重构。之后能通过插件的方式开放更多的扩展能力出来，可以由有需求的人来完善。

gitea-mirror commented

2026-05-05 13:02:23 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 30, 2020):

你说的不就是 haproxy/nginx 的功能吗？

@fatedier commented on GitHub (Oct 30, 2020): 你说的不就是 haproxy/nginx 的功能吗？

gitea-mirror commented

2026-05-05 13:02:24 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 15, 2020):

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

@github-actions[bot] commented on GitHub (Dec 15, 2020): Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.