关于无限接收流量的神秘bug #1969

k79e · 2019-10-26T11:15:13Z

在这里人们以为他是kcp的
我过去的确也碰到但是后来我用ws+web也出问题了. 所以问题根本就不是kcp的.
仿佛这就是dos攻击一样出问题的时候v2无限接收流量一直都不停.
我发现访问pornhub 打开个30min的视频从中间看比较容易触发
虽然不会立刻触发但是等等总能触发.

可以看看视频文件的url然后下载一下看看他大小是多少然后你会发现不知不觉跑了比文件大小大很多倍的流量出来. 或者你会发现这个视频的进度条根本就没有走 v2却一直接收流量.

这问题太奇怪了. 有其他人遇到了么? 我用了广告过滤总不会pornhub检查到之后就专门浪费带宽把.
但是我记得第一次遇到问题的时候我只是http下载了一个视频文件在浏览器打开然后触发了问题.
所以应该不是网站造成的.

2020-01-17 21:00:21
不认为这个跟#1969 (comment) 相关.
我经过了种种测试问题一开始可能表现为本机的v2ray 收发包比率不一致. 接收过大.
目前发现没问题的时候是4% 刚才下载了vultr的文件中途取消了几次虽然没触发但是比率已经变成27%

2020-03-21 15:21:58
果然如某人所说是mux的问题. 我测了win/linux的客户端都有问题. mux关了立刻就好了!

q158073378252010 · 2019-10-26T14:02:30Z

这种问题一直都有。（特别是在进行测速时，单文件下载也有机会出现。不论是否关闭或开启 mux ）
如果链路质量好。甚至可以长达 300s （多数参数为默认配置下）

k79e · 2019-10-26T14:14:50Z

那么看起来就是下载任何比较大的文件就容易触发了.
奇怪啊我下载过比较大的文件但是历史上没出过问题.... 可能是我下载的东西太少了
倒是载入文件容易出问题. 视频文件直接浏览器开那样的.
那应该是不是另存为是另一种方式载入资源那种容易触发.

xqdoo00o · 2019-10-26T16:49:59Z

这个应该是传输控制哪里出问题了吧，有开tcp fastopen么

k79e · 2019-10-27T05:00:23Z

没有tfo
服务器就默认的1
而且我用的win 客户端啊 win哪里有tfo!!!

emiyalee1005 · 2019-10-27T06:38:10Z

h2+caddy+tfo off的经常碰都（网络良好，70m延迟，丢包0，专门在低峰期测）。。。烦死了必须得关掉客户端重启才行，这bug究竟要拖到何年何月才能解决，也是一般再看视屏或者高速刷网页时容易出现

k79e · 2019-10-27T06:45:19Z

哈哈哈哈真是要命的问题呢. 我这边一旦出现问题就不会停那个流量吓死人了.
100多m的视频他跑了七八百都不停要不是我发现了.... 别提了... 整天跑下去了就...
而且根本网页都关闭了他还在跑. 由此得证就算浏览器关闭了他照样自动收流量.

xqdoo00o · 2019-10-27T17:09:57Z

莫非是本地策略的bug
文档

k79e · 2019-10-28T06:08:26Z

问题在连接关闭和连接未关闭的时候都有发生(只需要一个条件触发他然后就跟连接关不关没什么关系了他就那里一直接收流量都不停) 所以可能不是那个策略的问题吧
因为载入视频从头到尾都是保持连接的啊

可能是数据传输过程有什么问题.
因为问题体现在数据接收量和实际不符

k79e · 2019-10-28T10:25:23Z

我两端alterid都用的是32 总不会是这个造成的吧....

edit1 我发现这个问题出现的时候 v2客户端上传下载不成比例而且差别特大. >10%
别提什么50%
今天在不是特严重没有一直接收流量最严重的那个情况我都发现了50%多的差别
用这个办法倒是能检测出来不是特严重发疯但是也有问题的情况.
alterid 0也照样那样. 4遇到了一直收流量 0照样有不匹配有空再测测看去....

qqqaadd · 2019-10-31T05:13:27Z

我曾经试过，用的ws+tls，只要outbounds中有任意一项（无论是freedom,还是vmess）打开了mux，通过freedom访问bili直播间然后关掉，就会几率会触发持续跑流量。

