github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 16:15:49 -06:00

[GH-ISSUE #1376] [建议]使用类似 tcp&udp 的协议名来代替分别写同一端口的 tcp 和 udp 协议的配置文件 #1090

New issue

Closed

opened 2026-05-05 12:42:06 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 12:42:06 -06:00

Owner

Originally created by @deadlineOvO on GitHub (Aug 12, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1376

这个建议主要是在有公网地址的网关配置端口转发时，可以同时指定 tcp 和 udp 端口的方法
如果可以的话，stcp 与未来可能会出现的 sudp 之类的是否也可以一个单元指定同一个端口？

简单的例子：
[myport]
type=tcp&udp
local_ip=127.0.0.1
local_port=19132
remote_port=5649

然后这个条目的 tcp 与 udp 端口都对应同一个端口而不用写两个单元

Originally created by @deadlineOvO on GitHub (Aug 12, 2019). Original GitHub issue: https://github.com/fatedier/frp/issues/1376 这个建议主要是在有公网地址的网关配置端口转发时，可以同时指定 tcp 和 udp 端口的方法如果可以的话，stcp 与未来可能会出现的 sudp 之类的是否也可以一个单元指定同一个端口？简单的例子： [myport] type=tcp&udp local_ip=127.0.0.1 local_port=19132 remote_port=5649 然后这个条目的 tcp 与 udp 端口都对应同一个端口而不用写两个单元

gitea-mirror closed this issue

2026-05-05 12:42:07 -06:00

gitea-mirror commented

2026-05-05 12:42:09 -06:00

Author

Owner

@fatedier commented on GitHub (Aug 12, 2019):

不打算在程序里做这方面的简化，还是会引入复杂性。proxy 的名字是不能重复的，所以需要按照一定的规则生成名称。且在解析上不能保证不会出现问题，tcp 和 udp 的参数以后未必会是完全一致。

@fatedier commented on GitHub (Aug 12, 2019): 不打算在程序里做这方面的简化，还是会引入复杂性。proxy 的名字是不能重复的，所以需要按照一定的规则生成名称。且在解析上不能保证不会出现问题，tcp 和 udp 的参数以后未必会是完全一致。

gitea-mirror commented

2026-05-05 12:42:10 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Aug 12, 2019):

不打算在程序里做这方面的简化，还是会引入复杂性。proxy 的名字是不能重复的，所以需要按照一定的规则生成名称。且在解析上不能保证不会出现问题，tcp 和 udp 的参数以后未必会是完全一致。

未来会有相应的这两个协议独立的参数？

@deadlineOvO commented on GitHub (Aug 12, 2019): > 不打算在程序里做这方面的简化，还是会引入复杂性。proxy 的名字是不能重复的，所以需要按照一定的规则生成名称。且在解析上不能保证不会出现问题，tcp 和 udp 的参数以后未必会是完全一致。未来会有相应的这两个协议独立的参数？

gitea-mirror commented

2026-05-05 12:42:11 -06:00

Author

Owner

@fatedier commented on GitHub (Aug 12, 2019):

@funnypro 在设计时这就是两种不同的类型，对应不同的配置。只是目前所拥有的配置字段是一致的。

这个简化的意义不大，你的期望应该是配置的简化。更可能的也许是通过一份含有语法糖的配置生成另一份配置。这个目前还没有看到非常明确的应用场景。如果只是示例中的配置，我觉得 copy 一下并没有太多问题。

@fatedier commented on GitHub (Aug 12, 2019): @funnypro 在设计时这就是两种不同的类型，对应不同的配置。只是目前所拥有的配置字段是一致的。这个简化的意义不大，你的期望应该是配置的简化。更可能的也许是通过一份含有语法糖的配置生成另一份配置。这个目前还没有看到非常明确的应用场景。如果只是示例中的配置，我觉得 copy 一下并没有太多问题。

gitea-mirror commented

2026-05-05 12:42:12 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Aug 12, 2019):

@funnypro 在设计时这就是两种不同的类型，对应不同的配置。只是目前所拥有的配置字段是一致的。

这个简化的意义不大，你的期望应该是配置的简化。更可能的也许是通过一份含有语法糖的配置生成另一份配置。这个目前还没有看到非常明确的应用场景。如果只是示例中的配置，我觉得 copy 一下并没有太多问题。

