什么时候能解决cpu99+ 打游戏延迟999ms的问题啊

[1265578519]

感觉这个问题都没人关注，很多人都有提出过，我在几年前也说过，，，3年过去了，依旧没有开发者来修复

[1265578519]

包括这些问题，其实都是这个BUG引起的，其实而不是核心无法利用多核的问题，当然，，v2现在确实是单核心，能多核心运算更好，特别是vps服务器上进行 #2548 v2ray/discussion#558

[Kylejustknows]

我估计，开发的朋友，现在都不知道这个Bug出在什么地方，不知道从什么地方开始修。

因为代码看起来没问题；这个问题又挺难复现的。（无法通过访问某个特定网站之类的方法让它准确发生；我服务器上的v2ray进程有时一跑就是几个月不重启，几年了，至今也没见这个问题发生过一次）

我不是否认说没有这个Bug，只是说它之影响一部分特定用户，并且似乎只发生在某些特定平台上，给我感觉更像是针对操作系统平台的“编译器”有某些隐藏的bug，而不像是V2Ray的代码有Bug。

[1265578519]

这个问题可以轻易百分百复现。。是属于必现。要复现随时都可以进行

[Kylejustknows]

这个问题可以轻易百分百复现。。是属于必现。要复现随时都可以进行

这也是奇怪的地方之一。 你知道v2ray是有人用来开机场的。一个机场服务器连接几百人在用，这几百人连接服务器干啥玩意的都有，却没见机场的进程炸过。

但无论如何，我等会照你另一个帖子写的，开Netch连接CoD Infinite Warfare (我只有这个)玩一会看看（或者你能再给我列几个其它容易炸的游戏）。进程有没有炸我会告诉你，至少我们这样能知道，是属于“某些系统环境下才会出现的问题”还是属于“V2Ray本身处理某些数据流的问题”

[zhj9709]

客户端使用socks5 udp也会出现cpu占用高的情况

[1265578519]

@Kylejustknows pubg，这些fps的游戏都百分百必现 @zhj9709 对的。。v2ray提供的s5也是一样会出问题，只要是经过了v2ray就有这毛病

[xqzr]

所以 我直接换$$了

[1265578519]

等个写代码的大佬提交下代码修复这个毛病

[Kylejustknows]

@Kylejustknows pubg，这些fps的游戏都百分百必现 @zhj9709 对的。。v2ray提供的s5也是一样会出问题，只要是经过了v2ray就有这毛病

我刚刚，顶着200+的延迟（我的服务器允许UDP但不是为游戏优化的）玩了一局COD，一局CSGO，一局Dota2。总共大约2小时。
用的是Netch的进程白名单模式。游戏期间只要死了，我就切出来看一下CPU。

V2ray的进程CPU占用率一直在0%，偶尔跳到2%，但从没超过2%

然后为了测试，用iperf超最大限速收发UDP包（特意制作大量UDP包和大量丢包），在收发UDP包跑满网速的情况下，V2ray的CPU能偶尔才达到5%。

所以我这边情况（win10最新版, i3CPU，Netch+UDP+V2ray），死活就是无法复现V2ray占满CPU的BUG（我不是说没有这个Bug，而是针对v2ray总用户数有几百万的情况下，这个Bug真的可能只有少数用户遇到。开发的朋友也一直不回应这个Bug，估计这个Bug他们也无法复现，就忽视掉了）

能不能看看，你们的机子，是不是有什么对网络流量有审核的部件，大家汇报一下看看有没有共同点？（360有网速监控，QQ管家，xx管家等等都有软件网络流量监控、多数杀毒软件和防火墙对每个软件的网络流量也都有即时扫描和审计，我怀疑某个流量监控或流量统计软件、驱动和V2Ray冲突了）

PS: 顺便说下，Netch里带的Netfilter SDK+ Redirector真是个好东西啊，让windows实现了几乎完美的透明代理，连底层的UWP和系统进程都代理了！我这一试，就直接把用了多年的Proxifier给扔了。

[1265578519]

在Netch群里，和各种身边朋友，都能轻松正常复现这个问题，而且是百分百复现。不存在无法复现的可能性。包括服务端也能轻松复现相同的问题，不仅仅是客户端
包括Netch开发者，也说了，不要用v2ray来打游戏，甚至说以后要去掉v2ray，免得有人来问cpu延迟这种问题。
至少用v2ray的所有人，都有相同的毛病，是不是你测试有问题？毕竟这是百分百能复现的 @Kylejustknows 随便搜索了下聊天记录，还有大量的聊天记录你可以进Netch群去看，都有讨论过

[zhj9709]

@Kylejustknows pubg，这些fps的游戏都百分百必现 @zhj9709 对的。。v2ray提供的s5也是一样会出问题，只要是经过了v2ray就有这毛病

