一个臭打游戏的对 fullcone 的高谈阔论

fullcone 是啥？

也称 nat1 或者是 nat 开放。简单来说，通讯中对方能获取你未修改的源 ip 和源端口基本就能识别成 fullcone nat。nat 一共有四种，就不细展开了。

fullcone nat 的好处在许多网络游戏（尤其是 cod），只有 fullcone nat 才能匹配到最多的人，nat1 可以匹配 nat 全类型的人，相比之下 nat3 只能匹配到 nat1 和 nat3 的人，nat4 就只能匹配到 nat4 的人，也就是基本鬼服。另外在电驴和 ed2k 网络中，fullcone 能连到最多的节点，ed2k 想要获取 high id 也需要在 fullcone 下。

（21.2.6 更新） 推荐阅读 xray 作者 rprx 的最新力作：进阶必读：代理协议 UDP 全方位透彻解析 · Discussion #237 · XTLS/Xray-core

为啥拿不到 nat1？

从原理上来说，因为全球的 ip 地址不足以及安全上的原因，一般我们拿到的公网 ip 会被 nat 再次处理为内网 ip，如果对方收到的是设备的内网 ip 或者是被 nat 设备转发过的端口号，无法将数据准确返回，则会标为其他类型 nat。

因此我一开始以为是内网 ip 的锅，毕竟公网 ip 比较难获取。后来发现并不是，虽然电信分配的并不是个固定 ip，但也是一个唯一的 ip，并没有其他人跟我共用这一个分配的 ip。

真正的原因是，常见的路由器和光猫所使用的系统基于 linux 内核，linux 默认 nat 转发类型就是 Symmetric NAT，只要通过其进行转发，就会变成其他类型的 nat。

另外，windows 防火墙的错误设置，以及对 udp 的限制（nat 的测试是在 udp 基础上进行的），都会造成 nat 测试结果变为其他类型。

nat 测试

测试 nat 的工具

各类 nat 测试工具原理上有一些差异，导致测试出的结果经常会让人感到迷惑：例如 linux 本身的 nat 实际上是 nat4，但部分测试工具测出来的结果却是 nat2。不过从另一个角度说，nat 类型影响到的应用场景很有限，大部分情况也就是下载和游戏这两个场景受到的影响较大，所以直接通过下载软件、游戏测试当然最好。如果没有呢？测试用到了虚拟机，总不能让人装个 200g 的 cod 进虚拟机。。。

windows

1. NatTypeTester。注意，该软件默认情况下可能不会触发 windows 防火墙的放行通知，导致测试出来的结果出错，得手动放行。
2. pynat。可使用 pip 安装。推荐，但极少数时候服务器出错会导致结果为 block。
3. （21.1.18 更新） HMBSbige/NatTypeTester: 测试当前网络的 NAT 类型（STUN）。多个 stun 地址，支持 socks 代理。
4. （21.1.18 更新）NetchX/Netch: Game network accelerator. Support Socks5, Shadowsocks, ShadowsocksR, Trojan, VMess, VLess proxies. UDP NAT FullCone。是测试工具，同时也是加速工具。

android

1. STUNner。谷歌商店能下到，不过在 vpn 环境下（比如 wireguard）似乎不是很准。
2. pynat。通过终端模拟器（推荐 termux） ，用 pip 安装运行。

测 udp 是否联通的手段（搭着梯子亦可测）

udp 阻塞也是 nat 类型不为开放的原因之一。下文 nat 测试结果提到的某些工具，比如 kcptun-sip003 的 tcp 通过 udp 转发后 udp 直接被拦阻了；以及几乎所有的手机端代理公族，都不转发 udp（虽然手机端游戏很少有 nat 的说法，但阻塞的 udp 一定程度上会导致游戏加速效果不佳）。而测试 udp 是否连通，方法有以下几种。

1. iperf（参考 17.2.10 日记）

2. dig udp dns

   dig '@208.67.222.222' -p 443 www.twitter.com

3. udpping

vpn 代理软件 nat 测试结果（21.1.18 证明已作废）

