v2ray + tls +websocket 的断流很可能是第三方客户端导致的 [纯讨论，不涉及issues]

[choicky]

PC 端 和 iOS 都在使用相同服务器的 v2ray + tls +websocket 。
我的PC端没有发现明显的断流现象，而 iOS 有很明显的断流现象，尤其是看 twitter 的视频时，通常在10秒钟左右就断流了。

最近折腾了一下，发现：

1. iOS 下的 Shadowrocket 使用上述组合一定会断流
   不管我是否在 v2ray.service 设置 /usr/bin/env v2ray.ray.buffer.size=1

Updated on May 03, 2018:

• Shadowrocket 在 v2ray.ray.buffer.size=0情况下依然有明显的断流。

2. iOS 下 Kitsunebi 没发现断流
   不管我是否在 v2ray.service 设置 /usr/bin/env v2ray.ray.buffer.size=1
   btw，只测试了半个小时左右。如以后有新发现，会update在这里

3. iOS 下 Pepi 在设置了 /usr/bin/env v2ray.ray.buffer.size=1之后能避免断流
   如没有设置，则 Pepi 跟 Shadowrocket 类似，会断流。

Updated on May 03, 2018:

• Pepi在 v2ray.ray.buffer.size=1情况下依然有断流，只是断流现象比不设置时有所改善。
• Pepi在 v2ray.ray.buffer.size=0情况下暂时没发现断流

btw，设置办法如下：
/etc/systemd/system/multi-user.target.wants/v2ray.service 中，

ExecStart=/usr/bin/v2ray/v2ray -config /etc/v2ray/config.json

改为

ExecStart=/usr/bin/env v2ray.ray.buffer.size=1 /usr/bin/v2ray/v2ray -config /etc/v2ray/config.json

[nicholascw]

试试改大buffer size或者直接改成0？

[choicky]

@nicholascw 改为0 对 shadowrocket 的断流现象没有改善，但看起来能解决 Pepi 的断流问题。

[beyondkmp]

@choicky 我改了一个版本，就服务端换下，有空可以再帮忙测试下

[choicky]

@beyondkmp releases 里面依然是 v3.21，新版本在哪呢？最好能提供ubuntu x64 的版本，因为我不一定能够从源码编译出来 ....

[beyondkmp]

发了个linux的测试版本， 你测试下。https://github.com/beyondkmp/v2ray-core/releases/download/test/v2ray-custom-linux-64.tar.gz

[bash99]

@beyondkmp 关闭mux，该测试版本对 #1014 问题有效。

BTW，1014应该和这个是类似问题，并且给出了100%可复现步骤（curl下载中 control+c 中止会触发bug，设置 -m 10之类最大时间后停止不会）。

[choicky]

@beyondkmp @bash99 这测试版本，在我 vps 运行之后，客户端无法正常连接 ...

服务器端出错提示 Transport|Internet|WebSocket: failed to serve http for WebSocket > accept tcp [::]:10086: use of closed network connection

我把 v3.21版本的v2ray stop，使用 v3.21 的 config.json 来运行这个测试版，也是类似的错误。

我是 caddy server 来转发 ws 。 应该跟 caddy 没关系吧，因为 v3.21 的 v2ray 能跑起来。

[choicky]

@beyondkmp @bash99

好奇怪，把 v3.21版本的v2ray stop，使用 v3.21 的 config.json 来运行 ，忽然见又能用这个测试版了。

我是 iOS 10，shadowrocket 上依然断流，程度没有变化。
Pepi暂时没发现断流。
Kitsunebi 没有发现断流。

也就是说，v3.22与v3.21，在我iOS 10上，改善了 Pepi的断流现象；对 shadowrocket 和 kitsunebi 没有额外的影响。

[beyondkmp]

shadowrocket的客户端版本是多少啊？这个目前还真没有测试环境 @choicky

[choicky]

@beyondkmp
shadowrocket 正式版的 v2.1.21 以及 测试版的 v2.1.22 都一样会断流。

我iPhone 6s 中目前没有断流的客户端只有 kitsunebi

[Justsoos]

v2ray 这个产品和 ss/ssr 不同，相当多时候要服务器和客户端一起改。
差一个看上去不起眼的参数都会连不通。
或者，你用别人好用账号一测便知。

[bash99]

@choicky 是不是 shadowrocket 缺省就开启了mux？
3.22 这个测试版本放断流，对我这边来说，client必须关闭mux才有用，否则还是断流。

[choicky]

@bash99 v3.21 和 3.22 开启 mux 在 Kitsunebi 上没出现断流。
shadowrocket 上没看到 mux 的设置之处，我把 json 导出来也没看到，内容如下：

{
  "ping" : 64,
  "weight" : 1509152440,
  "title" : "",
  "host" : "已隐藏",
  "ota" : true,
  "file" : "\/ws",
  "uuid" : "已隐藏",
  "method" : "chacha20-poly1305",
  "flag" : "SG",
  "obfs" : "websocket",
  "type" : "Vmess",
  "user" : "",
  "protoParam" : "",
  "tls" : false,
  "port" : 443,
  "proto" : "",
  "password" : "e7c5876e-6d4f-4998-97a5-23a76f9c299c",
  "data" : "",
  "obfsParam" : ""
}

