此讨论怀疑tls+ws已经被GFW精准识别的判断是否靠谱

[whlweb]

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指纹的，也许会有帮助。

[qiangliu8183]

转naiveproxy吧，用了好几年的tls+ws前天被封了443

[cjqhg2012]

转naiveproxy吧，用了好几年的tls+ws前天被封了443

naiveproxy也不行，换成naiveproxy，ipv6直接IP都没有了，就用了两天，没用naiveproxy之前最多是封443端口，用了naiveproxy后，整个IP都没有了。

[betaxab]

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 核心作为客户端。

[yyuurrii34]

我一台trojan-go（未设置utls）和一台xray-vless+xtls都被封端口，更换端口后，过大概一天左右，新端口都被封。
另有一台用的shadowsocks-libev(AEAD加密)直接被封IP,更换IP后同样，但被封的周期不同，是两天左右。
最近把xray和trojan-go的服务端和客户端均更新了（使用了utls指纹设置，trojan-go最新版默认开启utls指纹）大概24号左右，这台trojan服务器依然会被封端口。
我觉得应该就是用作代理的tls流量被识别了。

[linzc66]

对得，tls被识别了，我自建vmess+tls+ws 然后nginx前面做个网站，刚刚建好网站都还能访问，一旦v2ray开始连接，443端口秒封

[cumcw97u4nba3ykv]

敏感时期是不是大流量走境外都会被封？？

[gydchenxiao]

现在trojan协议安全吗，好像可以被识别了

[lingluan5210]

24年9月1日回答 目前vmess+tls 无伪装裸奔半年整 无封端口ip 日最低流量129MB 日均最高21G> 现在trojan协议安全吗，好像可以被识别了

[xiejay97]

tls已被封

[jinwyp]

是两个批次
第一次是 9月30日 vmess + tls + ws 没有fallback (vmess 没有fallback 只能nginx前置, 这里fallback 指没有使用nginx前置) 的 直接封IP, 封了20台, 只要是直连没有 Nginx作为前置的 一律封IP , 所有端口都无法使用. 包括ssh登录都无法使用.
这里有个小情况是 流量小的一台服务器没有被封.
所以 被封的原因究竟是流量大了,还是由于电脑上装了360,qq,微信国产软件上报导致的被封. 无法得知. 但有nginx fallback的没有被封.

第二次 是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是有弱点的 就是性能. 不可能一个硬件对抗全世界的服务器.

就是说 特殊情况下 只能解封换取性能 来封下一批.

[jinwyp]

大佬我就是用的你脚本的17选项安装，换了自己的网站，只不过用的是vless+tcp+xtls，这波还是被封IP了。开了clourflare的cdn能救回来，后续要注意什么？cdn能撑多久？
封IP 是直接SSH都连不上了吗？ 如果SSH可以连上就是封的端口， 可以换端口试试

目前看来只要是中转 都没事。 但CF经常被封 可以用优选IP 换IP就可以了

[mckuhei]

我用trojan就被封了，并且有apache作为fallback

[isyekong]

我认为与nginx没有直接关系，我的节点均有nginx作为前置，但几乎无一例外的封锁了443.
甚至影响了正常的https网站，请看我这个回复 net4people/bbs#129 (comment)

[jinwyp]

我认为与nginx没有直接关系，我的节点均有nginx作为前置，但几乎无一例外的封锁了443. 甚至影响了正常的https网站，请看我这个回复 net4people/bbs#129 (comment)

没有前置的第一波直接封 IP , 和封443 是两回事, 很多人还是没有弄清楚.
我写的那么多就是要大家知道 不要被引诱进入圈套. 现在443 很多端口都已经放开了.

[isyekong]

我认为与nginx没有直接关系，我的节点均有nginx作为前置，但几乎无一例外的封锁了443. 甚至影响了正常的https网站，请看我这个回复 net4people/bbs#129 (comment)

没有前置的第一波直接封 IP , 和封443 是两回事, 很多人还是没有弄清楚. 我写的那么多就是要大家知道 不要被引诱进入圈套. 现在443 很多端口都已经放开了.