我刚刚，顶着200+的延迟（我的服务器允许UDP但不是为游戏优化的）玩了一局COD，一局CSGO，一局Dota2。总共大约2小时。
用的是Netch的进程白名单模式。游戏期间只要死了，我就切出来看一下CPU。

V2ray的进程CPU占用率一直在0%，偶尔跳到2%，但从没超过2%

然后为了测试，用iperf超最大限速收发UDP包（特意制作大量UDP包和大量丢包），在收发UDP包跑满网速的情况下，V2ray的CPU能偶尔才达到5%。

所以我这边情况（win10最新版, i3CPU，Netch+UDP+V2ray），死活就是无法复现V2ray占满CPU的BUG（我不是说没有这个Bug，而是针对v2ray总用户数有几百万的情况下，这个Bug真的可能只有少数用户遇到。开发的朋友也一直不回应这个Bug，估计这个Bug他们也无法复现，就忽视掉了）

能不能看看，你们的机子，是不是有什么对网络流量有审核的部件，大家汇报一下看看有没有共同点？（360有网速监控，QQ管家，xx管家等等都有软件网络流量监控、多数杀毒软件和防火墙对每个软件的网络流量也都有即时扫描和审计，我怀疑某个流量监控或流量统计软件、驱动和V2Ray冲突了）

PS: 顺便说下，Netch里带的Netfilter SDK+ Redirector真是个好东西啊，让windows实现了几乎完美的透明代理，连底层的UWP和系统进程都代理了！我这一试，就直接把用了多年的Proxifier给扔了。

我安卓上测试了，不管是用脚本，还是用v2rayNG，用到socks udp时都会出现cpu占用高的问题，我还让人也测试了，同样的问题。#2427

[zhj9709]

@Kylejustknows pubg，这些fps的游戏都百分百必现 @zhj9709 对的。。v2ray提供的s5也是一样会出问题，只要是经过了v2ray就有这毛病

我刚刚，顶着200+的延迟（我的服务器允许UDP但不是为游戏优化的）玩了一局COD，一局CSGO，一局Dota2。总共大约2小时。
用的是Netch的进程白名单模式。游戏期间只要死了，我就切出来看一下CPU。
V2ray的进程CPU占用率一直在0%，偶尔跳到2%，但从没超过2%
然后为了测试，用iperf超最大限速收发UDP包（特意制作大量UDP包和大量丢包），在收发UDP包跑满网速的情况下，V2ray的CPU能偶尔才达到5%。
所以我这边情况（win10最新版, i3CPU，Netch+UDP+V2ray），死活就是无法复现V2ray占满CPU的BUG（我不是说没有这个Bug，而是针对v2ray总用户数有几百万的情况下，这个Bug真的可能只有少数用户遇到。开发的朋友也一直不回应这个Bug，估计这个Bug他们也无法复现，就忽视掉了）
能不能看看，你们的机子，是不是有什么对网络流量有审核的部件，大家汇报一下看看有没有共同点？（360有网速监控，QQ管家，xx管家等等都有软件网络流量监控、多数杀毒软件和防火墙对每个软件的网络流量也都有即时扫描和审计，我怀疑某个流量监控或流量统计软件、驱动和V2Ray冲突了）
PS: 顺便说下，Netch里带的Netfilter SDK+ Redirector真是个好东西啊，让windows实现了几乎完美的透明代理，连底层的UWP和系统进程都代理了！我这一试，就直接把用了多年的Proxifier给扔了。

我安卓上测试了，不管是用脚本，还是用v2rayNG，用到socks udp时都会出现cpu占用高的问题，我还让人也测试了，同样的问题。#2427

而且我那个issue上有个PR Wanted的标签，估计还要等别人提交pr请求吧

[Kylejustknows]

在Netch群里，和各种身边朋友，都能轻松正常复现这个问题，而且是百分百复现。不存在无法复现的可能性。包括服务端也能轻松复现相同的问题，不仅仅是客户端

我不是说没有这个问题，但因为回音壁效应，和你共鸣的都是有这个问题的。但也许有更多的人，没有这个问题所以不回复你，你也不知道。

比如说我，其实很久之前就看到issues里有这个问题，但是在我自己的”小机场“上和各个客户端上，这个问题从来没有出现过，所以就从来没回复、没关心过这个问题。

而且我刚刚玩了几局被骂得很惨的游戏，大致证实了我的个人电脑上这个问题不存在（因为据你说，这个问题应该游戏开始后很快就复现；我差不多玩了两个小时没有出现）

我漏掉两个细节：
1，因为我的v2ray有特殊设置，所以我是自己跑v2ray，然后netch用socks5连接到本地的v2ray端口； 而不是使用netch内置的v2ray; 你那里能否试试？
2, 我突然想起我的路由器有设置每台机器的UDP发包限制，所以我上面测的数据可能不准确，等会我把QoS去掉后再试试UDP发包。

