@fox233 https://github.com/dndx/uip/releases/download/v0.1.6/uip_x86_64-unknown-linux-gnu

文件太多网页上被折叠了

@beihu 现在恢复了，炸了几个小时

@Xusually IPoE 的确是未来，这个问题明显跟 IPoE 也没什么关系，要怪也只能怪这些大厂基于家宽都是 PPPoE 的假设搞出来的奇技淫巧。

就是这种主动探测手段，咋感觉跟某设备很像呢。

@ilovey482i 别说 MSS ，就连 3 层信息比如 TTL 都可以。Cloudflare 展示过一种用 eBPF 获取的方法： https://blog.cloudflare.com/epbf_sockets_hop_distance/
@2397613259qqq 我也想过这个问题，包括手机的流量 MTU 一般也是 1500 的，猜测 MTU 也不是唯一的判断条件，可能只有可疑的 IP 段（比如家宽，IDC ，云主机商）才会 challenge ，毕竟一般爬虫也不用手机流量来做代理。

> 有没有更合适的方法来规避这些探测呢？

MSS clamping 到 1452 有用吗？猜测这种探测包也得有个触发条件，如果每个 TCP 都检查代价太高。也许是先看 TCP SYN 包，MSS 太高怀疑的再二次触发主动探测验证。

这种风控措施都能被你发现，厉害了。

NE 应该是菊花厂的设备，NetEngine

@azhi 别想了，上海联通高上行宽带泛滥，跑 PCDN 怕电费都够呛

理论上这个问题电脑丢了也存在，开全盘加密可解

@Ghonewyn
@tux

Windows 版已经打出来了 https://github.com/dndx/uip/releases/tag/v0.1.6

感谢 amorphobia 贡献 https://github.com/dndx/uip/pull/1

我没有 Windows 系统，希望能有人帮忙测试一下能不能用。

RockPi 5B 挺适合在家里用的

@qsnow6 我觉得你说的很有道理，在 ipip 上测了一下，好像 `stun.l.google.com` 在国内一些地方的确是解析不出来（主要是联通）。

刚发布了一个新版本 `v0.1.5`，在这个版本里默认的服务器已经改为了 `stun.cloudflare.com`，应该会好一些。考虑到国外的用户，不太想用国内的服务器作为默认值，希望理解。

@v2wtf `uip -4` 试试，可能是你的 IPv6 不通

@v2wtf 感谢建议。实际上 G 家的 STUN 服务器在国内用起来也没问题，所以这个默认值也不是完全没道理。UDP 3478 比 TCP 443 被阻塞的概率也低多了。

@qsnow6 实际上 `stun.qq.com` 甚至还做了 GeoDNS 国内分区解析，算是很用心了。可用性不太需要担心，甚至可以顺带作为网络通断的判断。

@0o0O0o0O0o 公益的就难了，大厂 STUN 本来设计的就不是公益服务，所以可用性要靠谱点...国内的公益服务基本都不持久

@qsnow6 没错，我测试 ipip 也经常超时或者跳出来 5 秒盾，总体来说稳定性还是达不到要求。

国内能提供稳定 IP 查询接口的太少了。找来找去还是大厂的 STUN 服务器最稳定，比如 B 站的就是他们用来做直播 WebRTC P2P 的，甚至还写了优化文章： https://www.bilibili.com/read/cv19672394?from=articleDetail ，必然比各种公益性的服务要靠谱点。

为了你一个客户把整个省网流量都调裂开了？移动这运维水平，啧啧。

@RonnyJiang 9929 开了后就是没有公网，/t/903744 里面已经解释的很清楚了。

单连接肯定到不了 2000M 的，多个 TCP 连接负载均衡才能突破 1000M 。iKuai 我不熟悉，我用的是 RouterOS 。