xray方式应该被探测到，已测试

[xiagw]

1. 服务器nginx挂了一个网站，是正儿八经的网站 xxx.com 从国内可以正常访问
2. 装了xray，使用的配置文件是 Xray-examples/VLESS-TCP-TLS-WS (recommended)/config_server.json 和 Xray-examples/VLESS-TCP-TLS-WS (recommended)/config_client_tcp_tls.json
3. 用了两三天后被qiang，
4. 现在 xxx.com 可以打开，但是代理已经彻底失效。

[BI7PRK]

哇~ 好神奇 ^_*

[cross-hello]

Why don't you use VLESS+TCP?
Isn't it more quick? 🤣

[chika0801]

使用Vision并看使用提醒，你的协议组合方式从去年10月开始大规模被检测。

[o0HalfLife0o]

xray的核心是XTLS以及1.8.0即将更新的REALITY
VLESS-TCP-TLS-WS (recommended)的推荐只是对于需要通过cdn来改善线路质量不佳的而已，但实际上也已经不再经得起GFW的考验

[RPRX]

现在 xxx.com 可以打开，但是代理已经彻底失效。

不稀罕，你不说我差点忘了，去年我有个套 CF 的 WSS 遇到了不断升级的“智能墙”：

• 最初，WSS 被精准阻断（网站能上），研究发现用 Browser Dialer 就能解决，所以是 Golang WSS 指纹被针对了。
• 不久后，又被精准阻断，研究发现若一段时间内用浏览器打开过网页，WSS 才能用，加个自动请求解决了。
• 最后，众所周知，TLS in TLS 检测被部署了，CF 节点倒没被直接封端口，但即时丢包干扰更恶心，相信不少人都深有体会。

[chika0801]

loc从这月初开始，又有很多内容为 xxx ws tls（印象中xxx ws也有）被封端口的帖子，现在也是每天基本上有。

从这论坛帖子反映出是3月开会提高了强度。去年10月的强度持续到今年1月好久减弱了。（主观从观察hostloc每日发帖内容积累印象）

去年以来在hostloc的帖子，我就看到过有 类似 nginx前置 xxx ws tls 伪装网站能访问，梯子不通了的帖子，出现频率也不低。楼主只是来这报告了。。。

[cross-hello]

(So only someone with good luckiness could unrecognize blocking all the time 0 ︶ 0 )

[RPRX]

顺便，我说一下 WSS 代理为什么能被精准识别：

• 指纹：即使开了伪装，它发的 ALPN 始终为 http/1.1，一眼 WSS，实际上无法做到我们想要的“藏木于林”，只会裸送人头。
• 握手：WSS 内层的 WS 要多握手一次，时序特征非常独特。其实开 early data 可以缓解，若不得不用 WSS，建议 ?ed=2048
• TLS in TLS：这是 TLS 代理普遍存在的特征，需要针对性处理。多路复用可以缓解内层 TLS 握手特征，但却加重了“加密套娃”的特征，参考 XTLS Vision, fixes TLS in TLS, to the star and beyond #1295 第二大段，所以目前 XTLS Vision 是较优解法。

所以我现在的建议是：不要用 WSS，并且它应当被列为 deprecated。套 CDN 有 gRPC，直连有 N 种姿势，已无任何必要用 WSS。

[RPRX]

loc从这月初开始，又有很多内容为 xxx ws tls（印象中xxx ws也有）被封端口的帖子，现在也是每天基本上有。

从这论坛帖子反映出是3月开会提高了强度。去年10月的强度持续到今年1月好久减弱了。（主观从观察hostloc每日发帖内容积累印象）

去年以来在hostloc的帖子，我就看到过有 类似 nginx前置 xxx ws tls 伪装网站能访问，梯子不通了的帖子，出现频率也不低。楼主只是来这报告了。。。

直连还在用 WSS 的，不是小白就是人才。下次看到，麻烦甩出这句话：

指纹：即使开了伪装，它发的 ALPN 始终为 http/1.1，一眼 WSS，实际上无法做到我们想要的“藏木于林”，只会裸送人头。

[chika0801]

hostloc 一搜一大把帖子

