Xray does not support HTTP/1.1 over TLS.

这句表述有点问题，应该改为 "SplitHTTP in Xray does not support HTTP/1.1 over TLS."

LGTM，@Fangliding 更新一下中文文档

还有个地方需要修改

See PR1 and PR2

@mmmray 话说 SplitHTTP 服务端支持 HTTP/1.1 over TLS 吗？因为有些 CDN 不支持 H2 回源，比如早期的 Cloudflare

just tested it, yes, everything works, alpn behaves normally. h2+tls, h1+notls, h1+tls all work. the code was copied from websocket.

just tested it, yes, everything works, alpn behaves normally. h2+tls, h1+notls, h1+tls all work. the code was copied from websocket.

这样的话，最后一段话需要修改一下，直接说明客户端支持 h2+tls 和 h1+notls，服务端支持 h2+tls、h1+tls 和 h1+notls

it seems the 1.8.16 commit is pushed in xray-core, but there is no release. are you waiting for ZH docs or is there an issue?

it seems the 1.8.16 commit is pushed in xray-core, but there is no release. are you waiting for ZH docs or is there an issue?

刚刚在修改 release note

review了一遍讨论 我当初写效率不行是不想读者对这玩意的性能抱有太大期望 不然可能有人踩坑然后速度boom
query string一开始我就注意到了 就是一直没说 之前也想提一句改成路径
至于alpn我觉得实话实说就行了
ps:ws已经不存在alpn问题了 可以照常发h2,http/1.1

ps:ws已经不存在alpn问题了 可以照常发h2,http/1.1

你确定对着 CDN 发这个还能用 WebSocket 吗

难道你是想说 ECH

ps:ws已经不存在alpn问题了 可以照常发h2,http/1.1

你确定对着 CDN 发这个还能用 WebSocket 吗

之前测试是可以的

ps:ws已经不存在alpn问题了 可以照常发h2,http/1.1

你确定对着 CDN 发这个还能用 WebSocket 吗

之前测试是可以的

听着很怪，重测一下

@Fangliding GET /?session=UUID 这里没改

其实我觉得应该英译中为主，不能有没有翻译的内容，两个语种的文档内容应当保持一致

ps:ws已经不存在alpn问题了 可以照常发h2,http/1.1

你确定对着 CDN 发这个还能用 WebSocket 吗

之前测试是可以的

听着很怪，重测一下

可以用的 需要手动填而已

@Fangliding GET /?session=UUID 这里没改

很快就看到了 已经改了

其实我觉得应该英译中为主，不能有没有翻译的内容，两个语种的文档内容应当保持一致

英语写点commit message和注释能处理的来 文档毕竟还是考验点语文加上量太大(现有eng doc里还不知道多少是机翻)我就放弃挣扎了 之前搞个双语issue模板就够掉头发了 我觉得还是学各大维基写的写 喜欢外语的搞翻译

可以用的 需要手动填而已

如果 NG 的 WS 选 ALPN 有效的话，我测了 Cloudflare 可以，但这是非标准行为不能保证都支持，所以 WS 的 ALPN 问题仍然存在

就是感觉这里 https://github.com/XTLS/Xray-docs-next/pull/518/files 的英文表述挺直观的

一旦客户端完成协商，它可以使用 POST /<UUID>/<seq> 开始发送上行数据

比如中文文档的这个描述是过时的，就是感觉全翻译比较好，如果想加内容，同时也要给英文文档加，双语内容保持一致

就是感觉这里 https://github.com/XTLS/Xray-docs-next/pull/518/files 的英文表述挺直观的

看起来是简单了不过我不想后来者看着神秘的支持列表一头雾水，IETF写标准的时候有时候也会把consideration加进去

一旦客户端完成协商，它可以使用 POST /<UUID>/<seq> 开始发送上行数据

比如中文文档的这个描述是过时的，就是感觉全翻译比较好，如果想加内容，同时也要给英文文档加，双语内容保持一致