socks 系代理配合 mellow。

开放：

• ss 原版
• v2 原版
• v2 + tls
• v2 + kcptun
• ss + kcptun + udpspeeder
• ss + cloak 2.0（原 ss 的 udp 未做处理，但 tcp 被拦阻，所以实际上是 ss 原版）
• trojan

无 udp：

• ss + kcptun-sip003
• ss + cloak 1.0
• v2ray mkcp

对称：

• wireguard
• openvpn

socks 代理软件 fullcone 测试结果

促使我再做一次测试的导火索，是 xray 1.21 的更新日志：

可我上次测试出的结论是 vmess 支持 fullcone 啊？后来我发现自己忽略了一个重要的问题：代理工具只转发 tcp 流量时，udp 可能 blocked 也可能直连，直连的情况下 fullcone 测试结果将套用的是本地路由的 nat 类型。。。而测试时我路由器安装的系统是 padavan，已经被我设置为光猫桥接 + nat1 模式了，最终造成报道上出了偏差（

第二次测试不带那些正经的 vpn 玩了（正经的 vpn 都是全流量转发，不存在漏网之鱼的），只带上主流的 socks 代理工具，ss、trojan 和 v2ray（xray） 这三个。同时测试本次 xray 更新究竟能带来什么效果。这次我专门套了一个 nat3 的 openwrt 极路由用来测试。

测试结果如下面两张图所示。

第一张结果来自 windows，第二张结果来自 android。本来只计划测试 pc 端效果。后来发现 各 nat 测试工具连直连测试测出来的结果都不一致，索性把手机拉进来一起测，找找规律。

测试结果不算太严谨，有少数几个测试的结果前面的测试做完就水落石出了，我觉得没必要再去测了，比如手机端的 xray 1.21-> server 端 xray 1.22，更新日志里面都写了两边都要大于 1.21 的版本就会获得 fullcone，电脑这边也测过了，手机这边就不测了 。

• 测试到一半我基本就理解 xray 的更新日志中这个 fullcone 指的是什么了，即旧版本 xray/v2ray/v2fly 的 ss 和 trojan udp 机制有问题导致 nat 类型错误，原版 ss 和 trojan/trojan-go 并不存在这个问题；vmess/vless 也有这个问题但对于它们来说这不是 bug 而是 feature。。。所以，更新前，server 和 client 有一端使用了 v2ray（xray) 本身的 trojan/ss 功能的话会出问题，更新后无论是 xray 内部的 trojan/ss 还是原版 ss/trojan 两两互联 nat 都不会有问题。值得一提的是，xray trojan 即使是使用 xray 的新特性由 vless+tcp 同端口 fallback 而来的，nat 也能保持在 1。

• nat 测试工具中，我原本最为信任的 pynat 反而效果最为拉跨，只要用了代理就弹 fullcone；本身应该弹 fullcone 的反而弹 nat3（使用 mellow 时，不过不排除是 mellow 本身的问题）。新版 NatTypeTester 尚可，没出现什么原则性错误，就是有时用不同的 stun 测试机结果可能会不一样，个人感觉 stun.qq.com 比较准，而默认的 syncthing stun 在 Symmetric 下经常会报 UnsupportServer。netch 虽然准却有「既当运动员又当裁判」的嫌疑；手机端 stunner 除了需要多次测试出结果外，准确率也尚可。

• 某些场景下出现了「假打洞」的现象：多次测试后本身结果应为 nat3 的会慢慢变成 nat2 甚至是 nat1。常出现于在虚拟机 vmware 中使用 pynat 和在 android 中使用 pynat 的情况，偶尔也出现在 NatTypeTester 测试中（无论是虚拟机还是实机）。

  

• 所以原则上我不用虚拟机进行 nat 测试，但。。。mellow 现在的表现实在拉跨，我在实机上开几次才能成功连上一次，bug 不少。用较为干净的虚拟机，清理了注册表后，勉强能进行测试，不过嘛。。。看这测试效果，也许是我配置错了什么地方？

