downlinkCapacity设为2试试
删除了kcp的额外设置也会断流,我2台VPS不同线路, 都存在这个问题,今天测试了1.17.1发现也会断流, wget下一半就断流了,kcp+ss就不断流.
刚在内网用2台电脑间传输测试没发现断流.
初步认为是内部 race condition 导致的数据错乱,不过我暂时还不能重现。有待进一步调查。
要不我给你个配置文件 你去试试? 新买了台VPS做测试
如果你能分享一下 SSH 登录信息就更好了。不过我无法保证测试的时间,可能到周末才有空。
我邮件给你吧, 注意查收
另外还有个bug 服务器 配置文件检查无错误但是无法启动 命令敲完出现
V2Ray v1.18.2 (New Order) 20160704
An unified platform for anti-censorship.
进程就结束了
另外alterId的数量跟连接速度有关系么?
正在试用你的机器,你的 detour1 所对应的 inbound 的 protocol 没写,我帮你补上了。至于为什么没有 log 这一点很奇怪,在 mac os 上是有的。
alterId 和速度没关系,alterId 的数量和内存有关系,但如果不大于 100,应该观察不到内存的变化。
今天从shadowsocks-go + kcptun 换到 v2ray,开了kcp,结果几个小时后还是换回去了,原因:
以上不知道是我的设置有问题还是网络有问题?非专业人士不太会判断。
另外有个问题,动态端口是不是不能和shadowsocks 同时启用?
@Rememberli V2Ray 版本? 1.18.2?
断流问题依然存在..

vmess+kcptun的客户端就不断流

会不会是这个原因引起的?
我昨天没仔细看,你的 VPS 上是开启了动态端口是么?上述断流也是发生在使用动态端口的时候?
@v2ray
待机就是关掉浏览器电脑不用,大概十几分钟就不行了。
我把我的配置文件email发给你,你有空帮忙仔细看看有没有什么问题好了,另外我试了增加动态端口的配置,结果失败,可以一并告诉我怎么改动态端口,谢谢!
我好像应该另开一个issue:P
对启用了动态端口,我主要都在用动态端口。 静态的kcp刚测试过没问题,动态端口的kcp有问题,无论同时开启几个端口,都会断流。 那台机器是专门给你测试的,我一般很少用
还是关于内存的问题
版本:1.19.2 kcp 静态端口 alterId:100
使用方式:bittorrent 浏览器youtube wget杂七杂八的下载流量都走vmess 流量一般都在2MB/s
我在服务器上挂客户端一段时候后进程的内存占用会越来越高 。
基本2到3天就到500-600MB了
有时候传输300MB的东西内存涨幅在100MB左右,大概用了400个连接 。
这服务器还跑了2个数据库在,内存硬盘io都比较吃紧,不想频繁重启客户端。
能把整体占用控制在100MB内么? 整体50MB就能在路由器上部署了。
go语言难道也是不会释放内存么? 另外动态端口的kcp断流有修复么?
内存释放的问题大致是这样的,Go 的垃圾回收并不是用完立即回收的,而是有某种触发机制。V2Ray 的某些做法刚好让 Go 认为这些内存之后还需要继续使用,就没有释放。在服务器端 V2Ray 没办法判断之后还有没有大量的并发连接,于是就不能及时地释放内存。
顺便我想问一下,你的 400 个连接是并发的还是有先后的?每个连接的速度都有 2MB/s?
应该是并发的, 一起2MB/s
等下晚上测试下降低下alterid数量测试下1.20

最新版动态端口的kcp还是断流
有必要去学学go了
感觉端口的变化并不能降低被识别特征的概率..
接着测试内存问题 alterId:30 缓存配置默认
bt下了3个新番. 高并发导致内存上升至320M

然后看youtube wget下点东西后内存占用下降到170M

目前148M

我是说把动态端口关掉,在动态端口刷新的时候,一定会造成断流的。如果你要下载大文件,可以配置一个单独的连接到主端口来下载,然后其它的请求继续使用动态端口。
嗯 明白了
做一个反馈。
我的服务器端使用的是1.21.1,在使用动态端口的情况下(kcp连接),刚配置好时没有问题,但是如果长时间空置(比如人离开电脑一个小时,或者关机一个晚上),再次使用时就无法连接,此时无论是重启服务器中的v2ray还是重启服务器,甚至将动态端口重新改为静态端口,都连接不上(这里指1.21和1.21.1两个版本的client)。检查server端,发现使用动态端口时一直重复警告信息“[Warning]Point: Unable to find an inbound handler with tag: detour”,而client端在等待较长时间(如5min)后,有一定概率出现警告"VMess|outbound: Failed to read response from tcp:xxx.xxxx.xxx:443: EOF"或"VMess|outbound: Failed to read response from udp:8.8.4.4:53: EOF"。国外网站一直不能连通。
可是奇怪的是,如果我使用1.18.2版本的client(版本都是windows 64位,使用win7 64位系统),此时能够连通国外网站,但是相比之前,速度慢许多。
最新的结果是,在这样的情况下,能使用的最新客户端是1.19.2,速度比1.18.2快不少。
应该已经修复。
发现一种可能的断流原因
服务端配置的时候没有给 user 配置 security,这时应该默认的 security 为 auto,按照文档描述运行框架为amd64和s390x时为aes-128-gcm加密方式,其他情况则为chacha20-poly1305加密方式
客户端使用 v2rayx,默认的 security 为 aes-128-cfb
其他参数配置正确的情况下,如果客户端 security 配置为 aes-128-cfb 时,可以正常连接使用,但是下载大文件会断流;客户端 security 修改为 aes-128-gcm 则一切正常。
Most helpful comment
做一个反馈。
我的服务器端使用的是1.21.1,在使用动态端口的情况下(kcp连接),刚配置好时没有问题,但是如果长时间空置(比如人离开电脑一个小时,或者关机一个晚上),再次使用时就无法连接,此时无论是重启服务器中的v2ray还是重启服务器,甚至将动态端口重新改为静态端口,都连接不上(这里指1.21和1.21.1两个版本的client)。检查server端,发现使用动态端口时一直重复警告信息“[Warning]Point: Unable to find an inbound handler with tag: detour”,而client端在等待较长时间(如5min)后,有一定概率出现警告"VMess|outbound: Failed to read response from tcp:xxx.xxxx.xxx:443: EOF"或"VMess|outbound: Failed to read response from udp:8.8.4.4:53: EOF"。国外网站一直不能连通。
可是奇怪的是,如果我使用1.18.2版本的client(版本都是windows 64位,使用win7 64位系统),此时能够连通国外网站,但是相比之前,速度慢许多。
最新的结果是,在这样的情况下,能使用的最新客户端是1.19.2,速度比1.18.2快不少。