Amaterasu33 · 2019-11-16T09:05:48Z

不光是这个问题，mKCP模式下的有效载荷也非常低，我设置的上传下载带宽都是5MB/s，但是看视频下载文件的时候，任务管理器里看的确跑到50Mb的带宽了，wireshark抓包算算差不多也是这个速率，服务器端也在以这个速度上传，但是实际的下载速度只有几百K。。。几百K啊。。。这效率也太低了点吧。
还有一个更神奇的情况，用mKCP跑speedtest的时候，哪怕在服务器和客户端都设定了带宽限制，关闭拥塞控制，实际的发包速率也是直接吃满带宽的，能跑到150Mb+，但是与此同时speedtest测出来的速度还是低得可怜。。。。

ileeoyo · 2019-12-19T02:30:33Z

不光是这个问题，mKCP模式下的有效载荷也非常低，我设置的上传下载带宽都是5MB/s，但是看视频下载文件的时候，任务管理器里看的确跑到50Mb的带宽了，wireshark抓包算算差不多也是这个速率，服务器端也在以这个速度上传，但是实际的下载速度只有几百K。。。几百K啊。。。这效率也太低了点吧。
还有一个更神奇的情况，用mKCP跑speedtest的时候，哪怕在服务器和客户端都设定了带宽限制，关闭拥塞控制，实际的发包速率也是直接吃满带宽的，能跑到150Mb+，但是与此同时speedtest测出来的速度还是低得可怜。。。。

kcp就是做这个的，多倍发包用流量换取速度。这很正常

k79e · 2019-12-19T05:18:48Z

kcp不是多倍发包正常网络占用不超过5-10%
mkcp估计年久失修无人维护所以就那样了

Amaterasu33 · 2019-12-19T05:20:51Z

不光是这个问题，mKCP模式下的有效载荷也非常低，我设置的上传下载带宽都是5MB/s，但是看视频下载文件的时候，任务管理器里看的确跑到50Mb的带宽了，wireshark抓包算算差不多也是这个速率，服务器端也在以这个速度上传，但是实际的下载速度只有几百K。。。几百K啊。。。这效率也太低了点吧。
还有一个更神奇的情况，用mKCP跑speedtest的时候，哪怕在服务器和客户端都设定了带宽限制，关闭拥塞控制，实际的发包速率也是直接吃满带宽的，能跑到150Mb+，但是与此同时speedtest测出来的速度还是低得可怜。。。。

kcp就是做这个的，多倍发包用流量换取速度。这很正常

这我知道，但是相同的网络环境下用KCPTUN能达到高得多的速度，实际占用的带宽只有2倍而已，播放视频、下载的体验远好于mKCP。

k79e · 2019-12-19T07:38:32Z

当初我月度统计好像连10%都没超过只用了百分之个位数.
你用了2倍是你网络高丢包要不然就是配置不当.
服务器接收的广播包都比kcp多发的包要大.
mkcp有个interval不可以配置太低越低速度越慢还不如直接用100ms最高来的好.

sjdjfcu · 2019-12-21T10:46:57Z

vmess ws tls，shadowrocket开启多路复用后下载vultr,softlayer等的测速文件，停止下载后仍然在下载，或用speedtest单线程，结束测速后仍在下载。断开连接才能停止下载。但是下载其他如google drive，app store的内容是不会出现这种情况

kotori2 · 2019-12-28T19:30:56Z

#1456 maybe related

k79e · 2019-12-29T05:45:49Z

高人那!!!! 果然有些道理
这个无限流量背后还有非无限(不仔细看流量统计根本难以发现!!) 也就是发送数据包大了很多.
但是那个问题好像是kcp only的. 咱其他模式也各种有问题所以问题更严重了呢!!!!

k79e · 2019-12-29T05:52:44Z

@sjdjfcu 你alterid多少? 不是0的话试试0 看看是不是不容易复现了?

sjdjfcu · 2019-12-29T09:46:05Z

只要开启多路复用，用shadowrocket、BifrostV、Kitsunebi都会触发这个bug。不开多路复用我alterid改成0也没触发过，而且shadowrocket也没地方输alterid。跟下载的内容也有关系，下载测速文件、google play的内容就会触发，但下载google drive、app store的内容不会触发。

k79e · 2019-12-29T11:23:29Z

