这么好看的猫直接挂闲鱼 20 块钱自提就行了，很多人买。
我小区的流浪猫都被邻居挂闲鱼卖了，好看的 20 ，丑的 10 块。

@Foxkeh 区别不大，现在大部分协议在不开 mux 的情况下都是 per connection 创建一个远端 connection ，对于一个境外 IP ，在国内竟然只有单个 SrcIP 去访问，并且连接数和流量都很高。只是为了抓人的话，人肉筛一遍这些特征就行了。
不过我准备改成 fallback 到 nvr 的 https 试试，更符合正常业务流量，我这 nvr 开在公网上快 6 年了，运营商也没管过。

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

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

内置反诈是趋势，要么 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 冲击小。
而且搞嵌入式的工资相比互联网差多了🤣大多数人也不爱上网冲浪到处叭叭