11.18日cloudflare挂掉的情况下，ws协议走cf cdn还能走通，xhttp 走cf cdn就挂了

[appotry]

说明啥，ws似乎更底层，cf挂掉的情况下还能用

日志一直提示ws协议将被弃用，这时候就看出ws的优越性了

个人是希望ws协议保留的，有啥非弃用不可的理由么？

[maoxikun]

ws走的http1.1，xhttp的stream-up/stream-one走的h2也就是grpc，协议实现都没了解过，仅仅在某个特殊的场景下，通过判断一个能用一个不能用就代表能用的更优越这逻辑真是绝了，何况cf挂掉这段时间你是否测试过xhttp通杀大部分场景的packet-up模式？

[appotry]

ws走的http1.1，xhttp的stream-up/stream-one走的h2也就是grpc，协议实现都没了解过，仅仅在某个特殊的场景下，通过判断一个能用一个不能用就代表能用的更优越这逻辑真是绝了，何况cf挂掉这段时间你是否测试过xhttp通杀大部分场景的packet-up模式？

能用不能用是最优先事项，什么速度延迟等都是能用之后才会考虑。都不能用了，谈个屁场景

对别人完全不了解就假设什么都不懂，智商堪忧

还有一个，cloudfalre partner虽然很早就停止了，但停止之后还可用很长时间。直到不能续签ssl，但此时ws协议依然能用。彻底禁止了partner之后，ws还可用了很长时间

在cf内部实现里面，ws就是更底层，什么h1,h2,h3,ssl都不能用的时候，ws还是可用。在h1都不能用的时候，ws是h1.1 upgraade的却可用，你考虑过为什么么

ws就是cloudfalre 内部实现逻辑里面最稳定的，通杀所有cdn

[maoxikun]

“cf故障情况下能用的ws比不能用的xhttp更优越”不是你表达的意思么，当然能不能用也是你敲一下键盘的事，反正我xhttp用的好好的，毕竟我有图片为证，你就简短几个文字，配置以及日志什么都没有，我通过算命了解你么？回答你的问题还得了解你，这都能人身攻击了笑死，当然关于你其他的言论我也是不能苟同的但是懒得喷

[RPRX]

你这 UA 咋这么标准，是自己填的还是用了浏览器转发

[maoxikun]

你这 UA 咋这么标准，是自己填的还是用了浏览器转发

自己填的，之前看过代码reality好像直接拿的utls的ua还是啥，就是一个chrome或者firefox字符串，指纹跟ua对应是不是更易于隐藏？

[RPRX]

REALITY 客户端代码取的那个 UA 只用于 SpiderX 就随便取了；对 CDN 来说能看到明文 UA 自然是和浏览器一样最好

[RPRX]

事实上 WS 不会被删，但你无法以单一 CDN “ws似乎更底层”来论证 WS 更优越，因为 XHTTP 的优越性本质在于它提供了很多选择 https://t.me/projectXtls/1107 而无关外部条件，举个例子，这次如果 CF 完全不可用，对于 XHTTP 你还有很多其它 CDN 可以用

此外 WSS 的 ALPN 固定为 http/1.1，GFW 曾经针对过它，虽然开 ECH 可以遮住它，但据说俄罗斯已经完全封锁了 cloudflare-ech.com

[appotry]

这种ws使用方式，除非服务器挂了，或者cf挂了，否则无论什么时间都一直稳定可用。 @RPRX 和你提到的帖子中使用方法不同

其实还对ws使用nginx里面进行了很多细节geek

[appotry]

对服务器还上了各种伪装，端口，防火墙，默认网站，ssl泄漏，爬虫屏蔽等等，也不知道那个起作用了，反正一直非常稳。
任何时间段都稳，ws更是稳中稳，cf各种故障的时候ws还能用

[maoxikun]

首选说一下，一直使用的是WebSocket over h2, h3 ,并禁用tls 1.0 1.1，并且是选择高强度加密方案

