[BUG] 时而断连，报 SSL handshake failed

[hasbai]

• I certify that I have read the contributing guidelines and I acknowledge if I don't follow the format below, or I'm using an old version of trojan, or I apparently fail to provide sufficient information (such as logs, specific numbers), or I don't check this box, my issue will be closed immediately without any notice.

Trojan Version
1.16.0

Describe the bug
每次加载新的页面都会断开连接，浏览器报错ERR_CONNECTION_RESET，但刷新后又正常
看日志显示 SSL handshake failed

Logs
服务端
[ERROR] : SSL handshake failed: Connection reset by peer

客户端
[ERROR] 127.0.0.1:54880 SSL handshake failed with:: 远程主机强迫关闭了一个现有的连接。

Environment
服务端：Debian10
客户端：Windows 10

Additional context
Add any other context about the problem here.

[yoursbest]

今早开始遇到了同样的问题，昨天还是好的。

Environment
服务端：Ubuntu20
客户端：iOS Shadowrocket

注：
服务端是nginx+trojan+ssl (by let's encrypt)。
将trojan替换成trojan-go后，nginx与ssl保持不变，则可以正常使用。

[ArcCal]

很明显 @klzgrad 几年前的担心终于变成现实了

[hasbai]

今早开始遇到了同样的问题，昨天还是好的。

Environment
服务端：Ubuntu20
客户端：iOS Shadowrocket

注：
服务端是nginx+trojan+ssl (by let's encrypt)。
将trojan替换成trojan-go后，nginx与ssl保持不变，则可以正常使用。

换成trojan-go后依然断连，请问你的配置是什么？

[jamin83]

遇到同样的问题，请问有解决方法吗？ 手机端打开正常的

[klzgrad]

我暂时在这做点笔记。

我也有类似情况，但可能跟trojan并没有关系。

TLS直连正常网站，会出现几次reset，然后又恢复正常。reset很明显是GFW注入的。判断依据是(1)连发3个reset，序列号分布均匀；(2)IP TTL与原站点不一致，而且>64。

然后很快就好了

[ghost]

Trojan需要升级啦，7月开始就一直这样了。

[Bryan2333]

会不会跟这事有关：https://www.v2ex.com/t/788719

[popococo-hanks-bocan]

2021-7-20开始，遇到同样的情况，每开一个网页都会先连不上，然后自动刷新脸上。日志记录ssl handshake failed.

[binarrii]

最近2周开始遇到这样的问题，然后把墙外的服务器换了个IP就好了，但是才过了两三天又这样了，基本判定是墙又升级了！

[johnshuxian]

浏览器开启Experimental QUIC protocol 实验特性，可能会有改善

地址栏输入chrome://flags/ 打开Experimental QUIC protocol就好了

[Bryan2333]

我这边就没啥事

[Tun2Sucks]

遇到这问题的是不是都是电信用户？

[jamin83]

[jamin83]

估计和IP无关，前段时间出现了，过了几天恢复正常了，今天又来了

[xh116]

我今天也遇到了

[redstoneleo]

会不会是这个原因https://www.v2ex.com/t/799816
时断时续的

[Bryan2333]

会不会是这个原因https://www.v2ex.com/t/799816
时断时续的

不是，这是DNS解析问题，和断连没太大关系。

[wududu123]

之前用vultr的 Dallas服务器跑v2ray，一般几个月换一次ip， 最近都不行了。昨天转trojan，一直是这个问题，根本用不了。

[redstoneleo]

我换这个之后稳定了，估计还是要有伪装网页吧？
https://github.com/mack-a/v2ray-agent

[yangq212607]

我的换其他端口就好了，不要用默认的443端口了。

[liyuan97]

不使用默认443，瞬间修复

[ConfusedLolo]

不使用默认443，瞬间修复

我的换其他端口就好了，不要用默认的443端口了。

几位是443端口被墙了吧？

[Sweet0range]

不使用默认443，瞬间修复

情况一样，同样电信

[LsnmxNB]

不使用默认443，瞬间修复

早就想到到443长期使用会有大流量，肯定会被重点关照的，提议让作者 @GreaterFire 有时间增加个动态端口解决这问题

[yyuurrii34]

今早开始遇到了同样的问题，昨天还是好的。

Environment 服务端：Ubuntu20 客户端：iOS Shadowrocket

注： 服务端是nginx+trojan+ssl (by let's encrypt)。 将trojan替换成trojan-go后，nginx与ssl保持不变，则可以正常使用。

墙似乎找到了方法对trojan的连接进行重放攻击，trojan-go的指纹伪造功能对这种攻击有一定抵挡。@GreaterFire

[yyuurrii34]

不使用默认443，瞬间修复

早就想到到443长期使用会有大流量，肯定会被重点关照的，提议让作者 @GreaterFire 有时间增加个动态端口解决这问题

这样换端口是无法从根本上解决问题的，因为这不会使你的连接绕过GFW的审查名单，GFW目前可能没到100%确认trojan连接的程度，但封锁端口或限速足以满足某一时期的管控需求，即使任何主动侦测手段都无效，GFW也可能通过流量的时间分布和长连接数量等特征来添加可疑列表。
https://gfw.report/talks/imc20/zh/
这篇文章提到，outlineVPN和brdgrd可以通过改变包的长度，以绕过流量检测，达到减少被GFW主动探测。
另外，文中提到，GFW的重放攻击，并不是一成不变的完全重放，有时会改变字节，有时会发送若干组不同字节长度的包，以查看服务器的反应。其中强调了一致性，即服务器对各种relay作出的回应应该保持一致性，按照trojan设计原理，这种回应应该是类似于http error page,既然Trojan尝试模似https作出回应，我所知道的，web服务器不可能只会返回404这一种错误，比如301,那么，我可以假装成审查者，然后向某个疑似代理的https服务器发送特定的包，这个包已确定在正常web服务器中会触发404错误，如果在这个服务器上得到301，我想这应该就是trojan无疑了。
所以，综上就是我认为trojan需要改进的地方。@GreaterFire

[yyuurrii34]

今早开始遇到了同样的问题，昨天还是好的。
Environment
服务端：Ubuntu20
客户端：iOS Shadowrocket
注：
服务端是nginx+trojan+ssl (by let's encrypt)。
将trojan替换成trojan-go后，nginx与ssl保持不变，则可以正常使用。

换成trojan-go后依然断连，请问你的配置是什么？

请打开trojan-go里的指纹伪造功能，fingerprint:"chrome"

今早开始遇到了同样的问题，昨天还是好的。
Environment 服务端：Ubuntu20 客户端：iOS Shadowrocket
注： 服务端是nginx+trojan+ssl (by let's encrypt)。 将trojan替换成trojan-go后，nginx与ssl保持不变，则可以正常使用。

墙似乎找到了方法对trojan的连接进行重放攻击，trojan-go的指纹伪造功能对这种攻击有一定抵挡。@GreaterFire