WSS:// 端口

[IamTaoChen]

在#12 (comment) 中讨论了一下关于wss端口的问题。

我还是觉得不应该支持wss://[DOMIAN]:PORT直接链接，目前配置的“多样性”造成了一些迷惑。我坚持使用~ ws/id|relay 这种方式。

针对 NAS上不能直接配置路径的问题，我觉得有以下两个解决方案:

1. 再添加一个nginx容器来进行反代，NAS的UI中配置反代到这个nginx上
2. 使用entrypoint.sh脚本，然后根据环境变量（比如RUSTDESK_WSS_MODE=1）使用sed将函数替换掉

@lejianwen @zhangbo8418 你们怎么觉得？大家也可以说说自己的想法

[zhangbo8418]

在#12 (comment) 中讨论了一下关于wss端口的问题。

我还是觉得不应该支持wss://[DOMIAN]:PORT直接链接，目前配置的“多样性”造成了一些迷惑。我坚持使用~ ws/id|relay 这种方式。

针对 NAS上不能直接配置路径的问题，我觉得有以下两个解决方案:

1. 再添加一个nginx容器来进行反代，NAS的UI中配置反代到这个nginx上
2. 使用entrypoint.sh脚本，然后根据环境变量（比如RUSTDESK_WSS_MODE=1）使用sed将函数替换掉

@lejianwen @zhangbo8418 你们怎么觉得？

咋不好理解？如果域名后面不带端口就直接就是ws/id|relay，它原版就是这样的并不支持带端口的域名，现在支持带端口的域名它就支持端口直连了，全自动的。。。

[IamTaoChen]

如果是不带端口的web完全可以看官方教程，因为没区别，但是如果你都web带端口了那wss也要带端口，既然wss带端口了为啥不直连？没必要纠结这问题

但是这样配置更复杂了，需要分情况来说明。现在隔三差五就会有人因为配置不对来提issue。中间加一层nginx反代并不会增加多少性能损耗，整体配置也会更容易也更通用一些

[zhangbo8418]

但是这样配置更复杂了，需要分情况来说明。现在隔三差五就会有人因为配置不对来提issue。中间加一层nginx反代并不会增加多少性能损耗，整体配置也会更容易也更通用一些

真不想纠结这问题，如果用VPS的一般都是有443的，如果说自己家里折腾连个wss反代都弄不明白那还搞个毛线。。。要我说还不如直接在api添加个代理功能，直接全连api服务器，api去请求hbbs和hbbr的ws端口，这样官方那一套都省了。。。

[IamTaoChen]

真不想纠结这问题，如果用VPS的一般都是有443的，如果说自己家里折腾连个wss反代都弄不明白那还搞个毛线。。。要我说还不如直接在api添加个代理功能，直接全连api服务器，api去请求hbbs和hbbr的ws端口，这样官方那一套都省了。。。

我提出这个不是要争什么优劣性，而是觉得全部使用/ws/id|relay对整个项目的维护以及配置会更容易、清楚一些。当然这也会有一个问题，当前wiki中的http模式的设置教程需要更新，需要配置反向代理

如果说自己家里折腾连个wss反代都弄不明白那还搞个毛线。。。

不管搞不搞得懂，这就会增加理解的难度->带不带端口是两套逻辑。如果为了兼容v1我理解，但是如果要放弃支持v1使用v2，我完全看不出使用直连的好处，看到的是不停的issue问配置有问题

[zhangbo8418]

不管搞不搞得懂，这就会增加理解的难度->带不带端口是两套逻辑。如果为了兼容v1我理解，但是如果要放弃支持v1使用v2，我完全看不出使用直连的好处，看到的是不停的issue问配置有问题

问题是，我看那个issue他那设置和这个有毛线关系。。。因为它是api上的端口设置错了，就算改成你说的那样，他也连不上，那也因该设置和web一样的端口。现在他那个也是这问题啊，因该和web一样不带端口。所以还是我说的，如果真的要简化配置还不如直接在api内部代理，都不用管hbbs和hbbr的端口，直接连api服务器就行。。。

[lejianwen]

这个地方的配置确实是有点混乱，全部使用/ws/id|relay确实对于理解和使用更为统一，但暂时还是使用wss://[DOMIAN]:PORT这种方式来。一是兼容性，二是能满足更多的用户使用场景。

web1基本已经弃用了。

我后面更新一下文档