兼容游戏列表 Compatible Game List

[Liqianyu]

我建议创建一份兼容性游戏列表，以以下格式。 I suggest creating a list of compatible games in the following format.

格式

好(比代理前有改善) Good

一般(没有显著变化) General

坏(甚至更差) Bad

存在问题(存在特定问题) Known Problems

游戏名: 平台:(Windows 10、XboxOne、PS4、Switch) Game Name: platform:(Windows 10、XboxOne、PS4、Switch) 版本:(v1\v2 git) Ver:(v1\v2 git) ISP:(尽量详细) VPS:(服务商、可尽量详细) 描述:(尽量详细) description: 日志:(如果可能，请贴上任何可能有用的日志) Logs:(If possible, please paste any log that may be useful)

例如: example: 存在问题: Known Problems: 游戏名:The Last of Us 平台:PS4 Pro Game Name: The Last of Us platform:PS4 Pro 版本:v1 ISP:北京移动 FTTH 100Mbps (公网IP 正规IX) VPS:阿里云香港国际版 47.89段 描述:无法搜索到房间，该问题在不代理情况下正常。可能是无法解决的代理问题。(使用VPN可能改善？) Description: The room could not be searched and the problem is normal without an agent. Probably an agent problem that can not be solved.

好 植物大战僵尸：花园战争2 PS4 Pro 版本:v1 ISP:北京移动 FTTH 100Mbps (公网IP 正规IX) VPS:阿里云香港国际版 47.89段 描述: 延迟得到了惊人的降低。欧洲、美东、美西、欧洲、亚洲的延迟统统低于100ms。 裸连欧洲、美国的延迟至少在200以上。

[wangyu-]

UDPspeeder只要合理配置，本身几乎不会引入兼容问题，如果出现兼容问题，应该主要是s**-redir方式本身的兼容问题。UDPspeeder+OpenVPN方式基本可以兼容任何游戏。兼容性问题和UDPspeeder的使用方式有关。

延迟能否降低，跟VPS的线路有很大关系。

总结一份Good/General/Bad，因为结果受UDPspeeder使用方式和VPS线路的影响，可能不是很有参考性。

尽管如此，仍然欢迎反馈使用效果。

[Liqianyu]

@wangyu- 主要是不同游戏对代理的适配不尽相同。因为每个游戏的机制不同。 我知道其本身并无兼容性问题。 现在我所遇到的问题就是。 The Last of Us使用任何代理都会出现搜人非常慢的情况(似乎只要代理UDP，即使是仅代理TCP也会) 我本身裸连搜人是非常快的。我在日志里可以看到很多MTU的警告。 不知道是不是这个原因。

[wangyu-]

https://github.com/wangyu-/UDPspeeder/wiki/使用经验

MTU问题可以看一下玩游戏的推荐设置这一节，只要你设置对了，就不会再出MTU问题了。

[Liqianyu]

@wangyu- 感谢回复，在格式上面加入了ISP、VPS的部分。 我现在试试v2版，能不能解决MTU的问题，除了MTU的问题，有些时候游戏发生错误的时候，我还可以看到断线的报错。 Logs recv_from error,errno Resource temporarily unavailable,this shouldnt happen,but lets try to pretend it didnt happen

使用V2服务端客户端 MTU报错不再出现。 没任何报错，但是游戏依旧搜不到人...

[wangyu-]

Resource temporarily unavailable出这个错误可能是VPS本身的问题。我自己从来没遇到过这个错误。

之前有人遇到同样的错误，他后来换了个VPS测试就没问题了。

https://github.com/wangyu-/UDPspeeder/issues/42

[Liqianyu]

我也认为这可能是VPS与目标的问题。 出现次数很少。 至于The Last of Us的问题我怀疑是因为搜人机制所导致的。 这个游戏的搜索机制很奇怪，完全是P2P的。 我有抓包过都是和亚马逊服务器发送一些UDP数据的样子。

可能和STUN有关...

长时间搜人没搜到自己掉线了....什么鬼 延迟突然增高。 阿里云开始丢包了...233

[wangyu-]

至于The Last of Us的问题我怀疑是因为搜人机制所导致的。 这个游戏的搜索机制很奇怪，完全是P2P的。

用VPN方式预期可以解决。VPN的兼容性更好。

[Liqianyu]

@wangyu- V2似乎比V1增加了少许延迟...(大约在6ms) 但是不会出现MTU分片问题...

是的，也许需要VPN解决... 那么最好是ShadowVPN＋OpenVPN?

[wangyu-]

用我推荐的那个游戏参数，不会增加延迟。 6ms可能是网络波动。

[Liqianyu]

但是我立刻切换到v1服务端，延迟确实降低了... 难道说是巧合？ 切换回来变高。

[Liqianyu]

@wangyu- 我尝试使用ShadowVPN，但是无法通信？ Log是 [WARN]send returned -1 ,errno:Resource temporarily unavailable MTU尝试调整到1200也没用。 服务端和客户端都是0.2.0 不套可以正常连。

[wangyu-]

在软件两端加上--log-level 5和--log-position，贴出client和server端的完整命令和log