我这里正常建站的443端口依旧是封锁状态，同时有几个服务器是被单向封锁（全部协议、端口），即可以国内数据可以传送给境外vm，但是境外vm数据无法传回境内

[Diffused7245]

Vless+WS+TLS 稳如老狗，一个月300G流量也没事，可能是因为我从不用ssh直连。

[isyekong]

猜测对于日常使用翻墙比较多的IP段，是这次特别关照的对象

[diya-he]

我已经无了，无赖套用CND

[Diffused7245]

猜测对于日常使用翻墙比较多的IP段，是这次特别关照的对象

173.82段很热门吧，美国mc机房，我跑softether都不封，估计是和ssh流量有关，外面有个正常网站。

[hr3lxphr6j]

traefik + vless + ws在10.3号被封了443，换成8443用到现在没问题。我在2号左右一天跑了300G流量，感觉是流量过大被盯上了

[isyekong]

我在10月4日使用 Vultr New Jersey DC 搭建了vless+ws+nginx ssl，半个小时就被阻断了443

[swatchion]

vultr 已被盯了

[jiechic]

这几天重新搭vmess tls websocket，和你一样，半小时被阻断，
但是朋友用一件脚本答出来的就没有问题，同443，
我特意去看了一键脚本的关键配置。感觉是sniffing的配置上，一般人估计很少设置这个设置然后被检测到
https://github.com/233boy/v2ray/blob/master/config/server/ws.json

[isyekong]

你朋友用的是233boy的脚本嘛

[jiechic]

你朋友用的是233boy的脚本嘛

是的，用的233的脚本，caddy的proxy和我原来的不一样，v2ray的配置也有点不一样，我今晚重新弄了一遍，看明天能活多久，目前我用朋友的节点，现在还没被封。
昨晚我原来的方式弄上去，半小时就封了。

[olbb]

我有台用的233的脚本，也被封了

[hinhe]

怀疑是kcp导致的

[DCA1909]

我今天直接用ip vmess ws就能跑啊
啥tls cdn都没加 直接裸奔

{
"address":"我的IP",
"alterId":0,
"host":"",
"id":"11c1b062-95ef-4b43-e65f-75fc7457e448",
"network":"ws",
"path":"/",
"port":52290,
"protocol":"vmess",
"ps":"T1",
"security":"auto",
"sni":"",
"tls":"none",
"type":"none"
}

[isyekong]

这个东西一直比较随缘....有的节点裸奔vmess+tcp也没事

[iamqk]

vless + tls + ws + nginx 伪装域名 目前存活OK
都是最新的v2ray内核

[iamqk]

都是国外ip，443直连

[cumcw97u4nba3ykv]

用ip裸奔早晚要被拉黑

[isyekong]

用ip裸奔早晚要被拉黑

CF不是让你这样滥用的，他已经TLS over TLS 了，除非无差别封锁443才会拉黑

[iamqk]

用ip裸奔早晚要被拉黑

我的意思是不走CF等CDN中转，还是有域名的

[cumcw97u4nba3ykv]

啊，我还以为就 www.baidu.com@ip 那种伪装。

CF的origin CA十五年有效， 省去了自签的麻烦，还更规范

[notsrlz]

软件在Windows上底层用于操作TLS链接的是那个Go库？可以以此着手看一下ClientHello指纹的问题。我暂时不理解，假如最终都是走的操作系统网络栈，ClientHello的指纹会因何而不同

[netheril96]

Go用的不是系统的TLS库。Chrome也不是。

[Septrum101]

ja3指纹主要说的是客户端，服务端只是协商后回答，真要说指纹被识别应该去客户端那问。

[DreamForestGTA5]

月流量16.83 GB
vless + ws + tls 启用utls
12.31被封443端口

[meilin96]

同一天，今天好像被放出来了

[tokoshiekou]

您好，我想請教一個問題，如果是使用非標準端口，采用 Vmess_TLS_WS_Nginx （僞裝域名）這種方式會不會不安全呢？
目前，有發現 Kitsunebi 沒有更新導致出現 MD5 驗證不通過，如果是設置服務端環境，將强制關閉 MD5 驗證是不是有潛在風險呢？
我不是很瞭解，所以向各位請教這些問題，渴望得到各位大佬回復，非常感謝

