RPRX
> 看起来已经写好了就等合并 https://go-review.googlesource.com/c/go/+/578575 ~reality 的更新工作快来了~ 希望 Golang GKD，~~想起了我那两个没下文的 PR~~ ECH 这个扩展的存在给 XTLS 找了个台阶下，~~后续 data record 长度不稳又怎么了我就不能是 ECH 吗~~ 对 REALITY 则可有可无，反正只要服务端写有你发的 SNI 就只验证 session id，~~啊不过服务端只能读到明文的 key_share 来使用~~ 鉴于 Xray 对...
预计在下个版本中出现，~~不然下个月现有的 Vision 可能要废了~~
先 rebase 一下
虽然本来想赶在下个月前上 Vision seed 但也不会那么快铺开，所以放下个月，以及 VLESS encryption，这个月我们专注 XHTTP
目前 Xray 中的 SS2022 是基于 sing 那边的代码，在 Xray 这里好像有点 buggy（比如服务端 UDP），正好 v2fly 前段时间也实现了 SS2022，你测下它的有没有 OOM 问题，没问题的话我们 port 过来即可
刚刚在想 XUDP 的 Global ID 没读取 SS2022 UDP 的那个 ID，回头看了下 VLESS 转 VLESS 好像都没传递 Global ID，还是要写一下
感谢 PR，我觉得启动耗时不是大问题，毕竟启动就一下，~~属于是能开就行~~，耗内存才是大问题，它会导致 Xray 在低内存平台比如硬路由上无法启动，~~iOS 上不知道会不会杀掉~~，[Xray-core v1.1.4](https://github.com/XTLS/Xray-core/releases/tag/v1.1.4) 我还写了个优化，~~后来被 v2fly 抄去了~~ 想起来之前我改这部分代码时有写缓存机制，但最后默认不用，就是为了省内存，~~如果需要缓存直接用就行~~：https://github.com/XTLS/Xray-core/issues/68#issuecomment-745231528 https://github.com/XTLS/Xray-core/commit/45f44c401acd31e0f5dcf8e7b4f2789cbc1be12a#diff-dbe303c220dd0c61c55dc37acc6058cc458cad4b6e12a7824b695bd8f179049fR170-R173 ~~现在看这英文有点歧义~~ > Thie PR created some wrappers to temporarily cache the geo data which can reduce the CPU usage....
一些 APP 会使用 ping 来检测连通性，而 socks 不支持代理 icmp 流量，tun2socks 此前的行为则是不处理、不响应
这个 PR 非常高效地实现了对 ping 请求的本地响应，支持 IPv4 和 IPv6，使这些 APP 可以正常工作
@Mygod 比如 https://t.me/projectXray/424048 此外，实测 Netch 是本地响应 ping，@Dreamacro 说 Clash 也是本地响应 ping，我认为他们的做法具有参考意义，毕竟 ping 全丢是有些奇怪的事情，加个本地响应并不多余，可以减少一些非预期情况、解决一些潜在的问题 我使用的是 XTLS 的版本，这是一个礼貌性 PR，看你们是否需要了