[1265578519]

1.不管是直接使用netch内置的v2ray 还是netch通过127.0.0.1:10808 s5模式连接到v2rayn客户端，都会存在相同的问题，包括之前群里面有人不信有毛病，他们一测cod，也出现相同的问题了，很明显在fps游戏中，很容易出现这种情况

[Kylejustknows]

1.不管是直接使用netch内置的v2ray 还是netch通过127.0.0.1:10808 s5模式连接到v2rayn客户端，都会存在相同的问题，包括之前群里面有人不信有毛病，他们一测cod，也出现相同的问题了，很明显在fps游戏中，很容易出现这种情况

行，我再跑一局COD试试看。
另，UDP转发可能是有问题。我刚刚解除了QoS限制，测试海量发UDP包，V2Ray短暂地跳到30%CPU，然后就冰冻住了，直到连接超时。不一定和你的游戏是同一个Bug，但我觉得V2ray的UDP部分应该有一些不显著的Bug。

[1265578519]

跳到30%CPU

你是4核心的吗？4核心利用一个核心的话，大约就在25%左右浮动，可能是同一个问题引起

[Kylejustknows]

跳到30%CPU

你是4核心的吗？4核心利用一个核心的话，大约就在25%左右浮动，可能是同一个问题引起

所见略同。当它跳到30%的时候，任务管理器正好在记录中，我赶紧看了一眼，那30%的峰值，是平均分配到4个核心。（电脑CPU核心4个逻辑核心都在30%左右）但V2ray的CPU使用和连接方式有关

但经过一波测试，我感觉我找到一些出错逻辑：

1，UDP瞬间发包数，当我把发包数限制为10的时候，测试总能通过。默认值发包（每秒120个UDP包左右）都产生高CPU然后失败了。（UDP数据包数量超过V2ray的vmess协议能瞬间处理的数量？）
2， 只要失败了，下面的所有UDP测试都数据挂起；重启V2ray后又能再联通。（但是在挂起的期间，我的CPU并没有持续飙高，就是不传输UDP数据了，V2ray也不显示任何错误）

[1265578519]

任务管理器正好在记录中，我赶紧看了一眼，那30%的峰值，是平均分配到4个核心。（电脑CPU核心4个逻辑核心都在30%左右）

这个是Windows 10的线程优化。实际上还是单核心运行的。解决这个问题的终点不是让他利用更多的核心，而是想办法解决问题所在，让其不占用CPU，对比下ss-lbev，人家占用不超过0.5%的cpu，内存也才5MB

[1265578519]

@Kylejustknows 你会写代码吗，要不要提交写修复这毛病啊

[1265578519]

每天都有不同的人来说v2延迟问题。

[hyxxsfwy]

把客户端换成 Clash 试试看

[1265578519]

Clash是gui还是？用的不是v2ray核心？

[hyxxsfwy]

Clash是gui还是？用的不是v2ray核心？

Clash 用的是自己的核心，Clash Core.
Clash for Windows 也支持用 OpeVPN 的 TAP 驱动实现全局 VPN.

[1265578519]

https://github.com/Dreamacro/clash/releases 这个吗？我看了下介绍，用的是v2ray的核心，不是他们自己开发的

[hyxxsfwy]

https://github.com/Dreamacro/clash/releases 这个吗？我看了下介绍，用的是v2ray的核心，不是他们自己开发的

你可以选择看看代码，或者装上客户端亲自试一试，而不是只看 Readme 里的鸣谢。

[Lightmani]

在我的Win10Pro+Netch 1.4.9的试验下,一局10分钟的CSGO,游戏中显示的延迟大概在62-70之间波动,和我节点本身的延迟并没有太大区别.

由于我没有COD,所以无法测试.但是我在GTAV,CSGO,彩虹六号中也从未遇到过CPU占用满的问题．
只有在彩虹六号里延迟比较高到了120ms....可能是因为我的节点比较垃圾吧...

所以我觉得这个问题是CoD的个例,就我本人的游戏体验来看,从未遇到过类似情况

[Kylejustknows]

在我的Win10Pro+Netch 1.4.9的试验下,一局10分钟的CSGO,游戏中显示的延迟大概在62-70之间波动,和我节点本身的延迟并没有太大区别.

由于我没有COD,所以无法测试.但是我在GTAV,CSGO,彩虹六号中也从未遇到过CPU占用满的问题．
只有在彩虹六号里延迟比较高到了120ms....可能是因为我的节点比较垃圾吧...

所以我觉得这个问题是CoD的个例,就我本人的游戏体验来看,从未遇到过类似情况

