5e2t

> @5e2t 针对河南 GFW 和广州国际出口 GFW 测试过 tlshello 分片：[XTLS/Xray-core#2426 (comment)](https://github.com/XTLS/Xray-core/issues/2426#issuecomment-1719685919) > > 我的观点是这些分片 **可能可用，但 GFW 并不需要重组它们，目前来说，一个报文只含一部分而不是完整的 client hello 即为异常** > > _@5e2t tested tlshello fragmentation against Henan GFW and Guangzhou...

理论上要是用hex string来识别的话(iptables可以做到)，则VLESS-TCP不开TLS的翻墙流量，以及server name写在第二个clienthello分片的流量都能被识别，但是直接靠16进制数对应的字符来识别域名肯定会造成流量的误伤吧。GFW应该肯定不会维护我跟目标IP的连接状态，也就是说gfw不管我有没有给对方发过syn，也不管我在这条连接上跟对方通信了多久，只看流量是不是clienthello，或者HTTP请求。那也就是说这种情况下用hex string来识别，必然造成流量的误伤(虽然我不知道概率是多少)........... *Theoretically, if you use hex string to identify the traffic (iptables can do it), then the fact that VLESS-TCP does not open TLS circumvention traffic, as...

@RPRX 之前 河南数据流量网络上的墙 能识别出开了TFO的流量的 clienthello，应该就是因为 数据流量网络上的墙 会看 headerlenth，就是那个一比特代表4字节的字段，4个比特都置1 也就是代表整个报头最大60字节的那个字段 所以说并不是 河南数据流量网络上的墙，特别地对TFO流量做了应对，反倒说明 这个墙是不维护连接状态的。 也就是说，我与某个IP 某个端口建立连接以后，发送 SNI不位于黑名单中的 clienthello握手包，通信一段时间以后，在这条连接上，再发送一个 SNI位于黑名单中的 clienthello握手包，应该是一定会收到阻断的。 所以固定宽带网络上的墙为什么那么傻，连HeaderLenth都不看（兴许是故意不看的.............） *Previously, the wall on Henan's data traffic network was able to...

@RPRX 会看HeaderLenth当然也算不上先进~~，之前我对计算机网络知识的了解还不够，所以才觉得河南数据流量网络上的墙 先进，现在看来，这一切似乎都是故意的~~ *Looking at HeaderLenth is certainly not considered advanced~~, earlier I did not have enough knowledge of computer networks, and that's why I considered the wall on the...

@RPRX 那么问题来了， TCP Timestamps和TCP Fast Open均绕不过 河南数据流量网络GFW的SNI阻断的原因已经知道了，就是无状态+会看HeaderLenth， TCP Timestamps和TCP Fast Open均能绕过河南固定宽带网络GFW的SNI阻断的原因也知道了，是无状态+不看HeaderLenth 那么 TCP Timestamps绕不过北上广出口GFW的SNI阻断，TCP Fast Open可以绕过北上广出口GFW的SNI阻断，是说明北上广出口GFW是无状态的还是有状态的，到底是看HeaderLenth还是不看HeaderLenth................ *So here's the question. The reason why TCP Timestamps and TCP Fast Open cannot...

@RPRX 无论是河南固定宽带网络上的GFW还是河南数据流量网络上的GFW，都能识别出servername位于第一个clienthello分片的TLS握手，并且 河南GFW的行为与 tcp的 HeaderLenth高度相关联， 我有很大的信心确认，河南GFW是靠 应用层的前几个或前十几个字节来识别TLS Clienthello的................ *Both the GFW on Henan's fixed broadband network and the GFW on Henan's data traffic network are able to recognize TLS handshakes...

@RPRX 北上广出口GFW识别不出 servername 写在了第一个clienthello分片的TLS握手，更像是”有状态“ 行为...... TCP Timestamps绕不过北上广出口GFW的SNI阻断， 只能说明 北上广出口GFW会看TCP HeaderLenth。 前面已经知道了，无状态+看HeaderLenth可识别TFO的clienthello， TCP FastOpen可以绕过北上广出口GFW的SNI阻断，大概也许说明了 TCP FastOpen的clienthello流量无法被GFW识别为syn，或者说，被识别为Syn了，然后就忽略了这个包的应用层数据了.......... 就是说只能说明北上广GFW是有状态+看HeaderLenth的。。。。 *Northbound exiting GFW can't recognize TLS handshakes where the servername is written in the...

@RPRX 北上广出口GFW 可能会维护连接状态，就是说，以每条TCP连接 为单位，只看 每条连接的前几个包，或者干脆是只看客户端发的第一个包............，如果客户端发的第一个包 不触发阻断，那么 此条连接后续所有通信 内容 将不再 被 检测.............. （以上为纯粹的猜测~~~~~~~~~） *Northbound exiting GFW may maintain the connection status, that is to say, in terms of each TCP connection,...

@RPRX 我个人认为 TCP Fast Open之所以能绕过 北上广出口GFW的SNI阻断，是因为北上广出口GFW 期望看到syn用以维护连接状态，然后syn包的应用层数据就理所当然的忽略掉了（因为在等着看后面一个包是不是Clienthello..........）。 而河南GFW 由于不维护连接状态，则期望看到的是TLS Clienthello握手包，所以 这就是同样的一个开了TCP Fast Open的TLS clienthello握手包，在 河南GFW和国际出口GFW那里有不同的表现的原因吧~~~ *Personally, I think the reason why TCP Fast Open bypasses the SNI blocking of the...

同样的一个开了TCP Fast Open的TLS clienthello握手包，在北上广出口GFW眼里是 syn， 在河南GFW眼里是TLS clienthello握手包。 *The same TLS clienthello handshake packet with TCP Fast Open on is a syn in the eyes of the Northbound exit GFW and...