不开多路复用我还真没测过....

k79e · 2019-12-31T07:07:31Z

版本更新了个什么缓冲区的补丁不知道对这个问题是否有影响.
谁要是先测试了过来回复下.

k79e · 2020-01-01T14:51:05Z

4.22测试了下发现很稳都复现不了了. 改天我再测测看.

k79e · 2020-01-02T15:46:04Z

还是有点问题收发从测试前的5% 变成了23%
现在又变成了238%
刚才已经触发无限接收了但是他自己能停下来然而流量已经爆表了.

更高了364%了

sjdjfcu · 2020-01-09T10:17:20Z

4.22.1还是会一直下载

aryMBLec · 2020-01-17T03:34:14Z

是不是用了bbr魔改、锐速这些东西？建议把"downlinkOnly" "uplinkOnly"调成0，加速链接关闭效率。

k79e · 2020-01-17T05:34:41Z

都说了多少遍了我用的ws
而且还是无限传输哪里有5秒那么简单的事情.

sjdjfcu · 2020-01-17T05:50:24Z

改成0开启多路复用已经不会一直下载了，vmess ws tls和普通的vmess都试过了

k79e · 2020-01-17T09:18:24Z

我不认为那个设置跟这个有关正常使用下载几个g有时候也触发不了问题.
更何况新版本更不容易触发了这并不代表问题消失了.
我建议你多看看pornhub 那个最好触发

sjdjfcu · 2020-01-17T10:36:48Z

Pornhub不是最容易触发的，vultr,softlayer等的测速文件和google play的应用是100%会触发的。但是把"downlinkOnly" "uplinkOnly"调成0已经不会触发了。

k79e · 2020-01-17T12:55:31Z

文件下载我这里基本没遇到过问题.

k79e · 2020-01-17T13:04:00Z

奇葩哦我下载了vultr的一开始是比率失调然后也触发了. 怎么这样.
他家的服务器和其他的不一样吗?

k79e · 2020-01-17T13:19:33Z

我关了mux发现下载vultr也变的更不容易触发了.
但是流量比例一直在网上走 ~10% ~14% 反正越来越高了.

sjdjfcu · 2020-02-18T04:57:42Z

我发现ws tls+apache多路复用还是会触发无限下载，"downlinkOnly" "uplinkOnly"调成0也没用。
ws tls+nginx和普通的tcp vmess调成0就不会触发。

k79e · 2020-02-18T05:21:29Z

调成0和禁用内部缓存我都做了 ng也是有问题.
下载digitalocean的测试文件一出现速度就停止他跑了24m才停.(他会连续下载9秒或者更多) 但是暂停下载的话情况好些.
总之测了几下流量比例成了200% 还是有严重的一直接流量问题.

k79e · 2020-03-19T07:21:53Z

谁有空服务器设置下这个看看
"transport": {
"sockopt": {
"mark": 0,
"tcpFastOpen": false,
"tproxy": "off"
}
}
#win10系统的话客户端也设置下?

全局配置里面关闭tfo.
我看的v2说明是默认开启tfo 这是什么意思?
现在发行版系统默认是关闭tfo. 然后v2ray默认开启tfo.
如果(v2)开启了tfo 但是系统配置是关闭tfo的那是什么情况会不会出现诡异问题

我感觉这跟tfo应该没啥关系.... 都没开应该用也用不了

k79e · 2020-03-19T07:31:56Z

行了当我没说

客户端发送SYN数据包，该数据包包含Fast Open选项，且该选项的Cookie为空，这表明客户端请求Fast Open Cookie；

我不认为咱发送的包里面有个tcp选项.....
反正就是根本没开那个功能就是了但是不知道服务器v2ray默认开启tfo 然后服务器默认tfo是没配置就是没开启是什么情况应该不会起作用吧.
//作用肯定不会有但是会不会有bug那就不清楚了.
//我记得tfo配置好像有好多个什么客户端开启tfo 服务端tfo only 双向tfo 乱七八糟的.....
//总之默认应该都是关闭的...

//刚才看了双边都没tfo..... 反正没那个tcp选项, 然后在这个情况下 v2 Sockopt开启了tfo 不知道是啥后果.

lucifer9 · 2020-03-21T01:49:09Z