• 标黄色部分的 pynat 测试结果，nat 测出 3 是因为刚开始我不太会配置 netch 的进程模式。之后用 mellow 的时，通过内置的流量路径监控日志才观察到 pynat 的流量路径是这样的：

  windowsTerminal.exe->powershell.exe->pynat.exe->python.exe

  把这些全加到代理的进程列表中就行了。不过看后续的测试效果，也能估计出那些标黄的应该都是 nat1，没有改变 pynat 拉跨的结论（该标 3 的全部给标 1 了）。

• netch 通过 socks 配合其他代理使用只能在进程模式下生效。在 tap 模式没办法排除进程会导致无限 loopback；用除了 socks 以外的代理，启动时都会开一个 socks5 一个 http 代理端口，但用 socks5 的话 netch 就只会开一个 http 端口，好死不死 NatTypeTester 不支持 http 代理（废话，http 代理不支持 udp 还测个啥）。。。所以除了 tun/tap 的测试中我没引入加了二级代理才有的功能。

(21.2.14 更新) xray 的最新更新通过巧妙的方法解决了 fullcone 的问题，鼓掌！而且通过测试 mkcp 也能正常的获取 fullcone 了。另外当时我的 netTester 版本为 3.4，目前最新的版本据悉已经解决了 vmess 显示为 unsupported 的诡异问题（待测试）。

如何解决不是 nat1 的问题？

修改路由器，使用桥接模式或换用支持 nat1 的固件

之前说过 linux 内核设备只要经过流量转发 nat 就不是 fullcone 了。换言之，通过 ssh 连进路由器，在路由器上运行 nat 检测那还会是 fullcone nat，但在连入路由器的设备上检测那就都是 nat4了。

更别说许多家庭用户使用光猫 + 路由器的组合，而光猫也处在路由模式下，就会造成双重 nat。

解决方法有几种，包括：

1. 使用 dmz 和 upnp。通过搜索引擎能查到最常见的方法，实际使用中就会发现一个是在多重 nat 环境中配置复杂，而且实际上我没配置好 upnp 后就没生效成功过， dmz 一次只对一个设备有效，设置了 dmz 也只能保证内网里其中一台设备的 nat 为 1。
2. 在需要 nat1 的设备上进行拨号，将 linux 设备设置为桥接。对于光猫后面挂着路由器的用户来说，完全没有必要用光猫进行路由，或者家中只有一台网络设备（比如电脑），或者能够进行多拨的地区，就算是直接链接光猫也可以这么设置，因为完全没必要路由。但如果家中有多台设备且不能多拨，那如此设置的话就只有其中进行拨号的那台设备能上网了。另外，想要把光猫设置为桥接模式可能需要超级管理员帐号。
3. 使需要进行拨号并开启路由的设备支持 fullcone 转发，比如使用 windows 系统的软路由；或是是刷入支持 fullcone 模式的固件，新版本的 padavan 和 openwrt 应该都可以。意料之外的是某些光猫也支持设置为 fullcone 模式，比如臭名昭著的 tewa-e500。。。不过同样需要超管帐号。

总结一下，对于大部分光猫 + 路由的用户，将光猫设置为桥接，路由开启 fullcone 转发即可。而单光猫或者无光猫单路由则需要在光猫上开启 fullcone，或者直接用需要 nat1 的设备拨号（比如 windows 电脑，比如 xbox/ps4）。

---

不过，如果是配合代理使用，上述措施均不需要。请看下文。

正确配置防火墙

最简单的，vps 面板端的防火墙端口全开 + 系统内关闭防火墙。不过不够安全就是。

比较推荐的方法，对入站端口进行限制，在 web 端和系统端同时添加代理 / 游戏端口，对于一些代理工具，还需要添加高位端口（10000 以上的端口）。

如果系统使用 windows 那就更简单了，可以添加应用到防火墙例外情况中。

出站端口不用管，无论打开还是关闭基本都不影响效果。

使用第三方加速器 / vps

最省心的方法。只要你购买的服务器/加速器上 nat 转发配置正确，经过代理后你的 nat 就会处于开放类型。你只需要付钱即可。

