[VLESS] TLS+fallbacks大文件curl报错

[ghost]

V2Ray版本为 v4.32.0
配置文件同 https://github.com/v2fly/v2ray-examples/blob/master/VLESS-TCP-TLS%20(maximal%20by%20rprx)/config_server.json
只是将xver改为0，dest改为TCP端口
在nginx的web目录下放两个文件，分别为100mb和10mb的文件file2和file3
执行curl命令，file3正常下载，file2报错

但是使用wget或者直接用chrome浏览器下载是没有任何问题的
通过查看nginx记录，chrome和curl使用的都是http2连接，wget使用的是http1
直接使用nginx搭建443端口tls+web服务，也是没有任何问题的。只有使用v2ray fallbacks才会出现问题
@RPRX

[ghost]

@RPRX 虽然issue被close了，但我还是想虚心请教下错误可能是什么原因导致的。（可能是我小白吧
我已经排除了其他因素的影响，比如指定nginx的web root目录在磁盘中，而不是/dev/shm，然后在另外一台电脑上使用curl。
但是结果依然是文件超过一定大小就报错。
不使用v2ray fallbacks就不会报错。
使用v2ray fallbacks，但不使用TLS也不会报错

[RPRX]

试试 XTLS（不开启特殊功能

[RPRX]

另一个建议：换个配置好点的机器来测试

[ghost]

试试 XTLS（不开启特殊功能

试了，结果一样

另一个建议：换个配置好点的机器来测试

我的机器内存大小1gb，不至于吧(

[ghost]

@RPRX 因为close了的issue可能传达不到所以 @ 一下

[RPRX]

我的机器内存大小1gb，不至于吧(

（至于

[ghost]

@RPRX
今天总算找到时间来做实验了，我用本地虚拟机给了8g内存(cpu为4核心8线程i5-8300h，这会儿性能总够了吧)，成功复现了这个bug。
不过发现要让bug的出现条件多了一个，就是curl必须是debian基系统的curl，比如deepin ubuntu debian。而redhat基系统，比如centos fedora不能复现。这个要求仅限于使用curl的客户端，对服务端的系统没有要求。
也就是要复现bug必须满足三个条件：

1.v2ray前置分流
2.v2ray开启tls(监听443端口)
3.客户端使用的curl必须是debian基系统的

这次我的v2ray和nginx服务是在fedora系统上搭建的，在fedora系统下使用curl，不能复现，但在deepin或者ubuntu系统下使用curl就能复现了。但是又不能说是debian基系统curl的问题，因为它确实能获取大文件，只是遇上v2ray前置分流就不行了
这次在8g的机器上也是，文件大小为100m就curl就不能获取了，而且在发生Bug的时候，curl还没有开始下载，你可以看到下载进度条为0
ps:
1.v4.32.1问题依然存在
2.bug的复现率是100%的，并非时好时坏

[RPRX]

根据描述，看起来更像是 debian 系 curl 的 bug

[RPRX]

但是又不能说是debian基系统curl的问题，因为它确实能获取大文件，只是遇上v2ray前置分流就不行了

（这个逻辑是不对的，因为 chrome 浏览器、wget、其它系统的 curl 都没问题，已经足以说明问题在哪了

[ghost]

但是又不能说是debian基系统curl的问题，因为它确实能获取大文件，只是遇上v2ray前置分流就不行了

（这个逻辑是不对的，因为 chrome 浏览器、wget、其它系统的 curl 都没问题，已经足以说明问题在哪了

@RPRX 个人认为fallbacks应该是透明的，即不让用户感受到v2ray前置分流的存在，让用户以为就是nginx在监听着443端口。且不说逻辑对不对，至少透明是做不到了，因为如果nginx放在最前面是没有这个问题的。文件下载不到，这都是小事，我更担心的是这可能成为v2ray前置分流的特征。

[RPRX]

@kirin10000

而且在发生Bug的时候，curl还没有开始下载

请提供此时 v2ray 的日志，看看到底发生了什么

[ghost]

@RPRX

2020/11/07 10:58:49 [Warning] v2ray.com/core: V2Ray 4.32.1 started
2020/11/07 11:00:30 [Info] [1605214724] v2ray.com/core/proxy/vless/inbound: firstLen = 24
2020/11/07 11:00:30 [Info] [1605214724] v2ray.com/core/proxy/vless/inbound: fallback starts > v2ray.com/core/proxy/vless/encoding: invalid request version
2020/11/07 11:00:30 [Info] [1605214724] v2ray.com/core/proxy/vless/inbound: realAlpn = h2
2020/11/07 11:00:30 [Info] [1605214724] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vless/inbound: fallback ends > v2ray.com/core/proxy/vless/inbound: failed to fallback request payload > write unix @->/dev/shm/nginx_unixsocket/h2.sock: write: broken pipe

这里用的是domain socket反代，tcp bug一样的

[RPRX]

ALPN 只有 http/1.1 时是否存在此问题

[ghost]

ALPN 只有 http/1.1 时是否存在此问题

@RPRX 如果指定ALPN 只有 http/1.1，这时候curl会以http1的方式连接，此时没有问题。

[RPRX]

目前看来问题应该是“特定版本 curl 的 h2c 请求会被 Nginx 直接关闭”，请测试下 Caddy 有无此问题

[RPRX]

（在这里 fallbacks 的角色只是忠实的流量转发，支持 h2 或许需要修改 Nginx 的配置，以关闭某些检查？可以试试其它版本

[ghost]

目前看来问题应该是“特定版本 curl 的 h2c 请求会被 Nginx 直接关闭”，请测试下 Caddy 有无此问题

@RPRX 我对caddy不熟悉，学习需要一段时间，一时半会儿是弄不了。如果是这个原因，我觉得只要换一个tls前置分流器，如果能复现同样的bug，更能说明问题。不过可惜我对别的tls分流器也不熟

[RPRX]

目前除了 v2ray 外，只有 trojan-gfw 支持 h2 回落，可以试试（trojan-go 暂不支持 h2 回落