XTLS
开启mux后下载文件，停止下载xray还在跑流量
开启mux后下载文件，停止下载xray还在跑流量，会持续特别久 像chrome这种有预下载的浏览器，不小心点开大文件下载链接就会跑好多流量
测试图：
客户端配置：
{
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "IP",
"port": 443,
"users": [
{
"id": "UUID",
"alterId": 64
}
]
}
]
},
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {
"allowInsecure": false
},
"wsSettings": {
"path": "/xray"
}
},
"mux": {
"enabled": true,
"concurrency": 8
}
}
至少当前的 Mux 肯定存在历史遗留 BUG，等待更多复现
看了下日志
打开下载链接开始下载
2021/02/03 09:55:27 [Info] [2395700667] proxy/socks: TCP Connect request to tcp:speed.hetzner.de:443
2021/02/03 09:55:27 tcp:127.0.0.1:19103 accepted tcp:speed.hetzner.de:443 [inbound -> outbound]
2021/02/03 09:55:27 [Info] [2395700667] app/dispatcher: taking detour [outbound] for [tcp:speed.hetzner.de:443]
2021/02/03 09:55:27 [Info] [2395700667] common/mux: dispatching request to tcp:speed.hetzner.de:443
中断下载，但是流量还是在持续传输
2021/02/03 09:55:35 [Info] common/mux: failed to write to downstream. closing session 2 > io: read/write on closed pipe
@Walter1Dumais 试试 concurrency 设为 1
设置 concurrency 为 1 后问题改善，不过下载并发数多的时候还是会持续四五秒下载
3个下载：总下载速度30MB/s，总上传5KB/s内 快速中断3个下载：下载速度跳到40MB/s，上传跳到100KB/s（中断下载后，上传一定会有100KB/s），持续4-5秒后恢复正常
试试同时把 policy level 0 的 uplinkOnly 和 downlinkOnly 设为 0
"policy": {
"levels": {
"0": {
"uplinkOnly": 0,
"downlinkOnly": 0
}
}
}
没起作用，还是有5秒左右的流量传输
一些陈年史料供参考 https://github.com/v2ray/v2ray-core/issues/1963 https://github.com/v2ray/v2ray-core/issues/1969 https://github.com/v2ray/v2ray-core/issues/2194 https://github.com/v2ray/v2ray-core/issues/2412 https://github.com/v2fly/v2ray-core/pull/168
用下这个补丁版的看看 https://github.com/v2fly/v2ray-core/suites/2082151777/artifacts/42180503
用下这个补丁版的看看 https://github.com/v2fly/v2ray-core/suites/2082151777/artifacts/42180503
@k79e 你测过了吗？解决了你的问题吗？
正在用 目前测试是出问题啊 不清楚其他正常使用会不会触发. 我是用接收方中断连接那样测试的
https://github.com/v2fly/v2ray-core/issues/672#issuecomment-782601390
我都怀疑用户程序中断是不是会发送rst包还是 fin ack 我不太懂 是不是mux下面他正好忽略了这个也指不定...
@k79e
想的比起来长期测试不如下个测速文件 于是我测试了下 前几个速度下去的是我按的暂停 后面卡一阵的是我按的取消下载
我也是这么测试的，不过我用的是 Xray-core
测试也发现了类似情况 不清楚不下载文件的时候是否容易触发
我测试的场景是 开启了mux，如果你之前也没有开启 mux，那肯定和这处 bug 无关了
我大致的测试流程就是 curl -O 下载个大文件，速度上来了就取消，原先的 mux 会继续下载一段时间。
你可以先编译一份 #285 的 Xray-core 测一下，还不行可以把配置贴上来我们看看。
有迹可循了 curl的中断是发送rst ack 那我凭什么不看下他走隧道内的回环流量 是否本地代理给我回了对应的包呢?
不需要编译啊 github自动编译的 我一直用mux 我的配置你有的 #672上有提到过
我用的691的 还是复现了 不需要285的了吧 我的思路是这样的 反正客户端主动中断连接不是要发送中断的包么? 如果代理没给我处理 比如1个rtt那没返回对应的ack 那就说明 代理程序忽略了应用程序的连接中断请求(rst)
有空我测下去
奇怪了 走了代理之后(v2ray) 通道内没看见程序返回来给rst的响应
也就是说这个rst果然没被确认 而且连接就中断了 后面的包不见了!!! 但是流量还在跑.
更奇怪的是 这个rst还是一个没收到的包 他不应该跨度那么大啊. 而且直连的时候没这个问题. ~rst就是ack的前面的包.~
抓了下发现数据流里面245个包 整个文件是260个包 但是当时是二三百k卡了很久 我的天哪 数据根本就没有 不清楚他在空接什么数据....
下载了530k数据然后中断
这是我用的配置，方便在本地测试，测试方式：
curl -x socks5://127.0.0.1:1080 -O https://dl.google.com/dl/android/aosp/redfin-rd1a.200810.020-factory-c3ea1715.zip
等速度上来之后取消执行
用 8b9c0ae 会发现会流量监控软件里面继续下载，用 #285 就立刻停止了
点击查看配置文件
{
"log": {
"loglevel": "debug"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 12345,
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [
{
"id": "bdbad328-37ab-4e1b-b598-08a2aa1fa3a5"
}
]
}
},
{
"tag": "in",
"listen": "127.0.0.1",
"port": 1080,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": false
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom"
},
{
"tag": "out",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "127.0.0.1",
"port": 12345,
"users": [
{
"encryption": "none",
"id": "bdbad328-37ab-4e1b-b598-08a2aa1fa3a5"
}
]
}
]
},
"mux": {
"enabled": true,
"concurrency": 1
}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": [
"in"
],
"outboundTag": "out"
}
]
}
}
用 https://github.com/XTLS/Xray-core/issues/232#issuecomment-782609391 测试可以跑满带宽，比如你是 Windows，在性能监视器里能看到网络使用率 100%，而在原先代码的情况下，中断满速下载，mux会无法正确处理中断的信号，就会继续满速下载一段时间，#285 修复之后网络使用率就会立刻降到 0%
你可以先试试按照 https://github.com/XTLS/Xray-core/issues/232#issuecomment-782609391 的配置和方式在本地测试，而不是在公网测试 @k79e
@SekiBetu 多收4%就有问题了. 一般测试也就2-3 多个40-50乃是好几倍就太大了. https://github.com/XTLS/Xray-core/issues/232#issuecomment-782609199 如图多了13倍根本就是炸了
@SekiBetu 真会瞎扯 不走隧道时候咋没这问题?
https://user-images.githubusercontent.com/6483602/108593752-894e9900-73b0-11eb-8b54-92226693bf6a.png 那这个怎么解释 就收了500k数据 格子一格就是1MBps 所以他差不多300k卡了很久 这还叫不准? 然后网络都堵塞了 请求也发不出去.
你如果说tcp就几十个字节的overhead 造成了收发流量多收了13倍 这个不算瞎扯 是有理有据 而且配上网速图 证明是有网速 不是统计出错 怎么还不叫瞎扯了?