[mydogshitgold]

IMO it is illogical not to use a well-known ports for WebSocket Secure transport as it breaks plausible deniability, makes you stand out in common HTTPs traffic and probably makes it easier for adversaries to detect and block your V2Ray traffic.

[tokoshiekou]

This is a very clear answer, thank you very much. ❤

[mydogshitgold]

At present, it has been found that Kitsunebi has not been updated, causing MD5 verification to fail. If the server environment is set, MD5 verification will be forcibly turned off. Is there a potential risk?

Possibly not if you are not using self-signed TLS certificates. You should definitely wait for an update if your V2Ray traffic is in cleartext.

[tokoshiekou]

I didn`t use self-signed method, I use a certificate issued by CA. Thank you very much for your help in answering my questions. 💖

[SandroDickens]

20230501更新，最近一周nginx+tls前置+vless+ws已被gfw识别并阻断。现象是只要使用xray/v2ray连过服务器，443端口立马被全国屏蔽，浏览器也无法访问服务端web页面，隔一段时间越约20-60分钟后恢复，国外访问一切正常。也就是说gfw能够根据流量特征精准识别tls流量是否是浏览器发出。另外用浏览器频繁重试访问web页面能加快恢复

[Yofo-me]

现在用nginx+v2ray(vmess)+tls+ws路径分流用个几小时就被封，但是同样的配置用apache2+v2ray(vmess)+tls+ws路径分流就不会，nginx和apache2都伪装站点了的

[Yofo-me]

nginx甚至几分钟不到就封了

[whlweb]

被封的一个AWS一个搬瓦工，都是用的Caddy

[iamqk]

nginx+v2ray(vless)+tls+ws
443被封
稳定运行近一年
不过最近快到期了
考虑更换一个供应商

[lingluan5210]

换个端口试试 banip还是端口 就怕banip段恶心还难找出问题

[Ironieser]

不过我现在只开启dns代理，不开cdn代理，iptest显示不能连接，但实际上域名能正常访问，也能正常用

[LucasHoo]

我也是这个，ip没被封过，只封端口，封了就换个端口，封的时间随机

[lingluan5210]

最近墙力度大了 十月风口吧> 我也是这个，ip没被封过，只封端口，封了就换个端口，封的时间随机

[Xyncgas]

应该自动换端口

[changeflyhigh]

建议使用如下防火墙规则，保护代理端口，防止端口被任意IP连接和探测
#ICMP相关
#windows默认ping包大小可关闭proxy端口
-A INPUT -p icmp -m icmp --icmp-type 8 -m length --length 60 -m recent --remove --name PROXYOPEN --mask 255.255.255.255 --rsource -j ACCEPT
#linux默认ping包大小可关闭proxy端口
-A INPUT -p icmp -m icmp --icmp-type 8 -m length --length 84 -m recent --remove --name PROXYOPEN --mask 255.255.255.255 --rsource -j ACCEPT
#接收 1996 大小的包可以打开proxy端口34567
-A INPUT -p icmp -m icmp --icmp-type 8 -m length --length 2024 -m recent --set --name PROXYOPEN --mask 255.255.255.255 --rsource -j ACCEPT

-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
-A INPUT -p icmp -j icmp-flood

[Xyncgas]

洗流量跟洗钱一样，要是人城管看到你的螺蛳粉店每天进出上千个美女，就要搞搞你告诉你服务跟流量不匹配

你搞TLS+WS，人家来到你的网站上看不到足够的服务‘证据’来支撑你那些玩游戏和看视频和浏览网页所产生的流量就有要搞你的心了，人家的正常流量它有加密，有明文，有它作为一个应用的一个流量特征，要是这个流量特征是像许多个应用塞到一起，那就是代理了

国家集中力量办大事的水平我们知道，要被中国AI检测到，我们必然于设计上存在很大问题吧而且还不好说是谁的责任因为【那是人家AI检测出来的】