当然，比较低端便宜的加速器技术人员这方面可能弄得不太行（最典型的，雷神加速器就是这样）。

对于 bt 下载也是如此，你可以将直接使用 vps 上搭建的相关工具下载，下载完后再拖回本地，vps 的 ip 一般处在公网且位于国外，能获取到质量最好的 tracker。小心蜜罐种子就是。

---

然而使用本地的 pc bt 工具（比如 qbitorrent）通过代理下载 bt 时，就要考虑代理性能问题了（虽然一般的游戏用的 vpn / 加速器禁止 bt）。udp 不通的代理查看流量走向的话，会发现软件流量走代理， bt 不走代理（不过我怀疑 tcp 方面的流量代理上了有部分加速效果）。而 udp 通畅但 nat 类型不对的话可能代理后效果比代理前还差（存疑）。

修改内核，实现 fullcone

对于本身会修改规则和转发的代理工具来说，直接代理（socks 代理）就会实现 nat1，比如 ss，v2ray，不过他们本身用于科学用途，流量经过多重加密，性能反而一般，用在游戏上拖慢速度和丢包。 其实综合来算 socks 代理效率要高于 vpn（vpn 要保证安全性，使用的加密算法强度普遍较高），不过部分 socks 代理的 udp 代理实现有问题，而正经一点的 vpn（wireguard，openvpn 等），不存在这方面的问题。（虽然有另一种说法 wireguard + udpspeeder 是代理加速游戏最好的方案，但我目前用本地电信实验效果并不理想，况且我家电信还没有受到 udp qos 影响）。

然而全流量代理的会直接套用被代理设备系统 netfilter 的 nat，造成测出的 nat 变为 4。

解决方案是，让系统支持 fullcone nat 并修改其 iptables 使中转流量全部按 fullcone nat 处理。

参考文章：

1. 指南类

• 简单操作使 CentOS 支持 Fullcone NAT
• Centos 7当网关启用Fullcone nat
• 有玩实况足球在线对战的朋友么，需要买哪里的服务器？（详情见评论区）

2. 细节类

• 升级Centos 7/6内核版本到4.12.4的方法
• CentOS 7. × 系统及内核升级指南
• 解决service iptables save出错please try to use systemctl.
• 第九章、防火牆與 NAT 伺服器
• Installing nftables from sources on Debian
• 设置未识别的网络默认为专用网络
• Iptables reload/restart on Ubuntu 18.04
• ubuntu/debian 模块加载方式

尽管我常用 debian，不过好像没有找到 debian 类系统的教学（主要不同点在于内核更换，模块的加载，还有 iptables 的自启上），centos 的倒是蛮多。但 centos 坑也不少，所以先试试 centos7 的。

centos7 内核改装

1. 更换内核。先吐槽一句，centos 更换内核比 debian 麻烦多了，后者下好内核和 header 就能用，centos 还得多下 devel 之类的几样东西，而且还得在官方源里面下，自己下载上传的不好装。。。

   fullcone-nat 模块对内核版本还是有一定要求，太新不行太旧也不行，好消息是支持 bbr 那几个内核基本都成，连 bbr-plus 那个自制内核都成。但锐速那个旧内核，和 centos7 默认定制的这个 3.10 就不要想了。。。

   先添加源

   rpm -import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
   rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

   查看有哪些内核能用：

   yum --disablerepo="*" --enablerepo="elrepo-kernel" list available

   现阶段能看到，mainline 的内核有点新，都是 5.x 系的；而长期支持版内核符合要求，装 lt 就好了。

   yum -y --enablerepo=elrepo-kernel install kernel-lt.x86_64

   装完重启。

   重启以后查看默认内核顺序

   awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg

   改 lt 内核顺序到开机顺序第一位

   vim /etc/default/grub

   改这句的数字到刚刚查看开机顺序看到 lt 内核所在的未知，注意位置是从 0 开始算。

   打个比方查看到的内核顺序，lt 内核在第二位

   那么，改 grub 文件的这一行为

   GRUB_DEFAULT=1

   更新 grub

   grub2-mkconfig -o /boot/grub2/grub.cfg

   重启后查看当前内核对不对

   uname -r

   然后查看当前内核与相关的编译模块有哪些

   rpm -qa | grep kernel

   原来 3.10 相关的 devel 和 header 等等等，全部删掉，否则待会会干扰 lt 内核其他模块的安装（下面这个命令只是打个比方，肯定不止这一个模块）

   yum remove -y kernel-tools-3.10.0-514.26.2.el7.x86_64

   然后安装剩下的 lt 模块，如果不知道还剩哪些的话，可以用「查看有哪些内核能用」那里的命令再确认一下。下面的命令也是仅供参考：

   yum -y --enablerepo=elrepo-kernel install kernel-lt-devel.x86_64 kernel-lt-headers.x86_64 kernel-lt-tools.x86_64 