我的想法是这样的，大概是类似那种开放指定端口段那样的？

@deadlineOvO commented on GitHub (Aug 12, 2019): > @funnypro 在设计时这就是两种不同的类型，对应不同的配置。只是目前所拥有的配置字段是一致的。 > > 这个简化的意义不大，你的期望应该是配置的简化。更可能的也许是通过一份含有语法糖的配置生成另一份配置。这个目前还没有看到非常明确的应用场景。如果只是示例中的配置，我觉得 copy 一下并没有太多问题。我的想法是这样的，大概是类似那种开放指定端口段那样的？

gitea-mirror commented

2026-05-05 12:42:12 -06:00

Author

Owner

@fatedier commented on GitHub (Aug 12, 2019):

倒是可以考虑一下这个事情，比如提供一些辅助生成配置的语法，然后通过指定命令来渲染出实际的配置文件。

我觉得可以好好思考一下，目前有哪些场景是有这样的需求的，然后提炼出来，再看怎么解决。不能为了某一个不是很重要的点去增加代码的复杂度，就有点得不偿失了。

@fatedier commented on GitHub (Aug 12, 2019): 倒是可以考虑一下这个事情，比如提供一些辅助生成配置的语法，然后通过指定命令来渲染出实际的配置文件。我觉得可以好好思考一下，目前有哪些场景是有这样的需求的，然后提炼出来，再看怎么解决。不能为了某一个不是很重要的点去增加代码的复杂度，就有点得不偿失了。

gitea-mirror commented

2026-05-05 12:42:13 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Aug 12, 2019):

倒是可以考虑一下这个事情，比如提供一些辅助生成配置的语法，然后通过指定命令来渲染出实际的配置文件。

我觉得可以好好思考一下，目前有哪些场景是有这样的需求的，然后提炼出来，再看怎么解决。不能为了某一个不是很重要的点去增加代码的复杂度，就有点得不偿失了。

可能像是 [multi:test_port] 这种
不过说到同端口使用两种协议的应用的话，目前是没有看到实际场景，虽然是有类似 tcp&udp 的防火墙规则

@deadlineOvO commented on GitHub (Aug 12, 2019): > 倒是可以考虑一下这个事情，比如提供一些辅助生成配置的语法，然后通过指定命令来渲染出实际的配置文件。 > > 我觉得可以好好思考一下，目前有哪些场景是有这样的需求的，然后提炼出来，再看怎么解决。不能为了某一个不是很重要的点去增加代码的复杂度，就有点得不偿失了。可能像是 [multi:test_port] 这种不过说到同端口使用两种协议的应用的话，目前是没有看到实际场景，虽然是有类似 tcp&udp 的防火墙规则

gitea-mirror commented

2026-05-05 12:42:14 -06:00

Author

Owner

@wwqgtxx commented on GitHub (Aug 19, 2019):

倒是可以考虑一下这个事情，比如提供一些辅助生成配置的语法，然后通过指定命令来渲染出实际的配置文件。
我觉得可以好好思考一下，目前有哪些场景是有这样的需求的，然后提炼出来，再看怎么解决。不能为了某一个不是很重要的点去增加代码的复杂度，就有点得不偿失了。

可能像是 [multi:test_port] 这种
不过说到同端口使用两种协议的应用的话，目前是没有看到实际场景，虽然是有类似 tcp&udp 的防火墙规则

同端口使用两种协议的应用最常见的应该就是Rdp了吧

@wwqgtxx commented on GitHub (Aug 19, 2019): > > 倒是可以考虑一下这个事情，比如提供一些辅助生成配置的语法，然后通过指定命令来渲染出实际的配置文件。 > > 我觉得可以好好思考一下，目前有哪些场景是有这样的需求的，然后提炼出来，再看怎么解决。不能为了某一个不是很重要的点去增加代码的复杂度，就有点得不偿失了。 > > 可能像是 [multi:test_port] 这种 > 不过说到同端口使用两种协议的应用的话，目前是没有看到实际场景，虽然是有类似 tcp&udp 的防火墙规则同端口使用两种协议的应用最常见的应该就是Rdp了吧