RPRX
https://github.com/XTLS/REALITY#vless-xtls-utls-reality-example-for-xray-core-%E4%B8%AD%E6%96%87
请使用 v1.7.2+ https://github.com/XTLS/Xray-core/releases/tag/v1.7.2
> curranty only trojan+tcp+tls/xtls has fallback ability you can't use fallback with vless/vmess Where did you get this info? Both VLESS and Trojan support `fallbacks` in Xray-core.
抱歉，的确是 VLESS 分享链接标准提案没有及时更新，fingerprint 参数还会加些选项，等~~秒天秒地秒空气的~~ Reality 协议加入 Xray-core 后，会一起更新一次 VLESS 分享链接标准提案，下个版本发布
麻烦用手机开代理，电脑端浏览器的插件设置为手机的 http 代理地址，然后用 wireshark 截取对应的流，并传上来（记得脱敏）
如果你遇到的问题可以稳定复现，是不用关闭这个 issue 的，它会帮助我们改进 Xray-core 的代码 说不定有人遇到了同样的问题，看到这个 issue 后会给我们反馈更多信息
> [log.zip](https://github.com/XTLS/Xray-core/files/10378223/log.zip) 今天一大早抓了一个，隐私浏览器访问的youtube，大概点重试点了6次才成功进去。 麻烦仅保留走代理的 TCP 连接数据
这个问题挺有趣的，根据你最新的报告，**看起来基于任何代理协议，任何时候访问谷歌学术都会导致连接被掐（即使开了 mux）** > 其次，使用 curl 代替浏览器访问不会被阻断（推测是特征不同）。 若可以稳定访问，请用 wireshark 截取 curl 访问时代理的 TCP 流，并分析和浏览器访问时的不同之处
另外请测试开启 mux 时 curl 访问谷歌学术是否会最终导致 mux 的 TCP 被掐，多观察一段时间
首先，感谢你的测试 > 此外，我也测试了一下直接用浏览器http代理，打开各种网页，文档，youtube等等，确实如readme所说，没有一个请求被误报。 其实还是有的，我和 @yuhan6665 都看到过，但出现概率非常非常之低，可以忽略不计的程度 > 我又看了下源代码，感觉这个检测方法总体来说是可行的，只是upCount和downCount根据不同的实现可能要选用不同的值。 我们这边的测试，包括群里很多人的测试结果都是直接刷屏（识别率目测至少有 80%） 我看了你贴上来的数据，发现一个问题，就是很多 upCount 看起来并不包含现代浏览器的 TLS Client Hello **现代浏览器的 TLS Client Hello 基本上就是 517 字节**，所以这方面你可以排查下，毕竟是检测 TLS in TLS 有尝试将电脑端浏览器的 HTTP 代理设为 Trojan...