[bash99]

@choicky @beyondkmp 3.22对我也是算改善断流，之前会几十秒都没响应（curl被control+c）；用3.22，那么则是在5~20秒之间恢复响应。

[lucifer9]

Kitsunebi 主界面可以显示连接时间
说它不断流的，有没有注意过，这个时间经常会重置
放着不动，持续连接时间就长些，经常用的话，就常常重置
也就是说其实它是经常会断了重连的（不管是啥原因）
没准儿这样恰好避开了断流呢

[beyondkmp]

kitsunebi是有自动重连的功能

[beyondkmp]

测试安卓bifrostV用之前的版本下载google play的东西都是下载到90%多就断流了，用了这个测试版本基本上都成功了。

[choicky]

@lucifer9 @beyondkmp 我把 kitsunebi 的自动重连功能关闭之后，v2ray 3.21和 3.22都没有断流。pepi 和shadowrocket 有断流

[ntgeralt]

shadowrocket是有点问题。我试过一个客户端配置文件，cdn ws+tls的，有路径，但完全无host。结果电脑客户端打开google1秒，手机打开个google要7-8秒

[bash99]

我现在h2+vmess；还是偶尔有断流（对比暂时没被封的ssr）。但是比ws+tls被ISP侦测中断要好。

[beyondkmp]

@bash99 你用的最新版本的吗？

[choicky]

@bash99 ws+tls 会被ISP侦测吗？我以为tls是很靠谱的 😂

另，h2 怎么配置呢？一直没看到比较详细的教程。

[beyondkmp]

tls我觉的比较靠谱吧。isp侦测目前对https的流量还是会放行的。不过也要看地方了

[bash99]

@beyondkmp 用的是你这个issue放出来的测试版。
tls + ws 我本地ISP会探测出来，特征是对应443端口被临时封锁一个小时（如果没后续连接，如果有连接就一直封锁），但是h2不会。

h2和tls都有一定断流，我现在是开一个http代理和socks代理，拿一个haproxy，用如下脚本自动测试http代理的联通性
option tcp-check
tcp-check send GET\ http://google.com/generate_204\ HTTP/1.0\r\n
tcp-check send Host:\ google.com\r\n
tcp-check send User-Agent:\ curl/7.52.1\r\n
tcp-check send Accept:\ /\r\n
tcp-check send \r\n
tcp-check expect rstring ^HTTP/1.[1|0]\ 204
，同时开放给内部用。
效果就是平均40分钟，单个节点会碰上一次断流，有多个节点不容易碰上都断的情况。并且断流时直接访问对应https站点正常。

如果需要我可以单开一个issue给出比较详细的配置。

[iKingEast]

shadowrocket和kitsunebi我都有用,都是最新商店版,ws+tls+nginx.软件都是最新版
结果和lz的完全相反,kitsunebi不开启断线重连的话,偶尔会断开,shadowrocket也会断开,但频率比kitsunebi的低很多.
打个比方,kitsunebi如果每天一断的话,shadowrocket就是几天一断.

[pingma]

@bash99 请教个问题，v2ray+ws+tls/v2ray+http2+tls底层都是用http+tls来传输的，那么这样用和直接用http2代理，在流量特征上有什么区别吗？

如果没有区别的话，直接搞个http2代理似乎更简单粗暴有效……

[bash99]

@pingma 因为还得对内无缝，并且还得负载均衡（加上线路坏了就剔除）。求问现在哪个代理支持上游是http2 proxy吗？

[pingma]

@bash99 caddy

[bash99]

@pingma 我知道你说的啥，但是我是希望有
user -> proxy-xxx --http2 --> caddy -> internet
的效果
但是现在支持parent是 https proxy的比如cow，向上仍然用的是 http/1.1，这样连接数很多。

[pingma]

@bash99 caddy支持http2代理，完美达到你要求的效果
关键词：forwardproxy

[bash99]

@pingma 我上面就是指caddy + forwardproxy装了的情况啊
但是又不想让普通用户去折腾 probe_resistance ，因此需要一个本地代理把这些细节都隐藏掉。同时又支持以http/2 连接upstream proxy.

[bash99]

今天换了vmess + tcp，mux下也能重现断流（curl访问 100MB测速并 ctrl+c）。

感觉可能和网速有关，当网速慢（通过v2ray下载Cachefly的100MB测试文件400KB/s左右）时，大文件阻塞了下行通道，而客户端中断导致的错误需要一定时间从v2ray-client传到v2ray-server从而取消下载。

而curl正常close时（用-m 15控制总运行时间），则这个close事件能够快速传递到v2ray-server，从而放弃缓存区的内容。

[DarienRaymond]

Kamino closed and cloned this issue to v2ray/discussion