不套可以正常连。

把套和不套的完整命令都发一下。

[Liqianyu]

@wangyu- 隐私信息已去除。 VPS:Aliyun HongKong Debian Router-ShadowVPN-speederv2-speederv2-ShadowVPN-VPS 我ShadowVPN直接跑本地的3333端口，应该没理解错吧？ 会被speederv2转发到VPS的speederv2然后转到ShadowVPN 但是不成功，很奇怪。不套是正常连通的。 另外路由-VPS的speederv1、speederv2都经过SS-UDP的测试，是正常的。 服务端似乎根本没接收到包？ 需要配置iptables？

S ./speederv2 -s -l0.0.0.0:8855 -r127.0.0.1:666 -f2:4 -k "password" --mode 0 -q1 --log-level 5 --log-position [2017-11-16 18:05:39][INFO]argc=13 ./speederv2 -s -l0.0.0.0:8855 -r127.0.0.1:666 -f2:4 -k password --mode 0 -q1 --log-level 5 --log-position [2017-11-16 18:05:39][DEBUG]key=password [2017-11-16 18:05:39][INFO][misc.cpp,func:print_parameter,line:253]jitter_min=0 jitter_max=0 output_interval_min=0 output_interval_max=0 fec_timeout=8 fec_data_num=2 fec_redundant_num=4 fec_mtu=1250 fec_queue_len=1 fec_mode=0 [2017-11-16 18:05:39][DEBUG][common.cpp,func:new_listen_socket,line:590]local_listen_fd=5 ,[2017-11-16 18:05:39][DEBUG][tunnel.cpp,func:tunnel_server_event_loop,line:385] delay_manager.get_timer_fd() =4 [2017-11-16 18:05:39][INFO][tunnel.cpp,func:tunnel_server_event_loop,line:387]now listening at 0.0.0.0:8855 [2017-11-16 18:05:39][DEBUG][tunnel.cpp,func:tunnel_server_event_loop,line:393] timer.get_timer_fd() =7

C ./speederv2 -c -l0.0.0.0:3333 -rVPS_IP:8855 -f2:4 -k "password" --mode 0 -q1 --log-level 5 --log-position [2017-11-16 18:05:45][INFO]argc=13 ./speederv2 -c -l0.0.0.0:3333 -rVPS_IP:8855 -f2:4 -k password --mode 0 -q1 --log-level 5 --log-position [2017-11-16 18:05:45][DEBUG]key=password [2017-11-16 18:05:45][INFO][misc.cpp,func:print_parameter,line:253]jitter_min=0 jitter_max=0 output_interval_min=0 output_interval_max=0 fec_timeout=8 fec_data_num=2 fec_redundant_num=4 fec_mtu=1250 fec_queue_len=1 fec_mode=0 [2017-11-16 18:05:45][DEBUG][common.cpp,func:new_listen_socket,line:590]local_listen_fd=7 ,[2017-11-16 18:05:45][DEBUG][common.cpp,func:new_connected_socket,line:615][VPS_IP:8855]created new udp_fd 9 [2017-11-16 18:05:45][DEBUG][tunnel.cpp,func:tunnel_client_event_loop,line:52]remote_fd64=4294967397 [2017-11-16 18:05:45][DEBUG][tunnel.cpp,func:tunnel_client_event_loop,line:66]delay_manager.get_timer_fd()=4 [2017-11-16 18:05:45][DEBUG][tunnel.cpp,func:tunnel_client_event_loop,line:77]conn_info.fec_encode_manager.get_timer_fd64()=4294967395 [2017-11-16 18:05:45][DEBUG][tunnel.cpp,func:tunnel_client_event_loop,line:88]conn_info.timer.get_timer_fd()=6 [2017-11-16 18:06:22][INFO][tunnel.cpp,func:tunnel_client_event_loop,line:234]new packet from 127.0.0.1:44769,conv_id=e085e660

[Liqianyu]

不套的话。 服务端和客户端 shadowvpn -c /etc/shadowvpn/server.conf -s start shadowvpn -c /tmp/shadowvpn.conf' -s start

直接就可以连通。 我的ShadowVPN版本是0.20，所以有10.7.0.1/16的NAT，不知道这个地方是不是会有影响？

[wangyu-]

[WARN]send returned -1 ,errno:Resource temporarily unavailable

这个LOG是哪里报的，在完整的log里没有看到。

[Liqianyu]

@wangyu- 如果用speederv1才会出现。

客户端会大量报 [2017-11-16 18:37:41][DEBUG][main.cpp,func:check_delay_map,line:551]send return -1 at @300 [2017-11-16 18:37:41][WARN][main.cpp,func:event_loop,line:781]send returned -1 ,errno:Resource temporarily unavailable [2017-11-16 18:37:41][WARN][main.cpp,func:event_loop,line:781]send returned -1 ,errno:Resource temporarily unavailable 等等，似乎还有MTU的。但是V1和V2我都试过，都是不通。

[wangyu-]

服务端似乎根本没接收到包？

可能是服务端的bind问题，也可能是iptables问题。

你先按照这里说的排查一下吧：