2. 安装依赖。注意，安装依赖一定在更新内核之后，因为依赖和内核版本挂钩。然后待会的编译一定在安装依赖之后，原因相同。如果发现装的内核不对的话，更新完内核还要再装一边依赖，然后再去编译，否则大概率出现奇奇怪怪的问题。

   yum install gcc gcc-c++ autoconf autogen libmnl libmnl-devel libtool-devel libtool git -y

   另外，装一个原版的 iptables，先把 firewalld 干了（不过我感觉大部分 centos7 默认都不装这玩意）

   systemctl stop firewalld
   systemctl mask firewalld

   然后安装，设置开机启动

   yum install iptables-services
   systemctl enable iptables

   看看版本，应该是 v1.42

   iptables -V

3. 下载所要编译的三个模块源码，一个是 fullcone-nat 模块的依赖，一个是模块本身，另一个是 iptables 模块

   git clone git://git.netfilter.org/libnftnl.git
   git clone git://git.netfilter.org/iptables.git
   git clone https://github.com/Chion82/netfilter-full-cone-nat.git

   然后就是编译安装

   #编译 libnftnl
   cd libnftnl
   sh autogen.sh
   ./configure
   make
   make install
   
   cd ..
   
   #编译fullcone-nat
   cd ~/netfilter-full-cone-nat
   make
   modprobe nf_nat
   insmod xt_FULLCONENAT.ko
   
   cd ..
   
   #编译 iptables
   cp ~/netfilter-full-cone-nat/libipt_FULLCONENAT.c ~/iptables/extensions/
   ln -sfv /usr/sbin/xtables-multi /usr/bin/iptables-xml
   ./autogen.sh
   PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
   export PKG_CONFIG_PATH
   ./configure
   make
   make install

4. 关闭原来 iptables 的 service，换入现在 iptables 的 service，因为刚刚安装的位置和真正 iptables services 指向的位置不一样，没有执行替换的话，待会写入带 FULLCONENAT 的 nat 规则后用 service iptables save 保存就会报错。

   #先关闭iptables
   systemctl  stop iptables
   #删除原来的iptables
   rm -rf /sbin/iptables
   rm -rf /sbin/iptables-restore
   rm -rf /sbin/iptables-save
   #复制你自己编译的iptables
   cd /usr/local/sbin
   cp /usr/local/sbin/iptables /sbin/     
   cp /usr/local/sbin/iptables-restore /sbin/
   cp /usr/local/sbin/iptables-save /sbin/
   #检验iptables版本，应该是 1.8.4
   iptables -V

   注意那三句 cp 一句句执行，因为每句都要按一次 y，全部一起执行的话只会出一次 y，只替换第一个 iptables 文件。

5. 设置开机自动加载 Fullcone 模块

   kernel=`uname -r`
   cp ~/netfilter-full-cone-nat/xt_FULLCONENAT.ko  /lib/modules/$kernel/
   depmod
   echo "modprobe xt_FULLCONENAT" > /etc/sysconfig/modules/xt_FULLCONENAT.modules
   chmod 755 /etc/sysconfig/modules/xt_FULLCONENAT.modules

6. 重启，检查

   lsmod | grep xt_FULLCONENAT

   有输出即可。