据我现在的经验，它和发包率有一些关系。Steam平台的游戏以较低的30pps速度发UDP包在config文件内可调，PUBG和CoD没有公开数据，但我估计为了体验可能用了超高的发包率。我自以为我的电脑没有这个bug，但当我用测试软件每秒100个UDP包发送时，我的V2ray也假死了。

问题不在于该不该玩Cod或者用Netch，关键在于，一个代理软件，你对它发送好的、坏的、大的、小的、扭曲的、合法不合法。。。的各种数据包，它都应该能合理地处理（该转发的转发，该抛弃的抛弃）。而不应该遇到自己不喜欢的数据包就立刻死给你看。

[Kylejustknows]

Clash是gui还是？用的不是v2ray核心？

Clash 用的是自己的核心，Clash Core.
Clash for Windows 也支持用 OpeVPN 的 TAP 驱动实现全局 VPN.

应该是没用的。我这两天有空时在测试和研究怎样准确地触发这个Bug。 Netfilter来转发UDP或者SSTAP全局VPN都会触发这个Bug都试过。这个Bug和UDP数据流的“内容”有关，而与你用什么软件、什么方法把数据传给V2ray无关。

[ghost]

(声明：本人萌新+小白，若有纰漏，还望各位大佬海涵。）
这是一个socks中对于UDP连接的一个bug：
(v2ray-core/proxy/socks/server.go line213-245)

for { 
	mpayload, err := reader.ReadMultiBuffer() 
	... ...
	for _, payload := range mpayload { 
		... ...
		if inbound := session.InboundFromContext(ctx); inbound != nil && inbound.Source.IsValid() { 
			ctx = log.ContextWithAccessMessage(ctx,... ...) 
		} 
		ctx = protocol.ContextWithRequestHeader(ctx, request) 
		... ...
	}
} 

首先，v2ray会对每一个socks连接建立一个Context(ctx)，并对其添加几个Value（例如ID）:

v2ray-core/app/proxyman/inbound/worker.go

Line 289 in f9935d0

ctx = session.ContextWithID(ctx, sid)

对于socksClient发来的每一个UDP包，v2ray都会对ctx进行log.ContextWithAccessMessage()与protocol.ContextWithRequestHeader()操作。这两个函数本质上是Context.WithValue()。
Context.WithValue()相关代码：

func WithValue(parent Context, key, val interface{}) Context {
	if key == nil {
		panic("nil key")
	}
	if !reflectlite.TypeOf(key).Comparable() {
		panic("key is not comparable")
	}
	return &valueCtx{parent, key, val}
}

当socksClient发来的UDP包很多时，存放ID的valueCtx就是当前ctx的子n代ctx，这时从ctx中获取ID对应的Value就会极为困难：

func (c *valueCtx) Value(key interface{}) interface{} {
	if c.key == key {
		return c.val
	}
	return c.Context.Value(key)
}

当ctx.Value()被调用时，ctx会疯狂调用子代的ctx.Value()，产生巨大的CPU消耗；同时，大量子代ctx占用大量的内存，与 @1265578519 的issue中的描述类似。

[1265578519]

@JimHan75d8c5 感谢分析，如果是这个问题的话，不知道好修不？

[ghost]

应该挺好修的，在 log.ContextWithAccessMessage()与protocol.ContextWithRequestHeader()里面加个判断就行🙃
🙃🙃🙃

[1265578519]

@kslr 这位开发者，麻烦进来帮看看，上面有人发了修复方案

[AmazingDM]

[lylyo]

在我的Win10Pro+Netch 1.4.9的试验下,一局10分钟的CSGO,游戏中显示的延迟大概在62-70之间波动,和我节点本身的延迟并没有太大区别.
由于我没有COD,所以无法测试.但是我在GTAV,CSGO,彩虹六号中也从未遇到过CPU占用满的问题．
只有在彩虹六号里延迟比较高到了120ms....可能是因为我的节点比较垃圾吧...
所以我觉得这个问题是CoD的个例,就我本人的游戏体验来看,从未遇到过类似情况

据我现在的经验，它和发包率有一些关系。Steam平台的游戏以较低的30pps速度发UDP包在config文件内可调，PUBG和CoD没有公开数据，但我估计为了体验可能用了超高的发包率。我自以为我的电脑没有这个bug，但当我用测试软件每秒100个UDP包发送时，我的V2ray也假死了。

问题不在于该不该玩Cod或者用Netch，关键在于，一个代理软件，你对它发送好的、坏的、大的、小的、扭曲的、合法不合法。。。的各种数据包，它都应该能合理地处理（该转发的转发，该抛弃的抛弃）。而不应该遇到自己不喜欢的数据包就立刻死给你看。

请问用的什么测试软件

[Kylejustknows]

在我的Win10Pro+Netch 1.4.9的试验下,一局10分钟的CSGO,游戏中显示的延迟大概在62-70之间波动,和我节点本身的延迟并没有太大区别.
由于我没有COD,所以无法测试.但是我在GTAV,CSGO,彩虹六号中也从未遇到过CPU占用满的问题．
只有在彩虹六号里延迟比较高到了120ms....可能是因为我的节点比较垃圾吧...
所以我觉得这个问题是CoD的个例,就我本人的游戏体验来看,从未遇到过类似情况

据我现在的经验，它和发包率有一些关系。Steam平台的游戏以较低的30pps速度发UDP包在config文件内可调，PUBG和CoD没有公开数据，但我估计为了体验可能用了超高的发包率。我自以为我的电脑没有这个bug，但当我用测试软件每秒100个UDP包发送时，我的V2ray也假死了。
问题不在于该不该玩Cod或者用Netch，关键在于，一个代理软件，你对它发送好的、坏的、大的、小的、扭曲的、合法不合法。。。的各种数据包，它都应该能合理地处理（该转发的转发，该抛弃的抛弃）。而不应该遇到自己不喜欢的数据包就立刻死给你看。

请问用的什么测试软件

iperf3 , 自定义参数 -u 打开UDP测试；-l 每个UDP包大小（数字后要加上K或者多少M）;-b每秒传输数据量（也要数字加K）； 这两个参数组合，就可以设计出各种大小、每秒各种数量的测试包。
或者用-k参数加个数字，意思是一次性送出多少个包。

测试时一旦遇到假死数据中断，服务器那边就会等很久很久很久才会放弃，所以记得远程连上服务器随时重启服务端。

[lylyo]

在我的Win10Pro+Netch 1.4.9的试验下,一局10分钟的CSGO,游戏中显示的延迟大概在62-70之间波动,和我节点本身的延迟并没有太大区别.
由于我没有COD,所以无法测试.但是我在GTAV,CSGO,彩虹六号中也从未遇到过CPU占用满的问题．
只有在彩虹六号里延迟比较高到了120ms....可能是因为我的节点比较垃圾吧...
所以我觉得这个问题是CoD的个例,就我本人的游戏体验来看,从未遇到过类似情况

据我现在的经验，它和发包率有一些关系。Steam平台的游戏以较低的30pps速度发UDP包在config文件内可调，PUBG和CoD没有公开数据，但我估计为了体验可能用了超高的发包率。我自以为我的电脑没有这个bug，但当我用测试软件每秒100个UDP包发送时，我的V2ray也假死了。
问题不在于该不该玩Cod或者用Netch，关键在于，一个代理软件，你对它发送好的、坏的、大的、小的、扭曲的、合法不合法。。。的各种数据包，它都应该能合理地处理（该转发的转发，该抛弃的抛弃）。而不应该遇到自己不喜欢的数据包就立刻死给你看。

请问用的什么测试软件

iperf3 , 自定义参数 -u 打开UDP测试；-l 每个UDP包大小（数字后要加上K或者多少M）;-b每秒传输数据量（也要数字加K）； 这两个参数组合，就可以设计出各种大小、每秒各种数量的测试包。
或者用-k参数加个数字，意思是一次性送出多少个包。

测试时一旦遇到假死数据中断，服务器那边就会等很久很久很久才会放弃，所以记得远程连上服务器随时重启服务端。

好的，感谢提示。

[xiaokangwang]

(声明：本人萌新+小白，若有纰漏，还望各位大佬海涵。）
这是一个socks中对于UDP连接的一个bug：
(v2ray-core/proxy/socks/server.go line213-245)

for { 
	mpayload, err := reader.ReadMultiBuffer() 
	... ...
	for _, payload := range mpayload { 
		... ...
		if inbound := session.InboundFromContext(ctx); inbound != nil && inbound.Source.IsValid() { 
			ctx = log.ContextWithAccessMessage(ctx,... ...) 
		} 
		ctx = protocol.ContextWithRequestHeader(ctx, request) 
		... ...
	}
} 

首先，v2ray会对每一个socks连接建立一个Context(ctx)，并对其添加几个Value（例如ID）:

v2ray-core/app/proxyman/inbound/worker.go

Line 289 in f9935d0

ctx = session.ContextWithID(ctx, sid)

对于socksClient发来的每一个UDP包，v2ray都会对ctx进行log.ContextWithAccessMessage()与protocol.ContextWithRequestHeader()操作。这两个函数本质上是Context.WithValue()。
Context.WithValue()相关代码：

func WithValue(parent Context, key, val interface{}) Context {
	if key == nil {
		panic("nil key")
	}
	if !reflectlite.TypeOf(key).Comparable() {
		panic("key is not comparable")
	}
	return &valueCtx{parent, key, val}
}

当socksClient发来的UDP包很多时，存放ID的valueCtx就是当前ctx的子n代ctx，这时从ctx中获取ID对应的Value就会极为困难：

func (c *valueCtx) Value(key interface{}) interface{} {
	if c.key == key {
		return c.val
	}
	return c.Context.Value(key)
}

当ctx.Value()被调用时，ctx会疯狂调用子代的ctx.Value()，产生巨大的CPU消耗；同时，大量子代ctx占用大量的内存，与 @1265578519 的issue中的描述类似。

我尝试修修看看
v2fly/v2ray-core@73616ab

[zhj9709]

(声明：本人萌新+小白，若有纰漏，还望各位大佬海涵。）
这是一个socks中对于UDP连接的一个bug：
(v2ray-core/proxy/socks/server.go line213-245)

for { 
	mpayload, err := reader.ReadMultiBuffer() 
	... ...
	for _, payload := range mpayload { 
		... ...
		if inbound := session.InboundFromContext(ctx); inbound != nil && inbound.Source.IsValid() { 
			ctx = log.ContextWithAccessMessage(ctx,... ...) 
		} 
		ctx = protocol.ContextWithRequestHeader(ctx, request) 
		... ...
	}
} 

首先，v2ray会对每一个socks连接建立一个Context(ctx)，并对其添加几个Value（例如ID）:

v2ray-core/app/proxyman/inbound/worker.go

Line 289 in f9935d0

ctx = session.ContextWithID(ctx, sid)

对于socksClient发来的每一个UDP包，v2ray都会对ctx进行log.ContextWithAccessMessage()与protocol.ContextWithRequestHeader()操作。这两个函数本质上是Context.WithValue()。
Context.WithValue()相关代码：

func WithValue(parent Context, key, val interface{}) Context {
	if key == nil {
		panic("nil key")
	}
	if !reflectlite.TypeOf(key).Comparable() {
		panic("key is not comparable")
	}
	return &valueCtx{parent, key, val}
}

当socksClient发来的UDP包很多时，存放ID的valueCtx就是当前ctx的子n代ctx，这时从ctx中获取ID对应的Value就会极为困难：

func (c *valueCtx) Value(key interface{}) interface{} {
	if c.key == key {
		return c.val
	}
	return c.Context.Value(key)
}

，
当ctx.Value()被调用时，ctx会疯狂调用子代的ctx.Value()，产生巨大的CPU消耗；同时，大量子代ctx占用大量的内存，与 @1265578519 的issue中的描述类似。

我尝试修修看看
v2fly@73616ab

安卓上用iperf3测试了一下，cpu占用好像正常了，之前测试cpu占用可以在50%以上，现在最多也就5-6%左右 等其他人再测试看看

[zhj9709]

(声明：本人萌新+小白，若有纰漏，还望各位大佬海涵。）
这是一个socks中对于UDP连接的一个bug：
(v2ray-core/proxy/socks/server.go line213-245)

for { 
	mpayload, err := reader.ReadMultiBuffer() 
	... ...
	for _, payload := range mpayload { 
		... ...
		if inbound := session.InboundFromContext(ctx); inbound != nil && inbound.Source.IsValid() { 
			ctx = log.ContextWithAccessMessage(ctx,... ...) 
		} 
		ctx = protocol.ContextWithRequestHeader(ctx, request) 
		... ...
	}
} 

首先，v2ray会对每一个socks连接建立一个Context(ctx)，并对其添加几个Value（例如ID）:

v2ray-core/app/proxyman/inbound/worker.go

Line 289 in f9935d0

ctx = session.ContextWithID(ctx, sid)

对于socksClient发来的每一个UDP包，v2ray都会对ctx进行log.ContextWithAccessMessage()与protocol.ContextWithRequestHeader()操作。这两个函数本质上是Context.WithValue()。
Context.WithValue()相关代码：

func WithValue(parent Context, key, val interface{}) Context {
	if key == nil {
		panic("nil key")
	}
	if !reflectlite.TypeOf(key).Comparable() {
		panic("key is not comparable")
	}
	return &valueCtx{parent, key, val}
}

当socksClient发来的UDP包很多时，存放ID的valueCtx就是当前ctx的子n代ctx，这时从ctx中获取ID对应的Value就会极为困难：

func (c *valueCtx) Value(key interface{}) interface{} {
	if c.key == key {
		return c.val
	}
	return c.Context.Value(key)
}

当ctx.Value()被调用时，ctx会疯狂调用子代的ctx.Value()，产生巨大的CPU消耗；同时，大量子代ctx占用大量的内存，与 @1265578519 的issue中的描述类似。

我尝试修修看看
v2fly@73616ab

另一部手机测试了一下，虽然cpu占用好很多，但还是有点高

[1265578519]

感谢楼上大佬提交PR，等版本发布好进行测试，不会编译，只能等现成的

[zhj9709]

感谢楼上大佬提交PR，等版本发布好进行测试，不会编译，只能等现成的

我编译一份发给你试试

[kslr]

感谢楼上大佬提交PR，等版本发布好进行测试，不会编译，只能等现成的

https://github.com/v2fly/V2FlyBleedingEdgeBinary/releases/tag/unstable-3e13d79af700f667a8663c6f1e62a9e3d9b0558a

[Lightmani]

在我的Win10Pro+Netch 1.4.9的试验下,一局10分钟的CSGO,游戏中显示的延迟大概在62-70之间波动,和我节点本身的延迟并没有太大区别.
由于我没有COD,所以无法测试.但是我在GTAV,CSGO,彩虹六号中也从未遇到过CPU占用满的问题．
只有在彩虹六号里延迟比较高到了120ms....可能是因为我的节点比较垃圾吧...
所以我觉得这个问题是CoD的个例,就我本人的游戏体验来看,从未遇到过类似情况

请问v2ray什么协议能玩彩虹六号？tls + websocket + socks5，测试出fullcone，但是游戏都连不上

Vmess+Ws+TLS
这个和协议的关系不大吧?建议检查下落地机和本地环境

[604909288]

感谢楼上大佬提交PR，等版本发布好进行测试，不会编译，只能等现成的

https://github.com/v2fly/V2FlyBleedingEdgeBinary/releases/tag/unstable-3e13d79af700f667a8663c6f1e62a9e3d9b0558a

这个是测试版的链接吗

[1265578519]

测试了，还是没修复，不过确实有一定好转了。不过问题还存在。之前不到10分钟必爆炸的，现在能撑住20-25分钟左右才出问题，打游戏依旧还是能百分百复现这个问题
麻烦大佬们在看看代码哪里能优化吧

[604909288]

测试了，还是没修复，不过确实有一定好转了。不过问题还存在。之前不到10分钟必爆炸的，现在能撑住20-25分钟左右才出问题
麻烦大佬们在看看代码哪里能优化吧

我这边感觉好多了，两个小时了，很稳定，就百分之2以下不涨了，之前一个小时就爆了

[Kylejustknows]

测试了。情况好转了非常多！

但看来这里有不止一个Bug.....

第一个Bug, UDP狂发包时CPU占满问题，基本解决了，CPU怎么轰炸都不会超过5%！

修正，第二个Bug，在我把服务器端也升级成测试版后，也好了！再也没遇到过。

每秒发超过2000个UDP包时，才开始偶尔丢包。性能非常强悍！CPU一直没超过6%。
这个BUG就这么修好了！V2ray可以正式做为游戏的主流代理软件来使用了。
建议尽快发布正式的新版更新。

第二个Bug, UDP假死问题，还是存在（Iperf跑几遍就能遇到)

主要错误显示是：v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe
这一行错误显示的瞬间，就假死了。
最麻烦的是，当假死发生后，这个UDP连接不会断掉、不会重联，而是永远保持着若有若无的连接（等了5分钟都没断，我猜如果在游戏里，就会显示999ms+的给人感觉已断网，但软件又显示没彻底断网的状况）

一直到软件关闭或者强行放弃这条UDP连接时，V2ray才会显示一条：
v2ray.com/core/app/proxyman/inbound: connection ends > read tcp 127.0.0.1:1081->127.0.0.1:59585: wsarecv: An existing connection was forcibly closed by the remote host.

[604909288]

大佬们牛逼，🙏🙏

[1265578519]

测试了。情况好转了非常多！

但看来这里有不止一个Bug.....

第一个Bug, UDP狂发包时CPU占满问题，基本解决了，CPU怎么轰炸都不会超过5%！

第二个Bug, UDP假死问题，还是存在（Iperf跑几遍就能遇到）

主要错误显示是：v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe
这一行错误显示的瞬间，就假死了。
最麻烦的是，当假死发生后，这个UDP连接不会断掉、不会重联，而是永远保持着若有若无的连接（等了5分钟都没断，我猜如果在游戏里，就会显示999ms+的给人感觉已断网，但软件又显示没彻底断网的状况）

一直到软件关闭或者强行放弃这条UDP连接时，V2ray才会显示一条：
v2ray.com/core/app/proxyman/inbound: connection ends > read tcp 127.0.0.1:1081->127.0.0.1:59585: wsarecv: An existing connection was forcibly closed by the remote host.
才结束。

可能你说的第二个问题，也会引起CPU100%。。。我这能出现
服务端我刚测了，使用vmess协议依然有问题。
包括用v2ray内置的ss，也会出现日志文件显示的和你类似。
然后一段时间后CPU直接冲到99%然后就卡死了。
内置的ss和使用v2ray vmess协议一样有相同的毛病

• [2020/06/19 02:23:22 117.183.0.3:6325 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:23 117.183.0.3:6326 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:24 117.183.0.3:6330 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:25 124.88.112.11:22264 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > unexpected EOF
  2020/06/19 02:23:25 117.183.0.3:6333 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:26 117.183.0.3:6335 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:27 117.183.0.3:6340 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:28 117.183.0.3:6341 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:29 117.183.0.3:6342 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:30 117.183.0.3:6344 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:31 117.183.0.3:6345 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:32 117.183.0.3:6350 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:33 117.183.0.3:6353 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:34 117.183.0.3:6354 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:35 117.183.0.3:6355 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:36 117.183.0.3:6357 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:37 udp:117.183.0.3:6917 accepted udp:185.34.107.128:3074
  2020/06/19 02:23:37 117.183.0.3:6358 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:38 117.183.0.3:6359 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:39 117.183.0.3:6361 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF
  2020/06/19 02:23:40 117.183.0.3:6362 rejected v2ray.com/core/proxy/shadowsocks: failed to read IV > EOF ]

[Kylejustknows]

可能你说的第二个问题，也会引起CPU100%。。。我这能出现
服务端我刚测了，用v2ray内置的ss，也会出现日志文件显示的和你类似。然后一段时间后CPU直接冲到99%然后就卡死了。内置的ss和使用v2ray协议一样有相同的毛病

把你贴的日志文件精简一下，太长了，重复的留几行就行了。
第二个问题，我刚开始测试的时候只有本地客户端用了测试版，才出现
几分钟后，我把服务器那边的v2ray也升级了，然后就再也无法复现第二个Bug。

现在我打字的同时，我的服务器和客户端正在以每秒2000个UDP包的速度同时上传+下载，不停地跑，稳定的一笔。

你贴的日志，看起来像是shadowsocks组件出的问题。可否换回成vmess试试？现在修复后vmess的UDP性能可能比Shadowsocks协议更强悍了。

[1265578519]

可能你说的第二个问题，也会引起CPU100%。。。我这能出现
服务端我刚测了，用v2ray内置的ss，也会出现日志文件显示的和你类似。然后一段时间后CPU直接冲到99%然后就卡死了。内置的ss和使用v2ray协议一样有相同的毛病

把你贴的日志文件精简一下，太长了，重复的留几行就行了。
第二个问题，我刚开始测试的时候只有本地客户端用了测试版，才出现
几分钟后，我把服务器那边的v2ray也升级了，然后就再也无法复现第二个Bug。

现在我打字的同时，我的服务器和客户端正在以每秒2000个UDP包的速度同时上传+下载，不停地跑，稳定的一笔。

你贴的日志，看起来像是shadowsocks组件出的问题。可否换回成vmess试试？现在修复后vmess的UDP性能可能比Shadowsocks协议更强悍了。

现在突然没跳出那种日志了，，不过还是有毛病
内置的SS运行5分钟后占用30%

运行10分钟后占用50%，游戏正常玩20分钟后，它会越来越高然后就爆掉了，等会我抓个v2ray vmess协议给你看看，还是有毛病的。只不过以前10分钟内必爆，现在可以撑20分钟了

用SS是方便测服务端，，因为用v2ray的话，一般是客户端先炸了，服务端还算正常。

[1265578519]

额。玩了十分钟确实没问题了，我只升级了服务端，我刚才Netch客户端内的v2ray没升级。
刚我下了直接复制进去Netch客户端的bin目录后，v2ray vmess协议已经没毛病了打游戏cpu占用不到1%，没有跳动CPU的现象，内存不超过20M没有波动

不过v2ray内置的ss要不要顺便看看是什么毛病啊？
@Kylejustknows 大佬要不要抽空看看

配置方法如下

                                       "streamSettings": {
                                "network": "ws"
                        },
                        "sniffing": {
                                "enabled": true,
                                "destOverride": [
                                        "http",
                                        "tls"
                                ]
                        }
                } ,
        {
            "protocol": "shadowsocks",
            "port": 65535,
            "settings": {
                "method": "aes-128-gcm",
                "password": "www.v2ray.com",
                "network": "tcp,udp",
                "level": 1,
                "ota": false
            }
        }
        ],

根据之前大佬提交的PR，，我搜了下源代码，应该是这个文件这一段影响了
https://github.com/v2fly/v2ray-core/blob/73616ab9e221850a278bd902e9cd8d759a72553f/proxy/shadowsocks/server.go#L147
看到了类似代码

如果正式版本发布了，希望注明下当前版本已经可以支持游玩游戏。方便大家看到更新日志能理解现在v2ray也能用来打游戏了
new v2ray a proven and effective pc game fast solution.