https://github.com/wangyu-/UDPspeeder/wiki/发Issue前请看

看一下里面的自我排查那一节。 S***VPN肯定是支持的，有很多人反馈过可以。

另外你把S*VPN两端的conf也贴一下吧。

[wangyu-]

Resource temporarily unavailable，这个错误我查了一下，如果是send 提示Resource temporarily unavailable，说的是UDP在kenerl中的发送buffer满了，如果出现得少的话可以忽略。在我这边从来没有出现过。

如果是像你说的一样大量出现，就不正常了。原因未知，以前貌似没人提到过send的Resource temporarily unavailable。 我建议你用虚拟机的linux测试一下，先确保配置没问题。

[Liqianyu]

@wangyu- 阿里云网卡绑定的是内网IP。不知道是不是这个影响？ 我都把ShadowVPN切换成无令牌模式，一样是不行。 谁ShadowVPN成功了？麻烦帮我@一下

[wangyu-]

https://github.com/wangyu-/udp2raw-tunnel/issues/84

https://github.com/wangyu-/UDPspeeder/issues/25

https://www.v2ex.com/t/382261 里面也有人反馈可以。

v1 v2都没问题。

要不然你直接用https://github.com/wangyu-/tinyFecVPN 这个吧。

也可以用UDPspeeder+OpenVPN，我发过详细的配置：

https://github.com/wangyu-/UDPspeeder/blob/master/doc/udpspeeder_openvpn.md

[Liqianyu]

@wangyu- 最终我成功了。应该是回环问题。 但是我发现V2要比V1慢特别多。 V1可以达到11/6 上下 V2就只有1.1/5 上下 单位Mbps 延迟相同，但是V2还丢包。

补充:以上测速结果不准确，V1、V2后来测速没显著区别。

MTU不能高于1200，否则就会不正常。

命令是 ./speederv1 -l0.0.0.0:8855 -r127.0.0.1:666 -s -d2 -k "password" ./speederv1 -l0.0.0.0:3333 -rVPS_IP:8855 -c -d2 -k "password"

./speederv2 -s -l0.0.0.0:8855 -r127.0.0.1:666 -f2:4 -k "password" --mode 0 -q1 ./speederv2 -c -l0.0.0.0:3333 -rVPS_IP:8855 -f2:4 -k "password" --mode 0 -q1

[wangyu-]

在测试的时候speederv2CPU占用率有多少？

主要是路由器这一端，VPS端应该没问题。

MTU不能高于1200，否则就会不正常。

V1版有可能，V2版--mode 0不用考虑MTU。

[wangyu-]

用什么方法测试的速度？

[Liqianyu]

总结一下遇到的问题 V1: MTU不能高于1200，要不然会有很多奇怪问题。日志也会报MTU错误。 总之必须调低。 但是，即使是这样，某些时候会突然卡着，这时候重启speeder服务端客户端即可恢复。

V2: BCM4709的话，路由端最高是30%吧。 可以不用理会MTU问题。 暂时来看比V1好，至少还没遇到突然卡住的问题。 但是有时候会突然丢包一下。这在V1上似乎没有。 不过很少，低于1%

[Liqianyu]

测速是使用Fast和SpeedTest 刚才的测速结果确实有错误。不知道什么地方弄错了。 总之还在调试。 这么说还是推荐V2咯？如果路由性能够。

[wangyu-]

这么说还是推荐V2咯？如果路由性能够。

从可以不用管MTU这个角度出发，还是用V2吧。

但是，即使是这样，某些时候会突然卡着，这时候重启speeder服务端客户端即可恢复。

这个基本上不是speederv1的问题，在speederv2写好之前我一直是用speederv1的，在VPS/树莓派/tplink路由器上面跑了几个月，从来没重启过。 不过我是串连了udp2raw用的，不是裸连。

[Liqianyu]

因为ShadowVPN也先天不全，所以我也不好肯定是speederv1的问题。 但是目前speederv2没遇到这个卡住的问题...v1出现特别频繁...大概半小时能出三四次吧...

所谓卡住现象: 浏览器打开网页，一直加载。但是Ping没问题。没丢包也没延迟增加。 此时重启服务端，客户端。立刻恢复。

[wangyu-]

所谓卡住现象: 浏览器打开网页，一直加载。但是Ping没问题。没丢包也没延迟增加。 此时重启服务端，客户端。立刻恢复。

有可能是udp连接被做手脚了。现在运营商很狡猾，连接一段时间后，不直接掐掉你的连接，而是砍掉长度大的UDP数据包。造成的结果就是网页打不开了，但是PING没问题（ping一般都是短包）。我这边在用udp2raw时也能观察到类似问题。

重启udpspeeder相当于换端口重连了，所以可以解决这个问题。

V2版因为可以把大数据包切成小数据包，没受运营商的丢包策略影响。

[wangyu-]

加上udp2raw把udp伪装成tcp，可以缓解udp被做手脚的问题。串上udp2raw后，这种情况的频率大约1天出现几次到几天出现1次不等。udp2raw检测到这个问题以后，可以自动帮你重连。

可以试一下。