7. 未来保存规则，可通过

   service iptables save
   service iptables restart

   生效。

debian 内核改装

1. 安装内核。跳过。一键脚本那么多，教程也写的这么多了。

2. 安装依赖。

   apt install build-essential libtool libnfnetlink0 libnfnetlink-dev libpcap0.8-dev libtool autoconf autogen git -y

3. 下载四个模块的源码。原因是 apt 库中没有 libnftnl 模块的依赖 libmnl 下。

   git clone git://git.netfilter.org/libmnl
   git clone git://git.netfilter.org/libnftnl.git
   git clone git://git.netfilter.org/iptables.git
   git clone https://github.com/Chion82/netfilter-full-cone-nat.git

4. 编译安装。又一个和 centos 不一样的地方，debian 没有 iptables-xml，也没有 pkg_config_path

   #编译libmnl
   cd libnftnl
   sh autogen.sh
   ./configure --disable-dependency-tracking
   #直接configure好像报错
   #./configure
   make
   make install
   
   #编译 libnftnl
   cd libnftnl
   sh autogen.sh
   ./configure
   make
   make install
   
   cd ..
   
   #编译fullcone-nat
   cd ~/netfilter-full-cone-nat
   make
   modprobe nf_nat
   insmod xt_FULLCONENAT.ko
   
   cd ..
   
   #编译 iptables
   cp ~/netfilter-full-cone-nat/libipt_FULLCONENAT.c ~/iptables/extensions/
   ./autogen.sh
   ./configure
   make
   make install

5. 设置开机加载模块

   kernel=`uname -r`
   cp ~/netfilter-full-cone-nat/xt_FULLCONENAT.ko  /lib/modules/$kernel/
   depmod
   echo "xt_FULLCONENAT">>/etc/modules

   重启，检测

   lsmod | grep xt_FULLCONENAT

   另外这里不需要检测 iptables 版本号，因为 debian 默认情况下就安装了最新版的 iptables，所以无论是安装修改版 iptables 之前还是之后，查看版本号都是 1.8.4。

6. 安装 iptables 自动加载服务。

   apt install iptables-persistent -y

   未来保存规则时，需要用以下命令

   iptables-save > /etc/iptables/rules.v4

iptables fullcone 设置

1. 先看目前的 iptables 表，尽管其实一共三张表，但有一张默认不怎么管，一开始也是空的，所以只看 nat 表和 filter 表就够了

   iptables -L -v
   iptables -L -t nat -v

2. 默认情况下，貌似有 drop 规则会干扰使用，需要删掉

   或者直接清空路由表：

   iptables -F
   iptables -Z

3. 理论上，只用添加下面这两句就能生效了

   iptables -t nat -A POSTROUTING -o eth0 -j FULLCONENAT
   iptables -t nat -A PREROUTING -i eth0 -j FULLCONENAT

   还有两个可选规则（准备给 wireguard 的），我测试过没啥用

   iptables -t nat -A PREROUTING -i wg0 -j FULLCONENAT
   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o wg0 -j MASQUERADE

   另外也可以把命令中的 -A 换成 -I 强制添加规则到第一行（不过大部分时候 chain 里面都只有这一条规则）

   而有的 wireguard 教程里面的 postup 和 postdown 也可以加，非 fullcone 下必加，但 fullcone nat 模块开启后就可以不加了

   PostUp = iptables -I FORWARD -i wg0 -j ACCEPT; iptables -I FORWARD -o wg0 -j ACCEPT
   PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT

4. 初步判断 iptables 规则是否有用，可以跑一段时间流量后通过第一步的两个查询命令查看是否有流量通过。注意，有流量通过的规则并不一定是关键有效的，比如 postup 和 postdown 这两句执行后会发现也有流量经过，但去掉了也不影响连通性。

   修改了以后重新观察是否连通正确可以先执行 iptables -Z 清空流量统计。

5. 修改后记得保存，然后重启后通过第一步或者 iptables-save 查看是否重启时自动加载了路由表。

使用类 vpn 工具

