反DPI措施应该可以防止IP暴死

[louiesun]

建议停止简单的改host行为，加入反DPI措施，明文的sni将导致极简单的机器ip封锁。
请至少套一个TCB帧置乱或者TLS+TCP分片使用，不然IP会越来越少。
参考项目：
GhosTCP
TLSgragment

[louiesun]

有迹象表明墙的封锁机制是发现机器DPI违规sni后短时间封锁+人工决定长期封锁。

[GoodCoder666]

接管系统的 TCP 连接显然超出了本项目的范畴（如上所说，有现成项目）。不过，我可以考虑添加测速/扫描时启用反 DPI 措施的选项。

希望您能提供进一步分析。

[louiesun]

接管系统的 TCP 连接显然超出了本项目的范畴（如上所说，有现成项目）。不过，我可以考虑添加测速/扫描时启用反 DPI 措施的选项。

希望您能提供进一步分析。

希望在首页加一句尽可能不要只改host。我觉得这是有用的，代价不大，好处很大。

[louiesun]

ipv6再扫扫说不定其他google服务也可以用。

[louiesun]

@GoodCoder666 强烈建议现在取消掉写入host的功能。
另外：除了扫ip外，还可以用不同国家的dns去查某个域名（因为这样可以确保扫到的ip是有这个服务的）。
我们知道墙是主动探测，所以中国人不用大概率就没有被封。
facebook这里我已经成功了。

[UjuiUjuMandan]

违规sni

本项目的翻译API端点是违规sni吗？

[louiesun]

违规sni

本项目的翻译API端点是违规sni吗？

googleapi.com包是的呀，就算不发rst也可以记到小本本上时候封ip

[UjuiUjuMandan]

googleapi.com包是的呀，就算不发rst也可以记到小本本上时候封ip

如果是为什么不发RST？

[louiesun]

googleapi.com包是的呀，就算不发rst也可以记到小本本上时候封ip

如果是为什么不发RST？

不知道，可能墙不想发。但是你得想墙为什么来封你的IP？他怎么知道这个ip有问题，https是加密的，唯一明文的是sni。
vps浏览被识别后被封的流程是：先RST，后封端口最后封ip。本质上一切源头是流量被识别了。

你到时候加个前置代理就会发现ip根本不死。我靠这个已经稳定用全套google服务一个礼拜了，比那一天就死的host好多了

[UjuiUjuMandan]

你到时候加个前置代理就会发现ip根本不死。

这和我观测到的不同，phantomsocks 我一直在用，IP过几周就得重新扫描。

[louiesun]

也许吧，再观望观望，我的时间确实太短了。但是我看之前帖子有一天就死的，说明搞搞还是有用的。。

[GoodCoder666]

@louiesun 嗯，先不急，这个issue我pin上了，解决方案还有待进一步观察讨论

[maoist2009]

@UjuiUjuMandan 这事有很多可能。

1. 和墙没关系，对面换ip了
2. 墙很聪明，在钓鱼（实话说，这东西可以像封tor一样主动探测）
3. 我们的反dpi有问题，有一定概率发墙可以识别的包，时间长了就死
4. 墙更聪明，故意留下来改hosthttps://zhuanlan.zhihu.com/p/657810016)，有人扫IP改host，正好扫到你用的，ip就死了。（accesser issue里有三个好久都没死，可能因为是非标端口（不是443），一般人扫不到）

[louiesun]

你到时候加个前置代理就会发现ip根本不死。

这和我观测到的不同，phantomsocks 我一直在用，IP过几周就得重新扫描。

现在我的google cloud 1445端口ip还没死，70ms延迟

[louiesun]

你到时候加个前置代理就会发现ip根本不死。

这和我观测到的不同，phantomsocks 我一直在用，IP过几周就得重新扫描。

现在我的google cloud 1445端口ip还没死，70ms延迟

死了一个ip。笑死了，晚8点整的事情，被空路由了。
不知道是不是因为6点左右我给他443端口发了一个裸的http1.1包，然后他给我发了个302到google.com的包。（希望是这样。当然，我至始至终没有被rst过）