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 号电池。

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

内置反诈是趋势，要么 iphone ，要么外版。
国内 android 未来 100%包含取证后门。相比 iphone ，只要你能扛得住电，就没人能从 iphone 里面提取出数据。

你的短信转发是用短信转发的？这必定风控。
我早期在测试 asterisk 的时候，多打了几次电话就被停机了，测试完成后，到目前运行了两年多，非常稳定。
短信用 bark 吐出来，发送短信用 tg bot ； ios 订阅的 bria 接打电话。

safari 的三击段落选取会选中一大片空白，这是真的恶心

@miya0923 你做不到就没办法排查，你随便换任何一家 CDN ，在没有 mtr 明确证明是到 cdn 入站那跳中断的情况下，都不会给你处理这种零星问题。

@miya0923 那你也要提供是对方问题的证据，你明显给出的证据不足以证明是对方的问题。给 mtr 是常规操作，估计你也没用过 aws 、gcp ，你这种问题不带 mtr 去 aws 、gcp 提单，对方根本不会接人工。我们是 aws 大客户，提网络问题必带 mtr 。

要 mtr 是正常的，不然对方完全无法分析。
包括你提到的“未响应的截图”，先不说里面有没有明确的“connect timeout”（代表 tcp 建联超时）还是“request timeout”（代表请求超时），即使有，你也不能保证是用户自己 DNS 的解析结果有问题。
像这种零星的问题，你不提供明确的证据，本来就没法查，即使你提供了证据，这种零星的问题，腾讯自己很有可能也处理不了，大概率是运营商的问题。

搞硬件（嵌入式）需要有实体硬件，需要接 jtag 调试，所以受 AI 冲击小。
而且搞嵌入式的工资相比互联网差多了🤣大多数人也不爱上网冲浪到处叭叭

这类工具太多了，在大部分地区的光猫都是默认对称型的情况下，几乎没可能直连，那么都走服务器中转的话，前期需要巨大的边缘节点的投入，这部分成本高、付费意愿低，很难盈利吧。
比如用国内的情况举例，ToC 的用户画像：
* 网络知识强：改全锥形，用现成工具打洞（或者用你的免费打洞能力），付费意愿低
* 网络知识弱：组网场景少，国内带宽成本高，即使有付费意愿，也不愿意承担每个月上百元的成本

ToB 的用户，我更愿意选择成熟的蒲公英，而且还有现成的路由器盒子，边缘站点直接放个路由器去组网就行了；边缘节点更多，权限管理更成熟。

没看懂和网盘的区别是什么，在超大规模的用户量的情况下，同样约等于每个人都是在为自己那份存储买单，你的方案只是把底层计费方式暴露出来了，用户在使用的时候需要考虑的东西更多了，也许体验还不如网盘月费包干。
通过“用户协议”干掉上传纯私有文件的那部分“刺头”用户就行了。

@YGHMXFAL 那必然断的，而且是多级封，机房看你上传高就会直接在 olt 上封 loid ，离谱的一批。好在上海联通因为 pcdn 被封了之后可以无责拆机。