Mellow做网关时 ，PC测试为FullCone 但 Switch 和 PS4 测试网络NAT类型分别是F和第三类

[mellow-io]

Mellow做网关时 ，PC测试为FullCone 但 Switch 和 PS4 测试网络NAT类型分别是F和第三类

[feng92f]

@eycorsican 今天在 openwrt （透明代理）测试PS4还是类型3, 测试 PC 是Full Cone。透明代理已经满意了，就是一直搞不定PS4。

[feng92f]

@eycorsican 排除了mellow的问题，有可能是PS的测试包太大了，服务端或机房的问题

[feng92f]

发送了个1522Bytes的UDP有1600的返回：
unknown process | udp | 39s | 192.168.2.150:9308 | 52.40.62.122:3478 | 1,552 | 1,600 |   | udp_out
发送22528的没有返回（我猜这个0是超时了吧）
unknown process | udp | 32s | 192.168.2.150:62484 | 52.40.62.122:3478 | 22,528 | 0 | | udp_out
这是PS的测试

[feng92f]

服务端的日志是PS测试NAT类型的时候会先发10个小的UDP，都可以成功。然后再发10个大的UDP，ss或者socks都能发出去，但是没有回复。

2019/11/09 05:20:59 [Info] [1998981765] v2ray.com/core/proxy/freedom: opening connection to udp:52.40.62.42:3478
2019/11/09 05:21:00 [Debug] [1998981765] v2ray.com/core/proxy/socks: send packet to udp:52.40.62.42:3478 with 2038 bytes
2019/11/09 05:21:00 [Debug] [1998981765] v2ray.com/core/transport/internet/udp: dispatch request to: udp:52.40.62.42:3478
2019/11/09 05:21:00 [Debug] [1998981765] v2ray.com/core/proxy/socks: send packet to udp:52.40.62.42:3478 with 2038 bytes
2019/11/09 05:21:00 [Debug] [1998981765] v2ray.com/core/transport/internet/udp: dispatch request to: udp:52.40.62.42:3478
2019/11/09 05:21:02 [Debug] [1998981765] v2ray.com/core/proxy/socks: send packet to udp:52.40.62.42:3478 with 2038 bytes
2019/11/09 05:21:02 [Debug] [1998981765] v2ray.com/core/transport/internet/udp: dispatch request to: udp:52.40.62.42:3478
2019/11/09 05:21:03 [Info] [4102669601] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2019/11/09 05:21:03 [Info] [4102669601] v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe
2019/11/09 05:21:03 [Info] [1998981765] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2019/11/09 05:21:03 [Info] [1998981765] v2ray.com/core/transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe

[eycorsican]

你服务端用 v2ray-core ？

[feng92f]

是为了排查，在服务端debug清楚点 就v2ray 开了socks代理看日志，小包都成功了，但是大包都没有回复。 ss用的其他版本 以及机场服务也测试过。 eycorsican <[email protected]>于2019年11月10日 周日16:48写道：

…

你服务端用 v2ray-core ？ — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#35?email_source=notifications&email_token=AAEW7SE4P5UESOVEKONEFQ3QS7DEDA5CNFSM4I5FJC32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUYMYI#issuecomment-552175201>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEW7SEA5T6NEY4YIQ6Q4VDQS7DEDANCNFSM4I5FJC3Q> .

[eycorsican]

说起这个包大小，v2ray 在这方面好像是有些问题的，我后面修一下再发个包，你有空测试下一不？需要 macOS 还是 Linux？

[feng92f]

Linux amd64 eycorsican <[email protected]>于2019年11月10日 周日18:43写道：

…

说起这个包大小，v2ray 在这方面好像是有些问题的，我后面修一下再发个包，你有空测试下一不？需要 macOS 还是 Linux？ — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#35?email_source=notifications&email_token=AAEW7SCAPXTJV5QOKG4MLKLQS7QTPA5CNFSM4I5FJC32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDU2KAA#issuecomment-552183040>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEW7SDLVGFYV6VMSDHOU2TQS7QTPANCNFSM4I5FJC3Q> .

[eycorsican]

发现改起来很麻烦还是算了。

总的来说，通过 v2ray-core （或者 Mellow）的 UDP 包不能超过 2048 字节，超过部分数据会丢失，从上面的日志来看，代理的数据是 2038 字节，如果算上 SOCKS5 协议头 10 字节，刚好传了 2048 字节。

UDP 包一般不会超过 1500 字节所以问题不大，你实际使用中，比如玩游戏时，会因为这个问题玩不了吗？

[feng92f]

那就是PS4发出的是更大的包，发出前被截取了，导致过不了NAT服务器的校验。感觉是不好修啊。Apex 进不去。

[feng92f]

还有一些游戏也是哗哗的UDP超时

[feng92f]

哪有什么推荐的办法处理这些UDP流量呢

[eycorsican]

@feng92f 试下这个：https://github.com/mellow-io/mellow/releases/download/v0.1.8/core-linux-amd64-fix-udp