类 vpn 工具同样代理全部流量，区别在于它们的 udp 流量经过特殊处理，能够保证 nat 类型为 fullcone。目前有以下这么几种：

• zhxie/ikago: IkaGo is a proxy which helps bypassing UDP blocking, UDP QoS and NAT firewall written in Go.（不太推荐）
  使用体验：ikago 和 pcap2socks 使用体验 | Bao’s 备忘录
• wangyu- / tinyfecVPN：专为有损链接而设计的VPN，具有内置的前向纠错（FEC）支持。 在高延迟有损链路上提高网络质量。

ikago 不推荐的原因是 bug 较为影响使用。

使用 socks 代理转 vpn 工具

• Proxifier - The Most Advanced Proxy Client
• SSTAP
• mellow（不太推荐）
  使用体验：mellow 使用体验 | Bao’s 备忘录
• zhxie/pcap2socks: Redirect traffic to SOCKS proxy with pcap.（不太推荐）
• zhxie/pcap2socks-gui: A front-end interface for pcap2socks.
  使用体验：ikago 和 pcap2socks 使用体验 | Bao’s 备忘录
• NetchX/Netch: Game network accelerator. Support Socks5, Shadowsocks, ShadowsocksR, Trojan, VMess, VLess proxies. UDP NAT FullCone
  使用体验：netch 使用体验（代理规则获取） | Bao’s 备忘录

mellow 和 pcap2socks 不推荐的原因同样是 bug 不少，另外 mellow 的配置门槛还挺高的。不过 mellow 的最大贡献是应该本身 go 的 tun/tap 实现。pcap2socks 就比较神秘，cli 界面用着用着就会报错，但 gui 并不会报错。

剩下的几个，Proxifier 专注于进程代理，能给多个进程配置不同的代理和 dns，我觉得更适合作为那些个长期挂在后台，需要代理却不支持 http 代理也没有 socks 配置设置的应用使用。

netch 是这几个中我最为推荐的，直接支持多种协议不需要再用二级代理进行转发（除非是使用 mkcp+seed，目前 netch 中还不支持相关配置）。不过之前也提到，tun/tap 全局代理尚未可用（容易 loopback）。且 netch 的 tun/tap，确实也有几次上不去网的状况发生，不算非常稳定。

SSTAP 可用全局代理，通过设置路由能够避免 loopback 的产生。不过人家在项目主页上也说了，使用 sstap 不仅不能解决 nat 问题，nat 还会永远被固定在 Symmetric 的状态。

上面这些工具，除了 pcap2socks 外工作方式无非进程代理和 tun/tap 转发两种。tun/tap 转发在建立了正确 ip 表的前提下效果完美，但可靠性欠佳（极少情况下反复开关几回以后网卡都工作不正常了，表现为啥网页都开不开，重启后才正常）。而进程代理方式有可能会遗漏一些游戏进程外的相关进程，就会造成类似 cod16 中游戏流量显然已经被加速过（丢包减少，能进游戏），然而丢包显示错误（始终为 0）的情况，或者是类似微软系第一方游戏上未加速 xbox live 服务导致云同步工作不正常的情况。

pcap2socks 工作方式又和上面这些不太一样，大概应该属于旁路由，好处是可以给主机加速，坏处是加速设备不能和游戏设备是同一台，各类第三方加速器的主机加速模式也是这个原理。类 vpn 工具中的 ikago 同样也是旁路由原理，不过是 ikago 还拥有转发流量到 vps 的功能，而 pcap2socks 则把这个功能交给了 socks 代理来实现。

话说回来，几种 socks 代理工具中，ss 和 ssr 属于 UOU（udp over udp），能够配合 udpspeeder/udp2raw/kcptun 使用；trojan 和 vless 属于 UOT（udp over tcp），只能配合 kcptun 使用。还有一个问题，就是在部分游戏的丢包显示中（比如 cod16），使用 UOT 代理做隧道的话，丢包显示不准确，始终为 0。未来 xray 如果能实现 smux 功能的话，就能部分替代 udpspeeder/kcptun 的加速效果。