这是我翻译看漏了
至于双语我确实搞不来，很多人的PR也是只有中文的，英文文档大部分可能就当初加英文的时候版本时候的翻译，我有个朋友建站最开始也是心血来潮搞个英文版本最后实在撑不住后来删了，等有缘人吧

如果 NG 的 WS 选 ALPN 有效的话

不过我记得根据代码，改不了浏览器指纹的 ALPN，所以应该是无效的

@Fangliding 你测的是 Cloudflare 吗？

没开fingerprint 过了cloudflare

没开fingerprint 过了cloudflare

这样的话我想给 WebSocket 和 HTTPUpgrade 的路径再加一个参数

目前的代码应该是浏览器指纹的 ALPN 不可手动修改，用这俩传输方式时一定会被覆写为 http/1.1 也是不可手动修改

加一个参数 normal alpn，比如 ?na=true 就是用正常的 ALPN

path已经承载了太多 已经有reality了感觉其实不用动这里 更别说alpn本来就是可以修改的

至于utls 稍微修改一下应该就能让它支持alpn修改

uTLS 一直都能改 ALPN，是 Xray（我）不让用户改，乱改的话还是浏览器指纹吗

WSS 会自动把任何 ALPN 覆写为 http/1.1

https://github.com/XTLS/Xray-core/blob/e4f9d03bef5a50e2b11887125adde85b0af2403c/transport/internet/websocket/dialer.go#L94
https://github.com/XTLS/Xray-core/blob/e4f9d03bef5a50e2b11887125adde85b0af2403c/transport/internet/tls/tls.go#L103

等下，所以你是咋搞出 h2,http/1.1 的？@Fangliding

uTLS 一直都能改 ALPN，是 Xray（我）不让用户改，乱改的话还是浏览器指纹吗

WSS 会自动把任何 ALPN 覆写为 http/1.1

https://github.com/XTLS/Xray-core/blob/e4f9d03bef5a50e2b11887125adde85b0af2403c/transport/internet/websocket/dialer.go#L94 https://github.com/XTLS/Xray-core/blob/e4f9d03bef5a50e2b11887125adde85b0af2403c/transport/internet/tls/tls.go#L103

等下，所以你是咋搞出 h2,http/1.1 的？@Fangliding

它确实会发 可能是在哪里被tls option被覆写了

不过我需要修改一下证词 我之前的alpn用的是qv2ray设置的 正确的alpn写法是

"alpn":[
  "h2",
  "http/1.1"
]

但是qv2ray的配置生成不对 它发的是一个这样的玩意

"alpn":[
  "h2,http/1.1"
]

这压根就不是一个有效的alpn 可能cf看到之后就回落了 正确发送的alpn是没法建立ws连接(((
虽然闹了个乌龙不过似乎找到一个bug

找到问题了

https://github.com/XTLS/Xray-core/blob/e4f9d03bef5a50e2b11887125adde85b0af2403c/transport/internet/tls/config.go#L396

这个 WithNextProto 仅在 config 中没有设置alpn时生效 也就是说它是设置默认alpn且可以被config覆写

这么搞笑的吗

确实你那图是错的，正确的会这样显示：

ALPN Protocol
    ALPN string length: 2
    ALPN Next Protocol: h2
    ALPN string length: 8
    ALPN Next Protocol: http/1.1

那你把 wss 非浏览器指纹时能改 alpn 的 bug 给修了吧，此外再测一下 wss 正确发 h2 在前的 alpn 时能不能连得上 cf

试了不行 有h2就不行 其余情况哪怕不是http/1.1 写h3h4什么的都能连
我觉得不用改吧 毕竟也没用户瞎改 如果有人实在想发
现在xray服务端的情况是 必须要有http/1.1 与此同时不能有h2 我觉得可能比较有用的改动是允许客户端发h2的情况下两边正常握手 当然这种行为本身不知道能不能被主动探测利用 可能还得结合path进行过滤