如果是Linux系统，内核 3.13 以上默认开启 tfo https://en.wikipedia.org/wiki/TCP_Fast_Open#Characteristics

Justsoos · 2020-03-21T03:50:09Z

这个问题由来已久，但经验来说，只出现在windows客户端上
见
#964

k79e · 2020-03-21T07:05:45Z

内核参数看了默认只开客户端的服务器并没有默认那样至少发行版是这样.
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_fastopen_blackhole_timeout_sec = 3600
net.ipv4.tcp_fastopen_key = 00000000-00000000-00000000-00000000

查看了服务器发出的流量即使开启客户端模式 1参数.
没有配置cookie的情况下发送的流量不带有tfo opition.
也就是说要开启那个不管cookie 无论如何都要用tfo的客户端级配置服务器发出请求的时候才会有tfo标记. 那个设置昨天我看了不是1也不是2 他是个3位数.

k79e · 2020-03-21T07:06:25Z

@Justsoos 有空我跑linux测下....

k79e · 2020-03-21T07:11:54Z

@Justsoos linux也有我下了个测速文件 curl停止后发现还继续跑了13秒的流量太可怕了

k79e · 2020-03-21T07:18:03Z

果然和sjdjfcu 说的一模一样
mux关了屁事没有!!!!
真是mux见鬼了

yaleh · 2020-04-01T04:13:01Z

I just reproduced it. It can be walked around by disabling mux. I haven't check the code yet. It sounds that when mux is on, v2ray failed to detect whether the other side has closed the session.

It's not a Windows only bug. I reproduced it with a Linux client.

david9991 · 2020-04-08T03:30:41Z

这个问题由来已久，但经验来说，只出现在windows客户端上
见
#964

macOS 同样问题， Vmess+Ws+Mux，神祕流量。

violarulan · 2020-05-14T10:26:50Z

今儿用 ss 那个 v2ray-plugin 也出现了这种情况，用的 iplc，小流量看看网页不会出问题，开个 speedtest 就来了，测速停止之后流量继续跑了十几秒才停…

客户端浏览器都关了，服务端还能继续维持测速的带宽状态跑个几十秒，消耗流量 100MB 变 1000MB

Arc-2023 · 2020-07-05T13:29:13Z

看来这个问题挺普遍啊
我这里用mkcp协议才会出现这种问题，tcp反而啥问题都没有
比如挂pt的话，人一多就会出现本地带宽拥堵（10m/s，这应该是本地局部网的吞吐瓶颈了），实际数据传输很低（3m/s左右吧）
诡异的是我上传满载（10m/s），但是本地的上传带宽是25M，这时候用宝塔看vpn那儿的带宽下行占用竟然是10m/s，玄学一样的问题啊
之前买的vultr的5美刀的vps，后来发现mtu从1350改成1400在一定情况下有改善，例如IDM下载youtube视频，以及下载bt的时候实际最大带宽从5m/s提升到了8-9m/s，但是很多情况下还是有很严重的浪费
现在改成3.5刀的垃圾服务器之后，改MTU也没用了
没啥解决办法么？
这是目前的MKCP配置
"uplinkCapacity": 100,
"downlinkCapacity": 1000,
"congestion": false,
"writeBufferSize": 50,
"readBufferSize": 50,
"tti": 20,
"mtu": 1400
关闭了sniffing

7.16更新一下
我用kcp是因为不知道为什么,用SSR总是被封tcp
最近改成了tcp_http,依然能满速下载或上传,不会有利用率低的情况了

github-actions · 2020-11-14T01:30:29Z

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

SekiBetu · 2020-12-14T10:21:20Z

v2fly/v2ray-core#168

k79e · 2021-02-20T09:57:24Z

https://github.com/v2fly/v2ray-core/actions/runs/583163291
https://github.com/v2fly/v2ray-core/suites/2082151777/artifacts/42180503 <-download link
有问题的快来测试下这个补丁版!!

k79e mentioned this issue Mar 17, 2020

UPLOAD TEST ERROR，ws模式下，如果用作nginx等反代限制网速后，容易出错 #2340

Closed

github-actions bot added the Stale label Nov 14, 2020

github-actions bot closed this as completed Nov 19, 2020

SekiBetu mentioned this issue Dec 29, 2020

set mux to false by default netchx/netch#486

Merged