https://hostloc.com/thread-1141899-1-1.html
https://hostloc.com/thread-1142673-1-1.html

它搜索不用注册

[cross-hello]

(🤭Unintentionally become master) Mar 8, 2023 12:57:16 RPRX ***@***.***>:

…

loc从这月初开始，又有很多内容为 xxx ws tls（印象中xxx ws也有）被封端口的帖子，现在也是每天基本上有。 从这论坛帖子反映出是3月开会提高了强度。去年10月的强度持续到今年1月好久减弱了。（主观从观察hostloc每日发帖内容积累印象） 去年以来在hostloc的帖子，我就看到过有 类似 nginx前置 xxx ws tls 伪装网站能访问，梯子不通了的帖子，出现频率也不低。楼主只是来这报告了。。。 直连还在用 WSS 的，不是小白就是人才。下次看到，麻烦甩出这句话： *指纹：即使开了伪装，它发的 ALPN 始终为 http/1.1，一眼 WSS，实际上无法做到我们想要的“藏木于林”，只会裸送人头。* — Reply to this email directly, view it on GitHub[#1750 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYHAIFRFLH6IJA4TF6TW3AGSXANCNFSM6AAAAAAVTHOBUU]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYAM7QGPVGEGHB5VKFLW3AGSXA5CNFSM6AAAAAAVTHOBUWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSW7XXTG.gif]

[RPRX]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

[Fangliding]

loc从这月初开始，又有很多内容为 xxx ws tls（印象中xxx ws也有）被封端口的帖子，现在也是每天基本上有。
从这论坛帖子反映出是3月开会提高了强度。去年10月的强度持续到今年1月好久减弱了。（主观从观察hostloc每日发帖内容积累印象）
去年以来在hostloc的帖子，我就看到过有 类似 nginx前置 xxx ws tls 伪装网站能访问，梯子不通了的帖子，出现频率也不低。楼主只是来这报告了。。。

直连还在用 WSS 的，不是小白就是人才。下次看到，麻烦甩出这句话：

指纹：即使开了伪装，它发的 ALPN 始终为 http/1.1，一眼 WSS，实际上无法做到我们想要的“藏木于林”，只会裸送人头。

反自欺欺人协会主席发来贺电

[xqzr]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

HTTP/2 over WS

[cross-hello]

So change here the flag of HTTP/1.1 will be basically ok?
tlsConfig := config.GetTLSConfig(tls.WithDestination(dest), tls.WithNextProto("http/1.1"))

[RPRX]

So change here the flag of HTTP/1.1 will be basically ok? tlsConfig := config.GetTLSConfig(tls.WithDestination(dest), tls.WithNextProto("http/1.1"))

当然不行，WSS 的缺点就是 ALPN 必须为 http/1.1，若这里改为常规的 "h2", "http/1.1"，就过不了 CDN 了。

若不需过 CDN，即直连，服务端由自己控制，一唱一和当然可以，但完全没必要用复杂、且多一次握手的 WSS。

WebSocket 是一个设计得极其失败的协议，它自己搞了一套复杂且多余的协议结构和状态控制，搞成这样却没自带多路复用，相反地，每次都还要多握手一次。本来把全双工的 RAW 直接暴露给用户就完事，WebSocket 硬是要给 RAW 裹上一层包浆，理解不能。

[cross-hello]

All right, we indeed don't pass through CDN. Mar 8, 2023 18:53:02 RPRX ***@***.***>:

…

So change here the flag of HTTP/1.1 will be basically ok? tlsConfig := config.GetTLSConfig(tls.WithDestination(dest), tls.WithNextProto("http/1.1"))[https://github.com/XTLS/Xray-core/blob/c04c333afc68fa43a630ed1022473994a987f804/transport/internet/websocket/dialer.go#L87] 当然不行，WSS 的缺点就是 ALPN 必须为 *http/1.1*，若这里改为常规的 *"h2", "http/1.1"*，就过不了 CDN 了。 若不需过 CDN，即直连，服务端由自己控制，一唱一和当然可以，但完全没必要用复杂、且多一次握手的 WSS。 WebSocket 是一个设计得极其失败的协议，它自己搞了一套复杂且多余的协议结构和状态控制，搞成这样却没自带多路复用，相反地，每次都还要多握手一次。本来把全双工的 RAW 直接暴露给用户就完事，WebSocket 硬是要给 RAW 裹上一层包浆，理解不能。 — Reply to this email directly, view it on GitHub[#1750 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYAXSSDT4GJDE6UDDKLW3BQI3ANCNFSM6AAAAAAVTHOBUU]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYHQZUKS6I5NVWSYNGTW3BQI3A5CNFSM6AAAAAAVTHOBUWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSXAWCVE.gif]

[cross-hello]

😓 The little trick doesn't seem effect. 🤭

Without underlying code modification indeed hard to adjust.

[cross-hello]

Know it.
The ALPN configuration will be override for utls.
#1256 (comment)

[cross-hello]

OK, finish it. 🙃
תודה לאל. Good Luck

But Internet can't be used(as expected), so we changed it back.

[yyiu]

没有去分析，1.7.5 用的vmess+ws+nginx+tls,没套cdn
发现不能用之后换了v之后立马正常，换回1.7.5第一次访问后马上被阻断，只换了服务器端，其它配置不变，这样看来应该是有什么特征被找到了

[timi-owo]

WebSocket 是一个设计得极其失败的协议，它自己搞了一套复杂且多余的协议结构和状态控制，搞成这样却没自带多路复用，相反地，每次都还要多握手一次。本来把全双工的 RAW 直接暴露给用户就完事，WebSocket 硬是要给 RAW 裹上一层包浆，理解不能。

其实并不能说 WebSocket 设计得失败，只能说用在浏览器以外的场景不合适。

它原本只是设计给跑在浏览器里的网页用的，毕竟浏览器不会把原生 Socket 暴露给网页。

WebSocket 又为了兼容性，只能设计成由 HTTP 发起连接，（如果服务器支持），再将这条连接升级（转换）为 WebSocket，

之后就脱胎换骨，不按 HTTP 那套来行事了。而 H2 有多路复用，连接不是一对一，所以不适用 WS，只能走 H1 来握手。

R 佬肯定比我更懂什么是 WebSocket，我也同意既然不在浏览器里跑，那确实没必要多此一举，直接上原生套接字。

[zizifn]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源

https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

[RPRX]

WebSocket 是一个设计得极其失败的协议，它自己搞了一套复杂且多余的协议结构和状态控制，搞成这样却没自带多路复用，相反地，每次都还要多握手一次。本来把全双工的 RAW 直接暴露给用户就完事，WebSocket 硬是要给 RAW 裹上一层包浆，理解不能。

其实并不能说 WebSocket 设计得失败，只能说用在浏览器以外的场景不合适。

它原本只是设计给跑在浏览器里的网页用的，毕竟浏览器不会把原生 Socket 暴露给网页。

它就是设计得失败，你没有理解到我吐槽的是哪一部分。

WebSocket 又为了兼容性，只能设计成由 HTTP 发起连接，（如果服务器支持），再将这条连接升级（转换）为 WebSocket，

到这里还算是正常，我吐槽的是，WebSocket 设计了一套对 载荷 的编码格式等，还不带多路复用，大可不必，远不如直接传输。

之后就脱胎换骨，不按 HTTP 那套来行事了。而 H2 有多路复用，连接不是一对一，所以不适用 WS，只能走 H1 来握手。

（后面那句没看懂）

[RPRX]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源

https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

无关联，这个 HTTP/2 回源，只是多了一种 HTTP/1.1 以外的回源方式，实际上还是要 Cloudflare 先解析、处理，并不是直接透传。

[xqzr]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源

https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

https://t.me/projectXray/1087539

[zizifn]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源
https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

无关联，这个 HTTP/2 回源，只是多了一种 HTTP/1.1 以外的回源方式，实际上还是要 Cloudflare 先解析、处理，并不是直接透传。

试验了下，grpc 可以透传，http2 不可以。。我去他们 discord 问下吧。。

[timi-owo]

WebSocket 又为了兼容性，只能设计成由 HTTP 发起连接，（如果服务器支持），再将这条连接升级（转换）为 WebSocket，

到这里还算是正常，我吐槽的是，WebSocket 设计了一套对 载荷 的编码格式等，还不带多路复用，大可不必，远不如直接传输。

估计是为了制定 Web 标准和规范，WS 解决了网页端全双工通信，但又不想让人把它当成传统意义上的 Socket 来用。

用 R 佬的话来讲就是包了层浆，如果只把它看做全双工解决方案，不被名字里边的 Socket 迷惑，大概就想的通了。

之后就脱胎换骨，不按 HTTP 那套来行事了。而 H2 有多路复用，连接不是一对一，所以不适用 WS，只能走 H1 来握手。

（后面那句没看懂）

WebSocket 需要基于一条独立的信道，而 H2 的多路复用特性跟 WS 的目标冲突，所以不兼容。

至于 H3 是基于 QUIC 的，WebSocket 是基于 TCP 的，所以 ALPN 只能是 H1 了。

[RPRX]

WebSocket 又为了兼容性，只能设计成由 HTTP 发起连接，（如果服务器支持），再将这条连接升级（转换）为 WebSocket，

到这里还算是正常，我吐槽的是，WebSocket 设计了一套对 载荷 的编码格式等，还不带多路复用，大可不必，远不如直接传输。

估计是为了制定 Web 标准和规范，WS 解决了网页端全双工通信，但又不想让人把它当成传统意义上的 Socket 来用。

用 R 佬的话来讲就是包了层浆，如果只把它看做全双工解决方案，不被名字里边的 Socket 迷惑，大概就想的通了。

（想得通什么，没看懂）

之后就脱胎换骨，不按 HTTP 那套来行事了。而 H2 有多路复用，连接不是一对一，所以不适用 WS，只能走 H1 来握手。

（后面那句没看懂）

WebSocket 需要基于一条独立的信道，而 H2 的多路复用特性跟 WS 的目标冲突，所以不兼容。

至于 H3 是基于 QUIC 的，WebSocket 是基于 TCP 的，所以 ALPN 只能是 H1 了。

你对 WebSocket 的理解有误，WebSocket 的出现只是为了实现全双工通信，而不是独占一条 TCP，也不需要独占一条 TCP。
WebSocket over HTTP/2 就是浏览器复用已有的 HTTP/2 连接发起 WebSocket 请求，它是自动的，只要服务端声明支持。
去年我对它进行了一些研究、测试，Chrome 浏览器和 HAProxy 官网是支持的，而 Nginx 和 Cloudflare 还没有支持。

同理，WebSocket 发的 ALPN 是 http/1.1，显然是因为当初设计 WebSocket 时还没有 HTTP/2，所以当初的设计基于 HTTP/1.1。

坦白说我觉得你需要再研究研究，这样我就能看懂了。

[RPRX]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源
https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

无关联，这个 HTTP/2 回源，只是多了一种 HTTP/1.1 以外的回源方式，实际上还是要 Cloudflare 先解析、处理，并不是直接透传。

试验了下，grpc 可以透传，http2 不可以。。我去他们 discord 问下吧。。

因为 HTTP/2 被认为是框架，而 gRPC 被认为是载荷，没缓存的情况下，载荷当然要交给源服务器处理，不然网断了。。。

[zizifn]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源
https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

无关联，这个 HTTP/2 回源，只是多了一种 HTTP/1.1 以外的回源方式，实际上还是要 Cloudflare 先解析、处理，并不是直接透传。

试验了下，grpc 可以透传，http2 不可以。。我去他们 discord 问下吧。。

因为 HTTP/2 被认为是框架，而 gRPC 被认为是载荷，没缓存的情况下，载荷当然要交给源服务器处理，不然网断了。。。

谢谢解释，合理。但是我感觉具体细节就是因为 cloudflare buffer http request body（为了防攻击），这样无法 HTTP stream request. 看看 cf 以后不会不会给个选项 disable buffer HTTP request body 吧。

[timi-owo]

WebSocket 需要基于一条独立的信道，而 H2 的多路复用特性跟 WS 的目标冲突，所以不兼容。
至于 H3 是基于 QUIC 的，WebSocket 是基于 TCP 的，所以 ALPN 只能是 H1 了。

你对 WebSocket 的理解有误，WebSocket 的出现只是为了实现全双工通信，而不是独占一条 TCP，也不需要独占一条 TCP。 WebSocket over HTTP/2 就是浏览器复用已有的 HTTP/2 连接发起 WebSocket 请求，它是自动的，只要服务端声明支持。 去年我对它进行了一些研究、测试，Chrome 浏览器和 HAProxy 官网是支持的，而 Nginx 和 Cloudflare 还没有支持。

同理，WebSocket 发的 ALPN 是 http/1.1，显然是因为当初设计 WebSocket 时还没有 HTTP/2，所以当初的设计基于 HTTP/1.1。

坦白说我觉得你需要再研究研究，这样我就能看懂了。

原来如此，之前有在 Nginx 试过 WS over H2 没通，所以自以为 WebSocket 需要独占信道，这点没去看 RFC，谢谢 R 佬的指正。

[RPRX]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源
https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

无关联，这个 HTTP/2 回源，只是多了一种 HTTP/1.1 以外的回源方式，实际上还是要 Cloudflare 先解析、处理，并不是直接透传。

试验了下，grpc 可以透传，http2 不可以。。我去他们 discord 问下吧。。

因为 HTTP/2 被认为是框架，而 gRPC 被认为是载荷，没缓存的情况下，载荷当然要交给源服务器处理，不然网断了。。。

谢谢解释，合理。但是我感觉具体细节就是因为 cloudflare buffer http request body（为了防攻击），这样无法 HTTP stream request. 看看 cf 以后不会不会给个选项 disable buffer HTTP request body 吧。

不是，你说的这个是 streaming upload，Cloudflare 至今未支持，但它与支持 WebSocket over HTTP/2 没有关联，因为对于这样的特殊载荷必然要额外特殊处理才能通，比如 Cloudflare 的 HTTP/1.1 同样不支持普通载荷的 streaming upload，却支持 WebSocket。

CF 的工作原理是不管三七二十一先解析框架、载荷，没缓存就让处理后的合法载荷回源，若不认识、不处理载荷，就不会放行。

若要支持 WebSocket over HTTP/2，具体细节上，服务端必须声明 SETTINGS 8 为 1，你可以用 WireShark 看看，所以若 Cloudflare 要支持，它自己的 H2 回应必定要设 SETTINGS 8 为 1、增加额外特殊处理，这些都与是否支持普通载荷的 streaming upload 无关。

简单来说又完全是两码事，还是那句话，需要再研究研究。

[zizifn]

其实去年我还跑通过 WebSocket over HTTP/2，可惜 CF 完全不支持，就没啥用，所以我把目标转向了另一个东西，以后再放出来。

cloudflare 已经支持 HTTP2 溯源
https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/

无关联，这个 HTTP/2 回源，只是多了一种 HTTP/1.1 以外的回源方式，实际上还是要 Cloudflare 先解析、处理，并不是直接透传。

试验了下，grpc 可以透传，http2 不可以。。我去他们 discord 问下吧。。

因为 HTTP/2 被认为是框架，而 gRPC 被认为是载荷，没缓存的情况下，载荷当然要交给源服务器处理，不然网断了。。。

谢谢解释，合理。但是我感觉具体细节就是因为 cloudflare buffer http request body（为了防攻击），这样无法 HTTP stream request. 看看 cf 以后不会不会给个选项 disable buffer HTTP request body 吧。

不是，你说的这个是 streaming upload，Cloudflare 至今未支持，但它与支持 WebSocket over HTTP/2 没有关联，因为对于这样的特殊载荷必然要额外特殊处理才能通，比如 Cloudflare 的 HTTP/1.1 同样不支持普通载荷的 streaming upload，却支持 WebSocket。

CF 的工作原理是不管三七二十一先解析框架、载荷，没缓存就让处理后的合法载荷回源，若不认识、不处理载荷，就不会放行。

若要支持 WebSocket over HTTP/2，具体细节上，服务端必须声明 SETTINGS 8 为 1，你可以用 WireShark 看看，所以若 Cloudflare 要支持，它自己的 H2 回应必定要设 SETTINGS 8 为 1、增加额外特殊处理，这些都与是否支持普通载荷的 streaming upload 无关。

简单来说又完全是两码事，还是那句话，需要再研究研究。

谢谢解释。我是需要研究下。不过我也感觉 stream request 是个好东西，看到 chrome 105 fetch支持 half duplex我高兴了一会，如果以后支持 full duplex，一个 http2 请求一个天然的tunnel，我已经把stream requests 未来是否支持的问题，post 到 cloudfalre community call questions上了，看周五他们回答不回答了。

[RPRX]

其实现在当全双工用也没问题，毕竟可以是同一条 H2，如果 Cloudflare 支持 streaming request 实时回源了，H2 和 H3 都要崛起了

[zizifn]

其实现在当全双工用也没问题，毕竟可以是同一条 H2，如果 Cloudflare 支持 streaming request 实时回源了，H2 和 H3 都要崛起了

歪个楼，大佬请问下，有没有什么 wireshark 的插件可以快速的分析 vless 协议?

[lvii]

顺便，我说一下 WSS 代理为什么能被精准识别：

* **指纹：即使开了伪装，它发的 ALPN 始终为 `http/1.1`，一眼 WSS，实际上无法做到我们想要的“藏木于林”，只会裸送人头。**

* 握手：WSS 内层的 WS 要多握手一次，时序特征非常独特。其实开 [early data](https://github.com/XTLS/Xray-core/pull/375) 可以缓解，若不得不用 WSS，建议 `?ed=2048`

* TLS in TLS：这是 TLS 代理普遍存在的特征，需要针对性处理。多路复用可以缓解内层 TLS 握手特征，但却加重了“加密套娃”的特征，参考 [XTLS Vision, TLS in TLS, to the star and beyond #1295](https://github.com/XTLS/Xray-core/discussions/1295) 第二大段，所以目前 XTLS Vision 是较优解法。

所以我现在的建议是：不要用 WSS，并且它应当被列为 deprecated。套 CDN 有 gRPC，直连有 N 种姿势，已无任何必要用 WSS。

请问 @RPRX 使用 nginx + wss 和只使用 xray 的 VLESS-TCP-TLS-WS (recommended) 也是都是相同的弱点，也都不推荐了么

[RPRX]

@zizifn 不知道

@lvii 不推荐

[jgh004]

现在推荐哪种方案？ 如果必须nginx前置，怎么选方案？

[lhbdhr]

现在推荐哪种方案？ 如果必须nginx前置，怎么选方案？

I use grpc now, It's pretty good. you can try it.

[wutongskype]

loc从这月初开始，又有很多内容为 xxx ws tls（印象中xxx ws也有）被封端口的帖子，现在也是每天基本上有。
从这论坛帖子反映出是3月开会提高了强度。去年10月的强度持续到今年1月好久减弱了。（主观从观察hostloc每日发帖内容积累印象）
去年以来在hostloc的帖子，我就看到过有 类似 nginx前置 xxx ws tls 伪装网站能访问，梯子不通了的帖子，出现频率也不低。楼主只是来这报告了。。。

直连还在用 WSS 的，不是小白就是人才。下次看到，麻烦甩出这句话：

指纹：即使开了伪装，它发的 ALPN 始终为 http/1.1，一眼 WSS，实际上无法做到我们想要的“藏木于林”，只会裸送人头。

那我肯定就是人才了, 去年20大那会, 我一台阿里云轻量HK上, tcp协议里最稳的就wss和grpc了...
其他能用的就剩HY和tuic了.
当时vmess-tcp的aws128/256/chacha20*那几种加密模式全是秒墙. 只有zero/none两种不加密模式和vmess-ws(不套TLS)还能勉强能用一下, 但是用几分钟后就会遭到断流. 还有SS全系列也是秒墙.
不过我是前面有个vless的xtls, 然后fallback到vmess ws 和vmess grpc, 最后面还有个nginx的伪装网站...