hireall

> Other protoctols open UTLS will get [e47eae8f8c4887b6](https://tlsfingerprint.io/id/e47eae8f8c4887b6). Tried vless+tls+vision with chrome fingerprint, did get e47eae8f8c4887b6. It looks like only tls+ws renders chrome fingerprint as b8ddad74f1546398. BTW, does fingerprint send...

> 我服务端1.6.5版本最新的用vision，iOS端用shadowrocket还是老的稳定版1.6.1内核，用普通vless+tls（不带xtls）直连，没有遇到过断连的情况。但op端ssrp用最新1.6.5 vision连接也是时常断连半分钟到几分钟不等。可以推测问题在最新版vision的客户端。 手机客户端V2rayNG默认不开启mux，无论是tcp+ws还是vision，阻断都很厉害，打开Youtube秒挂。 后来找到了自定义配置的办法，在配置文件中开启了128路mux再配合tcp+ws，可用性好了很多。 因为没有看到过vision类似的报告，所以推测阿里这边的审查可能和单位时间新增连接数有关 而端口IP一直没有被封，极端情况也可能是阿里防火墙防ddos的默认行为 可以看下你iOS端的shadowrocket有没有mux，是不是也可能是mux减少了连接数的关系？ 不过总的来说阻断和这个issue没有必然关联 这个issue本身就是chrome指纹配置在tls+ws时的行为不正确

> > 基本配置：vless+tls+ws，回落正常站点伪装 R2C做旁路由，ubuntu20.04系统 使用dmsmasq仅分流gfwlist域名流量，TPROXY模式 当前版本使用Xray 1.6.5 > > 通过 [get-tls-fingerprints.py](https://github.com/gfw-report/get-tls-fingerprints) 抓取获得的指纹信息: > > `sudo tcpdump '(tcp[tcp[12]/4]=22) and (tcp[tcp[12]/4+1]=3) and (tcp[tcp[12]/4+5]=1) and (tcp[tcp[12]/4+9]=3)' -w - | ./get-tls-fingerprints.py | grep domain.com`...

> 根据之前的讨论 浏览器发 ws 时候 指纹确实是不一样的 原因是 ALPN 仅支持 http/1.1 所以这个应该是正确的现象 [#1256 (comment)](https://github.com/XTLS/Xray-core/pull/1256#issue-1410102500) 但是针对ws，指纹设置为safari、firefox时，查询到的结果中并没有 go 客户端的命中，仅设置为chrome时会有如题图中的结果，不知道是否会引起被识别的风险。