Replies: 18 comments 46 replies
-
转naiveproxy吧,用了好几年的tls+ws前天被封了443 |
Beta Was this translation helpful? Give feedback.
-
SS-AEAD、Trojan 存活情况要比 VMESS+ANY+TLS 好的多,统计了十几台各个国家地区的服务器,VMESS 这边仅剩几个北美的服务器存活,而 SS-AEAD、Trojan 基本上都存活下来了。 不只是 443 被封锁,使用非标准端口,一样被封锁。443 不是神,在 GFW 面前任何端口都没有区别。 我在 10 月 2 日就观察到了被封锁现象,不只是 10 月 3 日,但是大规模封锁是在 10 月 3 日中午。10 月 2 日的封禁方式是封锁该 IP 的全部协议,10 月 3 日则大多表现为只封禁端口,而不封锁整个IP。在 10 月 2 日后侥幸存活下来的服务器,大多都采用封禁端口的形式。即使更换端口,虽然短时间可以连通,但是会在几个小时内,端口继续被封禁。 而将这些服务器转而使用 VMESS+ANY,即不加 TLS,则可以正常使用不会被封禁。自 10 月 3 日至今,这些不使用 TLS 的 VMESS 服务器仍然存活。也有部分服务器使用了 Trojan,目前也是存活完好。 有理由怀疑,VMESS 的 TLS 在实现方式上是不是有特征可供利用。 完全解释不通 Trojan TLS 基本不会被封锁的现象(有人指出 Trojan 有包长度混淆,可能是因此受影响很小,或者说用户量比较小,先放行,待GFW引导用户换到Trojan得到足够多的样本再训练识别),均使用了相同的 v2ray 核心,以及大多数人使用 Clash 核心作为客户端。 |
Beta Was this translation helpful? Give feedback.
-
是两个批次 第二次 是10月3日 封443端口, 不仅仅是vmess + tls + ws, vless + tls + ws 一样封. 但如果是Nginx作为前置 转发path 到 vmess ws 或 vless ws 一切正常. 同时 vless xtls tcp fallback to 80 nginx 的一切正常 总结 没有识别出具体协议, 只是根据流量过大 而且没有网站或简单页面 作为前置. 使用web服务器作为前置是必要的. 这两次行为也很好理解, 第一次是没有fallback到页面, 直接封IP, 后来大家一看都加上了nginx 用上了443, 正好钓鱼 在来个第二次封443 让你用443做网站伪装. 一步一步走入圈套. 但vless 在前 fallback 80 还是没有nginx 在前面安全. 至于trojan 或ss 没有被封 可能是下一次的钓鱼计划. 一步一步让你换协议 走入圈套. 一句话 使用我脚本安装非常稳. 最安全的还是nginx前置, 其实vless 在前面 xtls也一样稳, 伪装网站不要太简单 最新发现 : 现在出现一种没有被封IP或端口 但还是无法连接的情况, ssh 都可以登录 端口都正常, 但还是连不上的情况, 就是白名单了, 把自己搞成局域网了, 可能某些IP段可以连 但某些根本就无法访问外网的情况. 就是说被封的原因就是针对某些VPS服务上的IP段封的. 像大的AWS, AZure, Linode 都没事 一切正常. 10月6日更新 第一批被封的IP 已经全部解封, 全部恢复正常. GFW是有弱点的 就是性能. 不可能一个硬件对抗全世界的服务器. 就是说 特殊情况下 只能解封换取性能 来封下一批. |
Beta Was this translation helpful? Give feedback.
-
Vless+WS+TLS 稳如老狗,一个月300G流量也没事,可能是因为我从不用ssh直连。 |
Beta Was this translation helpful? Give feedback.
-
traefik + vless + ws在10.3号被封了443,换成8443用到现在没问题。我在2号左右一天跑了300G流量,感觉是流量过大被盯上了 |
Beta Was this translation helpful? Give feedback.
-
这几天重新搭vmess tls websocket,和你一样,半小时被阻断, |
Beta Was this translation helpful? Give feedback.
-
我今天直接用ip vmess ws就能跑啊 { |
Beta Was this translation helpful? Give feedback.
-
vless + tls + ws + nginx 伪装域名 目前存活OK |
Beta Was this translation helpful? Give feedback.
-
软件在Windows上底层用于操作TLS链接的是那个Go库?可以以此着手看一下ClientHello指纹的问题。我暂时不理解,假如最终都是走的操作系统网络栈,ClientHello的指纹会因何而不同 |
Beta Was this translation helpful? Give feedback.
-
ja3指纹主要说的是客户端,服务端只是协商后回答,真要说指纹被识别应该去客户端那问。 |
Beta Was this translation helpful? Give feedback.
-
月流量16.83 GB |
Beta Was this translation helpful? Give feedback.
-
您好,我想請教一個問題,如果是使用非標準端口,采用 Vmess_TLS_WS_Nginx (僞裝域名)這種方式會不會不安全呢? |
Beta Was this translation helpful? Give feedback.
-
20230501更新,最近一周nginx+tls前置+vless+ws已被gfw识别并阻断。现象是只要使用xray/v2ray连过服务器,443端口立马被全国屏蔽,浏览器也无法访问服务端web页面,隔一段时间越约20-60分钟后恢复,国外访问一切正常。也就是说gfw能够根据流量特征精准识别tls流量是否是浏览器发出。另外用浏览器频繁重试访问web页面能加快恢复 |
Beta Was this translation helpful? Give feedback.
-
现在用nginx+v2ray(vmess)+tls+ws路径分流用个几小时就被封,但是同样的配置用apache2+v2ray(vmess)+tls+ws路径分流就不会,nginx和apache2都伪装站点了的 |
Beta Was this translation helpful? Give feedback.
-
nginx+v2ray(vless)+tls+ws |
Beta Was this translation helpful? Give feedback.
-
建议使用如下防火墙规则,保护代理端口,防止端口被任意IP连接和探测 -A INPUT -p tcp -m multiport --dports 34567 -m conntrack --ctstate NEW -m recent --update --seconds 1800 --name PROXYOPEN --mask 255.255.255.255 --rsource -j ACCEPT |
Beta Was this translation helpful? Give feedback.
-
洗流量跟洗钱一样,要是人城管看到你的螺蛳粉店每天进出上千个美女,就要搞搞你告诉你服务跟流量不匹配 你搞TLS+WS,人家来到你的网站上看不到足够的服务‘证据’来支撑你那些玩游戏和看视频和浏览网页所产生的流量就有要搞你的心了,人家的正常流量它有加密,有明文,有它作为一个应用的一个流量特征,要是这个流量特征是像许多个应用塞到一起,那就是代理了 国家集中力量办大事的水平我们知道,要被中国AI检测到,我们必然于设计上存在很大问题吧而且还不好说是谁的责任因为【那是人家AI检测出来的】 |
Beta Was this translation helpful? Give feedback.
-
net4people/bbs#129
基于以上信息,我们推测(但还未进行实证性的测量),这些封锁可能与翻墙软件客户端发出的Clienthello指纹相关。开发者们或许可以考虑采用uTLS。这个https://github.com/net4people/bbs/issues/54,[这篇总结](https://gfw.report/blog/v2ray_weaknesses/zh/#%E7%8B%AC%E7%89%B9%E7%9A%84tls-clienthello%E6%8C%87%E7%BA%B9),以及[这篇博文](https://zhufan.net/2022/06/18/tls%E6%8F%A1%E6%89%8B%E6%8C%87%E7%BA%B9%E6%A3%80%E6%B5%8B%E6%81%B6%E6%84%8F%E8%BD%AF%E4%BB%B6%E6%B5%81%E9%87%8F/)都是关于TLS指纹的,也许会有帮助。
Beta Was this translation helpful? Give feedback.
All reactions