我一直以为 Xray 现在的 ECH 就是这样的，原来不是吗

没什么人弄 草案写的是ALPN也属于敏感的扩展可以考虑加密 实际上除了翻墙的无人在意
go有一个issue但是三条消息就丢那了
Chrome的也是外部直接 http/1.1
我去提过编程语言接口难设计要不把outer ALPN也列入ECH Config 回复是那是实现自己的事
这个小utls fork怕不是第一个这么做的

@copilot 现在 Xray 的 ECH 会加密哪些信息

@RPRX I've opened a new pull request, #5726, to work on those changes. Once the pull request is ready, I'll request review from you.

我特么问个问题而已，它给我开个 PR

#5726 (comment) 所以 ech_outer_extensions 的长度的确有可能会变化，不过又不能假定 SNI 多长所以还好，比起来这个，现在的 inner payload 是不是甚至达不到 128？真 ECH 比最短的假 ECH 还短？Chrome 也是这样吗？

它有四个档 假ECH扩展往里roll 真ECH在计算出总长度后向上取整

utls 合并了 不过鉴于这不是 Chrome 默认行为 我需要再考虑一下接口

直接默认就行了为啥要考虑接口，我在 #5726 问那么多就是想确认下，结论是由于内层域名长度不能被 GFW 假定所以即使不小心多了 32 字节也没事

比如可能还是有人想要 ws+http/1.1 outer+ech 毕竟 ws 和 h2 可能不完全一样 如果一个连接同时存在 ws 长度特征 又是 h2,http/1.1 的 alpn 那只有可能是 新版utls 我想的是要么加个 "echHideALPN": true 或者 fingerprint: "chrome_alpn" 之类的选项 来手动控制
当然无论如何可能都有点杞人忧天

那确实 WS/HU 没有 h2 的指纹，但是 WS+ECH 挺小众的，说不定直到 GFW 把 cloudflare-ech.com 封了都不会针对这特征

毕竟也就过 CF 还会用一下 WS/HU 了，直连还非要用它们感觉有点 NTR

况且现在本来就是顶着 Chrome CH 指纹但是后续连接不完全符合 Chrome WSS 特征，所以我觉得无所谓吧

话说你这个是不是只能给 uTLS 用、 改不了 Golang 内置 TLS？

ws指纹倒是没啥问题 ws协议很简单没啥实现指纹 全看下面发的数据 然后tit

话说你这个是不是只能给 uTLS 用、 改不了 Golang 内置 TLS？

是 就是因为没法动 gotls （除非fork） 我才去弄 utls 的

@Fangliding 把 uTLS 依赖改到 refraction-networking/utls@1ba92b0 吧

我刚看了下你的 fork，或许是时候把 echForceQuery 的默认值改为 full？

我想utls发版了再动的 不过更一下应该没关系

utls 我改到了最新的commit
echForceQuery 默认调成 full 了 主要是前段时间群里有不明真相的群众抱怨怎么这个填个无效的也能连 然后不抓包都不知道有没有生效(yysy那个none我觉得也用处不大)
还有我把ECH乐观缓存的时间调到了4h 因为根据饺子醋研究cf的ech是一小时一轮有效期五个小时 最差的情况下这个config只能有效四个小时（我后来才知道我之前捏的这个缓存叫乐观缓存）

uTLS 别改到最新 commit 吧，它刚加那俩新版指纹还不知道有没有啥坑

反正大家用不到？都是chrome

@Fangliding 试下 REALITY 加新版 Firefox 指纹是否可用，也就是 reuse x25519 与否是否都正常

我照着之前的test改了下 那几个不用写版本号的“常见指纹列表” 里 360 和 android 是坏的 android 我很久以前调查过是他那个指纹还是 tls12 的原因 我也开过issue（很明显到现在都没改） 360 我没看

我不喜欢其他指纹不是它们不能用 而是实在是有点久没更新 为数不多的人集中在处理 chrome 相关指纹上 连xray的一些乱七八糟的设置都是尽量学这玩意