SekiBetu mentioned this issue Feb 14, 2021

开启mux后下载文件，停止下载xray还在跑流量 XTLS/Xray-core#232

Closed

Xray9 mentioned this issue Feb 20, 2021

fix: implement Close of pipe.Reader v2fly/v2ray-core#691

Closed

关于无限接收流量的神秘bug #1969

关于无限接收流量的神秘bug #1969

Comments

k79e commented Oct 26, 2019 • edited Loading

q158073378252010 commented Oct 26, 2019 • edited Loading

k79e commented Oct 26, 2019 • edited Loading

xqdoo00o commented Oct 26, 2019 • edited Loading

k79e commented Oct 27, 2019 • edited Loading

emiyalee1005 commented Oct 27, 2019

k79e commented Oct 27, 2019

xqdoo00o commented Oct 27, 2019 • edited Loading

k79e commented Oct 28, 2019 • edited Loading

k79e commented Oct 28, 2019 • edited Loading

qqqaadd commented Oct 31, 2019

Amaterasu33 commented Nov 16, 2019

ileeoyo commented Dec 19, 2019

k79e commented Dec 19, 2019 • edited Loading

Amaterasu33 commented Dec 19, 2019

k79e commented Dec 19, 2019

sjdjfcu commented Dec 21, 2019 • edited Loading

kotori2 commented Dec 28, 2019

k79e commented Dec 29, 2019 • edited Loading

k79e commented Dec 29, 2019

sjdjfcu commented Dec 29, 2019 • edited Loading

k79e commented Dec 29, 2019

k79e commented Dec 31, 2019

k79e commented Jan 1, 2020

k79e commented Jan 2, 2020 • edited Loading

sjdjfcu commented Jan 9, 2020

aryMBLec commented Jan 17, 2020

k79e commented Jan 17, 2020

sjdjfcu commented Jan 17, 2020

k79e commented Jan 17, 2020 • edited Loading

sjdjfcu commented Jan 17, 2020

k79e commented Jan 17, 2020

k79e commented Jan 17, 2020 • edited Loading

k79e commented Jan 17, 2020

sjdjfcu commented Feb 18, 2020

k79e commented Feb 18, 2020 • edited Loading

k79e commented Mar 19, 2020

k79e commented Mar 19, 2020 • edited Loading

lucifer9 commented Mar 21, 2020 • edited Loading

Justsoos commented Mar 21, 2020

k79e commented Mar 21, 2020 • edited Loading

k79e commented Mar 21, 2020

k79e commented Mar 21, 2020

k79e commented Mar 21, 2020

yaleh commented Apr 1, 2020 • edited Loading

david9991 commented Apr 8, 2020

violarulan commented May 14, 2020 • edited Loading

Arc-2023 commented Jul 5, 2020 • edited Loading

github-actions bot commented Nov 14, 2020

SekiBetu commented Dec 14, 2020

k79e commented Feb 20, 2021

k79e commented Oct 26, 2019 •

edited

Loading

q158073378252010 commented Oct 26, 2019 •

edited

Loading

k79e commented Oct 26, 2019 •

edited

Loading

xqdoo00o commented Oct 26, 2019 •

edited

Loading

k79e commented Oct 27, 2019 •

edited

Loading

xqdoo00o commented Oct 27, 2019 •

edited

Loading

k79e commented Oct 28, 2019 •

edited

Loading

k79e commented Oct 28, 2019 •

edited

Loading

k79e commented Dec 19, 2019 •

edited

Loading

sjdjfcu commented Dec 21, 2019 •

edited

Loading

k79e commented Dec 29, 2019 •

edited

Loading

sjdjfcu commented Dec 29, 2019 •

edited

Loading

k79e commented Jan 2, 2020 •

edited

Loading

k79e commented Jan 17, 2020 •

edited

Loading

k79e commented Jan 17, 2020 •

edited

Loading

k79e commented Feb 18, 2020 •

edited

Loading

k79e commented Mar 19, 2020 •

edited

Loading

lucifer9 commented Mar 21, 2020 •

edited

Loading

k79e commented Mar 21, 2020 •

edited

Loading

yaleh commented Apr 1, 2020 •

edited

Loading

violarulan commented May 14, 2020 •

edited

Loading

Arc-2023 commented Jul 5, 2020 •

edited

Loading