[feng92f]

@eycorsican 我测试了好几次，结果不同。有时候是类型二，有时候是类型三。类型三会影响游戏。
我把非53的UDP走ss-redir，让ss的路由直接从网关出去的话，每次都是类型2，服务端没问题。

[eycorsican]

你的意思是流量先经过 Mellow 再到 ss-redir ？还是完全不经 Mellow ？

[feng92f]

备选方案不经过 mellow ，我在session里看不到目的地为ss或者真实服务器的流量记录。

[feng92f]

之前PS会提示你的路由器不支持IP Fragments，现在看不到了

[feng92f]

啊不是备选，这个方案太麻烦了，还是完美支持最好啦

[eycorsican]

能给日志和用 tcpdump 抓下包最好

[feng92f]

好的

[eycorsican]

@feng92f

再测下这个：https://github.com/mellow-io/mellow/releases/download/v0.1.8/core-linux-amd64-fix-mtu

[feng92f]

@eycorsican 这个类型3我估计还包含了丢包率信息 这是Apex的连接数据（mellow）

用ss-redir测试几乎都是0丢包

[eycorsican]

再用这个抓下包：https://github.com/mellow-io/mellow/releases/download/v0.1.8/core-linux-amd64-ttl-tos

抓包时不要只过滤 udp，抓所有的数据，并用 -w 写到 pcap 文件里，比如这样：

tcpdump -i tun1 -w out.pcap

分别抓以下场景：

• 用 mellow 测出类型二
• 用 mellow 测出类型三
• 用 ss-redir 测出类型二

每次抓包只包含一次测试，从开始测试到结果显示出来为止，如果出现超时或者类型不符合的话要重测的话，抓包程序也要重启，不要把多次测试混在里面。

[feng92f]

可能是由于昨天重启路由的时候，mellow 启动前 sleep 时间太长了，所以走的是直连。

[eycorsican]

@feng92f https://github.com/mellow-io/mellow/releases/download/v0.1.8/core-linux-amd64-fix-nat

[feng92f]

@eycorsican 成就达成。稳定类型2，但是丢包（测试提示不支持Fragment，游戏丢包5%，进不去），应该是大包的问题。

[eycorsican]

不应该有 fragment 问题啊，会不会是网络波动问题

[feng92f]

@eycorsican "测试提示不支持Fragment" 是误报，抱歉，是我的MTU改成1400测试的，改为1500就好了。丢包还存在，我再确认一下。

[feng92f]

会不会是有的包不被core识别为UDP，然后走了vmess？我好几个出口

[eycorsican]

把配置改为全局代理到 ss-libev 服务器测下

[feng92f]

@eycorsican 稍等一下 我得换个服务器

[feng92f]

@eycorsican 全局后仍然有2%的丢包率(多个机房)，进入游戏要多次重试，可以进入。使用ss-redir可以0%丢包。让ss-redir处理非tcp流量后走mellow可以0丢包（游戏-ss-mellow-libev）。

[eycorsican]

流量是怎样从 ss-redir 给到 mellow 的？整个配置是怎样的？多个机房是指多个游戏区域服务器还是不同机房的 ss-libev？

[feng92f]

多个机房是:多个ss-libev测试多个游戏的机房都丢包。最后一个版本的session页面故障了，所以我不是很确定，通过iptables把udp标记，通过tproxy转给ssredir，然后ssredir走core出去。。。。如果我给ss加入静态路由直接到eth1，这个就不走core。

[eycorsican]

ss-redir 走 core (mellow) 的 freedom 出去？sessions 页面有啥故障了？

[feng92f]

@eycorsican 不好意思哈，昨天那个session页面打开的确表格只有表头， 里面没数据，我没能确认。
刚才重试了，没能重现，昨天应该是幻觉。通过ss转给mellow，仍然有2%的丢包。

这个就是ss走了mellow，挺滑稽，从udp-out出去的。这个红色的是sslibev。

[feng92f]

udp_out 就是 sslibev

[eycorsican]

我还是没看懂，大概是因为我没用过 ss-redir 吧，你直接把 ss-redir 和 mellow 的配置发一下。

[feng92f]

@eycorsican 我刚找机器测试了PUBG，ss-redir和mellow做到同样的效果，反复确认延迟和丢包率一样都是100ms和0%丢包。100ms主要是因为机房远。

[feng92f]

加 ip route add xxxxx via 192.168.1.1 table main 就绕过mellow，不加就走mellow，mellow配置没什么变化，基本就是你的推荐配置

[feng92f]

这Apex丢包是很严重的，2%是启动游戏前的测试，进入后丢包是上升的，应该和具体游戏的通讯方式有关了，Apex是不能玩的。PUBG没问题。

[eycorsican]

没什么头绪，感觉像是配置不当引起的问题，比如 DNS 解析返回了一个不合适的 IP。

现在 NAT 问题解决了，丢包问题另外开个 issue 讨论吧。

[feng92f]

好的 #80 #80