trojan
trojan copied to clipboard
[BUG] 时而断连,报 SSL handshake failed
- [x] 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]
客户端
[ERROR] 127.0.0.1:54880 SSL handshake failed with
Environment 服务端:Debian10 客户端:Windows 10
Additional context Add any other context about the problem here.
今早开始遇到了同样的问题,昨天还是好的。
Environment 服务端:Ubuntu20 客户端:iOS Shadowrocket
注: 服务端是nginx+trojan+ssl (by let's encrypt)。 将trojan替换成trojan-go后,nginx与ssl保持不变,则可以正常使用。
很明显 @klzgrad 几年前的担心终于变成现实了
很明显 @klzgrad 几年前的担心终于变成现实了
墙的再升级吗?我也断连了 trojan-go+ws+tls,换tcp有所改善
今早开始遇到了同样的问题,昨天还是好的。
Environment 服务端:Ubuntu20 客户端:iOS Shadowrocket
注: 服务端是nginx+trojan+ssl (by let's encrypt)。 将trojan替换成trojan-go后,nginx与ssl保持不变,则可以正常使用。
换成trojan-go后依然断连,请问你的配置是什么?
遇到同样的问题,请问有解决方法吗? 手机端打开正常的
我暂时在这做点笔记。
我也有类似情况,但可能跟trojan并没有关系。
TLS直连正常网站,会出现几次reset,然后又恢复正常。reset很明显是GFW注入的。判断依据是(1)连发3个reset,序列号分布均匀;(2)IP TTL与原站点不一致,而且>64。
然后很快就好了
Trojan需要升级啦,7月开始就一直这样了。
会不会跟这事有关:https://www.v2ex.com/t/788719
2021-7-20开始,遇到同样的情况,每开一个网页都会先连不上,然后自动刷新脸上。日志记录ssl handshake failed.
最近2周开始遇到这样的问题,然后把墙外的服务器换了个IP就好了,但是才过了两三天又这样了,基本判定是墙又升级了!
浏览器开启Experimental QUIC protocol 实验特性,可能会有改善
地址栏输入chrome://flags/ 打开Experimental QUIC protocol就好了
我这边就没啥事
遇到这问题的是不是都是电信用户?
估计和IP无关,前段时间出现了,过了几天恢复正常了,今天又来了
我今天也遇到了
会不会是这个原因https://www.v2ex.com/t/799816 时断时续的
会不会是这个原因https://www.v2ex.com/t/799816 时断时续的
不是,这是DNS解析问题,和断连没太大关系。
之前用vultr的 Dallas服务器跑v2ray,一般几个月换一次ip, 最近都不行了。昨天转trojan,一直是这个问题,根本用不了。
我换这个之后稳定了,估计还是要有伪装网页吧? https://github.com/mack-a/v2ray-agent
我的换其他端口就好了,不要用默认的443端口了。
不使用默认443,瞬间修复
不使用默认443,瞬间修复
我的换其他端口就好了,不要用默认的443端口了。
几位是443端口被墙了吧?
不使用默认443,瞬间修复
情况一样,同样电信
不使用默认443,瞬间修复
早就想到到443长期使用会有大流量,肯定会被重点关照的,提议让作者 @GreaterFire 有时间增加个动态端口解决这问题
今早开始遇到了同样的问题,昨天还是好的。
Environment 服务端:Ubuntu20 客户端:iOS Shadowrocket
注: 服务端是nginx+trojan+ssl (by let's encrypt)。 将trojan替换成trojan-go后,nginx与ssl保持不变,则可以正常使用。
墙似乎找到了方法对trojan的连接进行重放攻击,trojan-go的指纹伪造功能对这种攻击有一定抵挡。@GreaterFire
不使用默认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
今早开始遇到了同样的问题,昨天还是好的。 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