f4nff

还有一种情况，我测udp打洞的时候，复现的， 比如阿里云来说 本地 192.168.2.22:8889-->>---阿里云 47.221.22.22:80 udp发送数据，连续发送几个udp数据包，如果阿里云那边没有返回数据，那么本地怎么发数据，阿里云那边也收不到， 这就是我看到一些人有讲必须重启进程才能连上的原因， 如果网络抖动的时候，过多单边发送udp数据，会被视为攻击行为，会被屏蔽 这时候，就要释放掉本地的端口，重新建立新的连接，即可，这就是重启进程就恢复的根本原因。 以上3点如果做到，基本就有本质的改变了。

`--conn value set num of UDP connections to server (default: 1)` 这个参数只是实现了多并发连接， 可以实现多连接实现更多带宽争取， 但是解决断流问题需要实现 会话平滑转移，单位时间内，先建立新的隧道，然后把会话转移到新的隧道，然后释放之前的隧道， 然后为了尽量避免因为突发带宽过高触发Qos策略，还需实现限流，是单个连接的限流，而不是根据ip限流。 运营商，不止国内，基本全球运营商的Qos都是针对单连接的限速，而不是根据某个ip限速。

` --tcp to emulate a TCP connection(linux)` 这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包， nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了， Qos的条件非常简单， 在互联网中qos除了特别的策略， 只有四个条件， `源ip，源port，目标ip，目标port` 而且还有时效性， 只要这四个条件一直变，就可以完全避开Qos策略。

在互联网中qos除了特别的策略， 只有四个条件， `源ip，源port，目标ip，目标port` 而且还有时效性， 只要**这四个条件其中一个条件一直变**，就可以完全避开Qos策略。 **假设一个连接只用45s-120s左右， 并发5个连接，每个连接限速50Mbps峰值， 那么一直可以持续200Mbps带宽是没问题的。** 不过这样还是悄悄的玩，不然出口会更堵了。

`--autoexpire value set auto expiration time(in seconds) for a single UDP connection, 0 to disable (default: 0)` @laikitleung 这个确实有这个作用，但是不支持会话平滑转移到新连接， 如果老隧道里面有长连接，老隧道会一直保持， 如果完善一下这个功能，增加一下会话平滑转遇到新建隧道，就不错了，

垃圾协议，没必要支持，

你抗q直接用v2不就得了

@jfc8000 good～

``` { "strategy": "random", "max_fails": 1, "fail_timeout": 30, "nodes": [ "http://1.1.1.1:8080 -F=socks5://2.2.2.2:1080", "http://3.3.3.3:8080 -F=socks5://4.4.4.4:1080" ] } ``` 这个判断代理链通还是只判断http通不通，需要注意下， 必须判断代理链

`gost -L red://:12345 -F=mws://www.baidu.com:80?ip=122.223.22.11` `iptables -t nat -A OUTPUT -p tcp --match multiport ! --dports 12345,80 -j DNAT --to-destination 127.0.0.1:12345` 除了80，12345 端口其他测试都没问题， 但是80端口我日常需要使用，远程连接也需要， 该怎么对特定ip:80进行例外？ 而不是对全部80例外？