可能是你没有理解我的使用场景，这个警告在我这种使用场景下是多余的

客户端 ──CDN ALPN协商──→ SSL Nginx ──纯WebSocket──→ Xray
            ↑                               ↑
        ALPN=h2/h3                      无ALPN信息

服务器：多服务器单人独享，主打一个极致稳定可靠。wrap ipv4+ipv6多ip , dnsmasq，或者smartdns加速，内核优化，ip协议栈优化等

xray : 多协议同时配置，每个协议不同端口，每个协议都在外部nginx多个域名

xray ui：原来纯手动，最近使用全自动订阅。配合客户端订阅自动故障转移

nginx： 复用所有不同协议端口反向代理到443，每种协议都是多域名配置，自签名ssl或者使用cdn的ssl

cdn: cloudflare 里面多域名，并且配置其它cdn，不同cdn不同的域名。使用cdn的ssl自动续签，完全没有管理ssl的烦恼。

dns： 使用多种dns 混合使用， 国内dns，cf 的dns， 分线路解析，cloudflare ip 优选在dns优选或者在客户端里面配置ip 优选

客户端： 多客户端使用，路由器全局透明代理。手动配置参数，全自动订阅参数，smartdns，各种域名ip分流，故障自动切换不同节点，不同协议，不同cdn，不同dns，还可以配置ip优选

综合考虑稳定，低延迟，无感使用选择的方案，基本把能想到的优化手段全上了，还有啥可以极大提高的方法么？
上面只提到了主要部分流程，很多细节流程有多个方案

这种情况下使用ws协议的时候，ssl一直是全自动开启的，只是xray没有感知到。 此时xray ui 获取的自动订阅链接里面是没有配置alpn的，其实alpn在上层nginx里面一直实现着，只是xray没有感知到

这种场景下，服务器端ssl由于多域名不好自动acme续签配置。需要一个自动续签多域名ssl，简单实现是在cdn管理客户端看到的ssl

此时xray是否应该有一种配置机制获取外部nginx的tls配置，或者说准确是cdn的ssl配置。这里应该为配置外部tls 类型，并且可以配置alpn类型或者忽略，在cdn修改alpn类型非常方便。

@RPRX 大概都看过，但没有仔细研究xray的配置，暂时没有发现可以实现这个要求的配方方法。"security": "tls" 这里必须配置tls才能解除这个警告么？ xray现有的配置参数有可以实现使用外部tls的配置忽略自身tls的配置么？如果没有的话，可以计划添加一个新的tls类型么？毕竟反向代理很常见，直接使用xray tls要独占443端口，毕竟443端口宝贵，过GFW检测被封概率更低

nginx有个ssl 多级透传，但和xray, xray ui ，nginx之间各种参数配合也是一个坑

另外：喷子滚远点，都不理你了还跳出来秀智商，这智商跳起来能打到小四的膝盖么

把图片中这行高亮代码注释或者删掉然后重新编译就能实现你解除警告的自慰需求了，这警告跟你用什么ALPN或者什么security没有半毛钱关系，以你的智商应该不会听不懂吧，最后一喷，已block

[RPRX]

客户端 ──CDN ALPN协商──→ SSL Nginx ──纯WebSocket──→ Xray
            ↑                               ↑
        ALPN=h2/h3                      无ALPN信息

以前测试的结果是只有 HAProxy 支持 WebSocket over HTTP/2，至于 WebSocket over HTTP/3 这种东西我不确定它是否存在

Xray-core 的话 WSS 的 ALPN 就是 http/1.1，无论你 alpn 选的是什么，这么说吧你用 WireShark 抓一下流量看一下 ALPN 是什么

[RPRX]

搞了半天说的一直是两件事

首先那个警告是只要你用 WS 就会有，其次 WS 套 TLS 后 GFW 能看得到的 ALPN 就是 http/1.1，并不是你想的 h2/h3，除非开 ECH