FabricPath

@yulon 那我流量是很大了，我现在 7.5 刀的 2TB （ 1TB ）每个月基本上都能用完，基本每个月都这么大流量，gpt 本身也会产生大量上行。在去年早期实现的时候，我一直在对比和正向 trojan 的性能，在任何观察过的时间点，正向直连 vps 的 trojan 性能都不如反向的 ssh 。

@zxbiao 时代变了，早期是靠流量大小识别的，你直接让 AI 分析 gfw 的代码和已知的规则，就能发现现在审查重点是出海方向的 tls 了。现在除 tls 外，海外主动回连的协议都不是审查重点。



我发现楼上好多人重点搞错了，重点不是 ssh 协议，而是从海外主动回连的公开协议。

https://geedge.report/assets/geedge-tsg-usenix26.pdf 附上今年的研究报告。

顺便补充一下为啥我会用反向的连接，因为去年粗略扫了一遍 tsg 的源码，发现他主要审查的方向是 tls 、quic ，并且从文档和已有的规则集来看，具备明显的境内->境外和境外->境内方向性，审查重点就是境外往境外主动发起的 tls 和 quic 。
但是并没有发现“长连接”，“二元组”等明显的规则，从过去几年只有特殊时期才封二元组来看，这应该是一个 adhoc 的规则集，平时不会启用。

至于为什么是 ssh ，纯粹是因为懒得做实验，ssh 比 frp 更像是正常流量，并且启用之后一直很稳定，也没动力去探索其他协议。
虽然从代码中也没找到明确豁免 ssh 的逻辑，但是从性能测试来看，使用反向的 ssh 会明显比正向的 ssh 隧道更快，且可以稳定复现，说明至少现在部署的 gfw 版本，大概率对两个方向的处理有差异。

@leaflxh 过去 5 、6 年一直用同一个 lightsail ，就今年流量大升了规格才换了 IP ，只有开大会的时候会短时间掐二元组。

@xeonforce 放到过去靠二元组流量特征去无脑掐的年代，这种模式容易被识别，放到现在，从泄露的 gfw 代码来看，中心都放到去扫描前 N 个报文的特征，而且 gfw 用的 dpdk ，dpdk 本身要做包缓存就需要消耗巨量的 hugepage ，不做包缓存又解决不了 SNI 分片。

从 gfw repo 的论文也能看出来，gfw 是对连接做了缓存的，并且在高峰期还会降级

@est 我关心对方 kpi 干嘛，被封了就继续用 cdn 接入就行了，本来家宽有公网就少，提供一个思路和测试结果而已，不知道你要杠啥。

@est 你自己实现协议不就是为了特征少吗，因为国内没多少人有公网 IP ，所以只是检测重点不在这里；如果要检测梯子流量，那太容易了，只要二元组流量过大、连接数过多，直接掐了就行了。
@nomansky 就是因为特征明显才猜测临时进了豁免通道，并且 ssh 建连接的频率极低，也比非 mux 情况下的新建连接数量少得多；非公开协议，那太明显了。
@yeyeye 就是因为国内有公网的少。相比伪装成正常的流量，之前最开始灰度接反向 ssh 的时候，和走 cloudfront 的正向连接做负载均衡，开会的时候会直接基于二元组封禁到 cloudfront 接入点 IP 的连接（不清楚非公网 IP 是否也会使用二元组封禁），但是 ssh 隧道还活着。

此外基于 gfwreport 过去几年的报告来看，gfw 审查模型多检测连接前 N 个报文，对于超长时间的长连接来说，没明显感知到会中途检测的情况。包括之前使用 mux 的时候，也观察到新建连接超时，存量连接能正常通信的情况，不过没定量评估正向长连接的稳定性，纯感觉。

@zizon 正向的 ssh tunnel 和其他协议一样，只能跑到 400Mbps ，速度明显会低一截。

@hanfengzxh 我没试过其他非标协议。如果我去搞 gfw 的话，看到非标准流量特征，且长期 SrcIP 单一、连接 cps 搞、带宽大，会考虑直接掐掉。
其实正向连接大家都玩不出啥花儿了，gfw 也不需要太复杂的策略，如果一个目标 IP 常年有入站请求，并且 src ip 很单一，那很容易就可以判定为是梯子了。
现在反向连接审查得少，我估计纯粹是因为国内家宽有公网的不多。

应该是你锁出问题了？或者带摄像头？
我看了一下我这个锁 4 、5 年了（不带摄像头，全自动），我有印象就换过两次电池，就小米自家那个最便宜的 5 号电池。

因为你注册没完成，光猫的标准操作