钓鱼 TLS 攻击的可行性

[KanakoMikami]

如果我的理解没有问题的话，xtls 在满足条件时不会加密 tls 目标连接。如果构造钓鱼 tls 服务器，在正常完成 tls 握手后就开始发送特定数据，尽管数据会被客户端拒绝，但是数据内容对中间人可见，中间人通过过滤内容就可以识别与钓鱼服务器的连接。如果钓鱼服务器国内不能访问，那么只有通过 xtls 访问时特征数据才会经由国内网络传输，可以据此识别 xtls 服务器。

这种攻击需要客户端主动访问钓鱼服务器，但是如果将服务器链接作为自动加载的资源文件投放在国内常用网站，就有可能导致很多客户端在无意中访问。因为钓鱼服务器本来就不在国内，服务器端针对回国的分流无效。移动端的分应用代理有效，但是网页端分流也无效（不存在“分网页代理”，代理工具无法得知发起连接的网页）。

[RPRX]

大可不必，我有一个更优的钓法：“国内常用网站或客户端”向一个“境外钓鱼网址”发送 ID，再去看这个 ID 是哪个 IP 发的

所以钓鱼当然是可以钓的，但我的钓法能钓不止 XTLS（更通用），还不会触发 TLS 错误（更隐蔽），还无需过滤流量（更高效）

“更隐蔽”还体现在，其实你网站上简单挂个国外的流量统计就相当于开始钓了，这个也属于“识别你，与协议无关”系列

[KanakoMikami]

大可不必，我有一个更优的钓法：“国内常用网站或客户端”向一个“境外钓鱼网址”发送 ID，再去看这个 ID 是哪个 IP 发的

所以钓鱼当然是可以钓的，但我的钓法能钓不止 XTLS（更通用），还不会触发 TLS 错误（更隐蔽），还无需过滤流量（更高效）

“更隐蔽”还体现在，其实你网站上简单挂个国外的流量统计就相当于开始钓了，这个也属于“识别你，与协议无关”系列

你这个方法不能直接找到出国连接去确定国内用户和用于出国的 sni、目标 ip 和端口的组合（是“不能直接”，不是“不能”）。如果国外经过中转就更难找到。这里说 xtls 是因为只有这个直接用于出国。以及如果我的理解没错的话，你这里的 id 只由投放的网页决定，如果网页同时也提供给国外访问，就无法区分正常流量和代理流量。

[RPRX]

为了防止上面那样的反复修改我就不引用了

首先，审查者的最终目的是找到翻墙服务器，那么我的方法肯定是更优的，优点上面已经列出来了。国外的中转绝大多数是 CDN 或一些特殊需求分流，对于前者你的方法完全钓不到，毕竟 XTLS 就不支持 CDN，对于后者不会涉及钓鱼域名，机场可能不同？

其次，ID 那部分你没看懂，“国内常用网站或客户端”当然知道这个 ID 是属于哪个国内 IP 甚至用户的，你的最后一句我没看懂。

最后，如果你就是想抓到单个连接，我也可以提供另一个更通用、隐蔽的方法：特殊的难以被 padding 掩盖的收发流量 pattern。

[KanakoMikami]

上面那个反复修改是怎么发生的，我不明白

我的意思是，我的方法可以作为自动加载的资源文件投放，而用这种方法传 id 就有限制，否则就需要用 js 主动传输 id，而且还是不能直接得到出国服务器的 sni 和端口。通过钓鱼服务器能直接得到一台国外服务器的 ip，但是如果有不止一台国外服务器，手动配置中转，就不能直接得到出国服务器的 ip。因为这个 id 只能包含最初客户端的信息，即使检索这个客户端的出站也只能找到下一跳的连接，如果国内也有中转就也不容易从国内流量找到出国服务器。无论如何，这些都需要主动处理，不能直接在出国网关上部署被动检测，所以我说“直接”，当然只是要实现你说的”最终目的“的话也是可行的。

你说的“后者（特殊需求分流）不会涉及钓鱼域名”没看懂。

最后，感觉你说的流量模式仍然可以因为多路复用被覆盖，准确率不会很高，实现难度可能不小。这里能公开说明一下构造方法吗？

[RPRX]

以下内容不是回复你的，你刚发的等下回复

当然我说的这两种方法也是可以在一定程度上结合起来使用的，总之想钓鱼的话有 N 种花样姿势。

对于我说的第一种方法，关于“不能直接”和“不能”，我说一下：钓到了用户就可以去查同一时间他的出境流量，从而抓到单个连接。

普通人正常出境流量是较少的，数据库也可以过滤掉一些 IP，如果怕他剩下的流量还是多，不是还有收发流量 pattern 嘛。

不过“抓到单个连接”这个需求是比较伪的，审查者的最终目的是找到翻墙服务器，除非他要对付很少见的境外中转。

[RPRX]

~上面那个反复修改是怎么发生的，我不明白~

因为你引用的是旧版内容，我改你那条时你又编辑了，我又得改一次

我的意思是，我的方法可以作为自动加载的资源文件投放，而用这种方法传 id 就有限制，否则就需要用 js 主动传输 id，而且还是不能直接得到出国服务器的 sni 和端口。通过钓鱼服务器能直接得到一台国外服务器的 ip，但是如果有不止一台国外服务器，手动配置中转，就不能直接得到出国服务器的 ip。因为这个 id 只能包含最初客户端的信息，即使检索这个客户端的出站也只能找到下一跳的连接，如果国内也有中转就也不容易从国内流量找到出国服务器。无论如何，这些都需要主动处理，不能直接在出国网关上部署被动检测，所以我说“直接”，当然只是要实现你说的”最终目的“的话也是可行的。

出入境数据量是比较大的，所以如果能“直接上报 IP”，我没有必要选择去检测流量。

并且既然我要部署个钓鱼，我肯定是希望通用，而不是只能抓到占比很少的 XTLS。

你说的“后者（特殊需求分流）不会涉及钓鱼域名”没看懂。

比如说 Netflix、ChatGPT 需求并不会分流钓鱼域名。

最后，感觉你说的流量模式仍然可以因为多路复用被覆盖，准确率不会很高，实现难度可能不小。这里能公开说明一下构造方法吗？

多路复用能起到混淆作用，仅限于它对付的流量是普通的而不是“精心设计”的，另外绝大多数时候并没有大量的干扰流量。

对于构造方法，我推荐直接上正弦波，有傅里叶变换还要啥自行车。

[RPRX]

我的意思是，我的方法可以作为自动加载的资源文件投放，而用这种方法传 id 就有限制，否则就需要用 js 主动传输 id，而且还是不能直接得到出国服务器的 sni 和端口。通过钓鱼服务器能直接得到一台国外服务器的 ip，但是如果有不止一台国外服务器，手动配置中转，就不能直接得到出国服务器的 ip。因为这个 id 只能包含最初客户端的信息，即使检索这个客户端的出站也只能找到下一跳的连接，如果国内也有中转就也不容易从国内流量找到出国服务器。无论如何，这些都需要主动处理，不能直接在出国网关上部署被动检测，所以我说“直接”，当然只是要实现你说的”最终目的“的话也是可行的。

这一段有一处错误，我说的第一个方法中，JS 并不是必须的，比如图片链接后加个查询参数就行了

关于“境外中转”前面说过了，关于“境内中转”你可以看一下 https://t.me/projectXtls/147

[KanakoMikami]

对于构造方法，我推荐直接上正弦波，有傅里叶变换还要啥自行车。

这里的时域数据是包长吗（tls 的侧信道还有啥，这我不熟），如果是的话，能还原出指定频率需要的包会不会比较多？

这一段有一处错误，我说的第一个方法中，JS 并不是必须的，比如图片链接后加个查询参数就行了

我的理解是这个 id 同时用于编码客户端 ip，“静态”查询参数不能区分客户端（你之前说没懂的就是这个，我想说这样不能把本来就来自国外的流量区分开），而根据最终客户端动态生成查询参数仍然需要 js。

关于“境外中转”前面说过了，关于“境内中转”你可以看一下 https://t.me/projectXtls/147

我说的“境内中转”不是指类似 IPLC 的东西，只是为了隐藏客户端原始 ip。当然你可以说国内的事情总可以追溯，我只是说这能相对地避免”直接“的追溯。

off-topic 叠一下

关于 IPLC 我想提一下，公务人员也有访问国外网络的需求（监控国外舆情），而他们也没有和上层直接接触的权限，也许很多时候出国的手段就是 IPLC。另外还有国际贸易的需求，毕竟现在还在“以经济建设为中心”，或许十年内也不会改变这个方针。

[RPRX]

这里的时域数据是包长吗（tls 的侧信道还有啥，这我不熟），如果是的话，能还原出指定频率需要的包会不会比较多？

包长不行，因为包长受到种种限制，加上 padding 等影响，最终的包长不好控制，所以应当是数据量

代理的上传流量是非常少的，也就是说上行干扰非常少，正弦波发几个周期就足够了，想更精准就多取一段时间，但总时间都不长

我的理解是这个 id 同时用于编码客户端 ip，“静态”查询参数不能区分客户端（你之前说没懂的就是这个，我想说这样不能把本来就来自国外的流量区分开），而根据最终客户端动态生成查询参数仍然需要 js。

好像我没说清流程，这个 ID 最初是服务端生成的，服务端知道它发给了哪个 IP 或属于哪个用户，客户端只是“转发”它，不需生成

当然也可以客户端生成一个随机 ID，同时发给国内外两个服务器，这样好像还更 convenient，either way，你说的情况是不存在的

我说的“境内中转”不是指类似 IPLC 的东西，只是为了隐藏客户端原始 ip。当然你可以说国内的事情总可以追溯，我只是说这能相对地避免”直接“的追溯。

不过国内隐藏原始 IP 的服务应该说是几乎没有，除非你自己搭，可能还多少有点违规，卖改省份的服务都不行

关于 IPLC 我想提一下，公务人员也有访问国外网络的需求（监控国外舆情），而他们也没有和上层直接接触的权限，也许很多时候出国的手段就是 IPLC。另外还有国际贸易的需求，毕竟现在还在“以经济建设为中心”，或许十年内也不会改变这个方针。

关于 IPLC，好像有些人理解错了，我并不是说它本身会消失，它必然会一直存在，毕竟他们怎么会让自己也受到墙的限制呢？

但是对普通个人来说 IPLC 就是会“没有”，因为没人还敢散售，你买不到。即使偶有流出，价格也不是普通个人能承受的。

还有人说彻底脱钩，我想说严管 IPLC 乱象怎么就彻底脱钩了，又不是没它就不能翻墙，他们底下人做事也不是都能用上 IPLC。

[RPRX]

没新回复了就总结一下，这个钓鱼类似于 https://github.com/XTLS/Xray-core/discussions/593 ，想利用 XTLS 的特性显示点什么，乍一听挺刺激，但往往忽略了一个关键的问题：

审查者在这么做之前，已经拿到了翻墙服务器的 IP，且适用于各种协议，若再去生成、检测流量是为了找 IP，就像是脱裤子放屁。

https://github.com/XTLS/Go/issues/17#issuecomment-1301538136 我觉得若要应对审查者掌控代理服务端或目标地址的情况，只能是类似 Tor 的模式。

[RPRX]

比如说 GFW 在这里插一个正常的静态 img，我们一加载它不就拿到服务器 IP 了，GFW 再去查这 IP 有什么、有谁连接，不就凉了

所以我上 GitHub 都是用 Tor，另一方面 GitHub 肯定有 GFW 内线，其实它有能力直接把我 IP 交出去，都不用钓

要对付我说的第一种钓法，只有全代理，要对付我说的第二种钓法，只有彻底抹平流量特征，但这些解法特征都很明显，挺无解的

[KanakoMikami]

包长不行，因为包长受到种种限制，加上 padding 等影响，最终的包长不好控制，所以应当是数据量

代理的上传流量是非常少的，也就是说上行干扰非常少，正弦波发几个周期就足够了，想更精准就多取一段时间，但总时间都不长

你的意思是单次连接上下行的总数据量？没搞懂，请教一下细节。

这个 ID 最初是服务端生成的，服务端知道它发给了哪个 IP 或属于哪个用户

我忘了客户端是直连目标网页了，确实拿得到，就是要改原始服务端或者不开启 tls 进行注入，在我看来有点不灵活。

不过国内隐藏原始 IP 的服务应该说是几乎没有，除非你自己搭，可能还多少有点违规，卖改省份的服务都不行

我的意思就是自己搭，所以我说“可以追溯”。

但是对普通个人来说 IPLC 就是会“没有”，因为没人还敢散售，你买不到。即使偶有流出，价格也不是普通个人能承受的。

这里我们理解的分歧大概在于，我认为公务人员也属于“普通个人”，他们用来出国的方法不比我们多，只是他们的行为即使被检测也会被豁免。

审查者在这么做之前，已经拿到了翻墙服务器的 IP，且适用于各种协议。

我理解你想说的是，在全局的脆弱性下，局部的脆弱性可以忽略。但我的观点相反，往往是局部的脆弱性更容易被利用，而利用全局的脆弱性会受到更多的制约。

[RPRX]

你的意思是单次连接上下行的总数据量？没搞懂，请教一下细节。

一段时间的数据量作为一个采样点，离散采样加 FFT

我忘了客户端是直连目标网页了，确实拿得到~，就是要改原始服务端或者不开启 tls 进行注入，在我看来有点不灵活~。

服务端只需小改，这都嫌麻烦的话“客户端生成一个随机 ID，同时发给国内外两个服务器”，查日志就行，这件事可以很做得隐蔽

在我看来你必须检测流量且只能抓到占比很少的 XTLS 岂不是更不灵活，故意触发 TLS 错误还会被抓现行留证据：你想干啥？

我的意思就是自己搭，所以我说“可以追溯”。

它的确改变不了被我抓到的结果

这里我们理解的分歧大概在于，我认为公务人员也属于“普通个人”，他们用来出国的方法不比我们多，只是他们的行为即使被检测也会被豁免。

对于一些领导和特殊部门能用上 IPLC，对于底层打工科员就八仙过海各显神通

分歧不在于这里，而是你应该认识到严管 IPLC 对经济建设并没有多少影响，企业仍会有合法 IPLC，且翻墙手段不止 IPLC 这一种，现在绝大多数人并没有在用 IPLC，而是各种翻墙协议，如果哪天 IP 白名单了，灵活翻墙没了，这才会对经济建设有严重影响

我理解你想说的是，在全局的脆弱性下，局部的脆弱性可以忽略。但我的观点相反，往往是局部的脆弱性更容易被利用，而利用全局的脆弱性会受到更多的制约。

我觉得我可能不是这个意思，咱能不能不要谈空洞的哲学，要针对实际情况进行具体分析，不要把技术问题变为哲学问题

[KanakoMikami]

在我看来你必须检测流量且只能抓到占比很少的 XTLS 岂不是更不灵活，故意触发 TLS 错误还会被抓现行留证据：你想干啥？

你说的是覆盖率低，我承认。我说的是部署上的灵活性，尽管这在技术上确实不值一提，但是在行政上或许会多一点麻烦。客户端生成 id 不管同时发送给两个服务器还是什么都需要 js，当然这不是什么高要求。这里只是提一下细节，你说的也很合理，我觉得不用再讨论了。

分歧不在于这里，而是你应该认识到严管 IPLC 对经济建设并没有多少影响，企业仍会有合法 IPLC，且翻墙手段不止 IPLC 这一种，现在绝大多数人并没有在用 IPLC，而是各种翻墙协议，如果哪天 IP 白名单了，灵活翻墙没了，这才会对经济建设有严重影响

按我的理解，你是认为严管 iplc 会让用户被迫使用代理协议出国，更利于监控。而我这里是认为底层科员利用被“滥用”的 iplc 的可能性不小。而如果使用率真的很小，严管也没有足够的好处。就是说用的多的话会伤到自己人，用的少的话根本不用管，所以“滥用”可能会长期持续。

我觉得我可能不是这个意思，咱能不能不要谈空洞的哲学，要针对实际情况进行具体分析，不要把技术问题变为哲学问题

推测审查者的行为本来就不只是技术问题。这里我只是试图解释一下为什么我这里提出这个问题，而你不认为这是一个问题，没有讨论“哲学”的意思。你认为的实际情况和我认为的实际情况有区别，这很正常。

[RPRX]

按我的理解，你是认为严管 iplc 会让用户被迫使用代理协议出国，更利于监控。而我这里是认为底层科员利用被“滥用”的 iplc 的可能性不小。而如果使用率真的很小，严管也没有足够的好处。就是说用的多的话会伤到自己人，用的少的话根本不用管，所以“滥用”可能会长期持续。

不是，不管用什么都会被监控，IPLC 可能监控更严，只是不封，反而 IPLC 上掉以轻心用不够安全的加密，对监控来说更方便

你有一处逻辑矛盾，既然“底层科员”是“普通个人”，那么他们也应当像“普通个人”一样，以用各种翻墙协议为主，而不是 IPLC 大多数人就是为了完成任务，都不需要多好的线路，能翻就行，有多少人会自掏腰包去买 IPLC 机场？所以你的看法不现实

我认为散售 IPLC 要凉是因为机场用它，且由于这两年的 GFW，用得更疯狂，那么根据历史，机场流行的都要凉凉，中转同理

推测审查者的行为本来就不只是技术问题。这里我只是试图解释一下为什么我这里提出这个问题，而你不认为这是一个问题，没有讨论“哲学”的意思。你认为的实际情况和我认为的实际情况有区别，这很正常。

主要是你一句完全脱离技术的哲学，意图只能靠猜

我说了钓是可以钓的，只是我有更好的钓法，一个都跑不掉，注意是更好的，有时候就是会有不仅更通用还更好用的这种情况

[KanakoMikami]

你有一处逻辑矛盾，既然“底层科员”是“普通个人”，那么他们也应当像“普通个人”一样，以用各种翻墙协议为主，而不是 IPLC 大多数人就是为了完成任务，都不需要多好的线路，能翻就行，有多少人会自掏腰包去买 IPLC 机场？所以你的看法不现实

“能翻就行”未必比“买 IPLC 机场”简单，而且可能多人共用或者团队分配，不一定需要“自掏腰包”。

我认为散售 IPLC 要凉是因为机场用它，且由于这两年的 GFW，用得更疯狂，那么根据历史，机场流行的都要凉凉，中转同理

“根据历史”总是有一定的合理性，但实际情况还是要具体分析。这里就是在具体推测，当然也只是提供一种可能性，不是什么绝对的说法。

我说了钓是可以钓的，只是我有更好的钓法，一个都跑不掉，注意是更好的，有时候就是会有不仅更通用还更好用的这种情况

我当然承认你的方法更通用。我那句话的意思就是，你的方法“太通用”，实际用起来反而容易受到额外的限制，虽然听起来有点反逻辑。而只能解决一个问题的特殊方法反而更容易实施，更不容易出错。只是个人理解，不用太在意。

我这个方法缺乏隐蔽性确实是一个问题，不过你的第一个方法隐蔽性也没有多高，如果实施了反审查社区应该很快就能注意到。第二个方法确实比较隐蔽，这里我主观认为不会被使用吧，既然你也没有办法。

[RPRX]

“能翻就行”未必比“买 IPLC 机场”简单，而且可能多人共用或者团队分配，不一定需要“自掏腰包”。

我觉得这个就是杠了，你的看法是“底层科员”也属于“普通个人”但在用 IPLC，我只是说我并没有看到后半段的必要性与合理性 并简单举了个例子，实际上当然也会有共用、共同支出，你要证明你的看法应当是说明你的看法的必要性与合理性，而不是来这么一句话，后半句没看出有很大帮助关键前半句也没说对啊，买个中端机场就是“能翻就行”，数量、选择更多，价格更低，难道会更难？

“根据历史”总是有一定的合理性，但实际情况还是要具体分析。这里就是在具体推测，当然也只是提供一种可能性，不是什么绝对的说法。

这回具体分析了，具体情况就是今年机场以中转为主，中转肯定要凉，并且行政手段会让它凉得彻底，而不像协议被识别了偶尔还能蹦跶两下，且中转是 IPLC 的前置条件，所以我们退一万步来讲，就算散售 IPLC 本身没有被严管，也会跟着中转一起凉

所以不管怎么看，散售 IPLC 都是凉，关键它自己也比以前疯狂啊，以前正宫是优质直连线路，机场都宣传自己的线路多好，IPLC 只是备胎，现在机场用过时协议就等着被墙，IPLC 上位成了“高端”机场的标配，不管真假都宣传自己是 IPLC，它不凉谁凉

我当然承认你的方法更通用。我那句话的意思就是，你的方法“太通用”，实际用起来反而容易受到额外的限制，虽然听起来有点反逻辑。而只能解决一个问题的特殊方法反而更容易实施，更不容易出错。只是个人理解，不用太在意。

确实反逻辑

我这个方法缺乏隐蔽性确实是一个问题，不过你的第一个方法隐蔽性也没有多高，如果实施了反审查社区应该很快就能注意到。第二个方法确实比较隐蔽，这里我主观认为不会被使用吧~，既然你也没有办法~。

你说反了，第一个方法更隐蔽，因为带个参数是很合理的事情，你发现它有也不能确定它是钓鱼，而第二个方法的流量特征很明显

[KanakoMikami]

我觉得这个就是杠了，你的看法是“底层科员”也属于“普通个人”但在用 IPLC，我只是说我并没有看到后半段的必要性与合理性 并简单举了个例子，实际上当然也会有共用、共同支出，你要证明你的看法应当是说明你的看法的必要性与合理性，而不是来这么一句话，后半句没看出有很大帮助关键前半句也没说对啊，买个中端机场就是“能翻就行”，数量、选择更多，价格更低，难道会更难？

我说得明白一点，我认为 iplc 机场相当有市场，很容易被底层科员使用。你觉得他们使用中端机场是”明显更好“的方案，所以我说的情况不存在。这里我不认可你说的”明显更好“而已。我说的也是推测，证明不了必要性，合理性是主观的，没必要再争了。

这回具体分析了，具体情况就是今年机场以中转为主，中转肯定要凉，并且行政手段会让它凉得彻底，而不像协议被识别了偶尔还能蹦跶两下，且中转是 IPLC 的前置条件，所以我们退一万步来讲，就算散售 IPLC 本身没有被严管，也会跟着中转一起凉

所以不管怎么看，散售 IPLC 都是凉，关键它自己也比以前疯狂啊，以前正宫是优质直连线路，机场都宣传自己的线路多好，IPLC 只是备胎，现在机场用过时协议就等着被墙，IPLC 上位成了“高端”机场的标配，不管真假都宣传自己是 IPLC，它不凉谁凉

”不管怎么看“是你对未来管控政策的推测，或许你有内部消息帮助你判断，不过如果没有公开的信息源，我也没办法信服是不是。

你说反了，第一个方法更隐蔽，因为带个参数是很合理的事情，你发现它有也不能确定它是钓鱼，而第二个方法的流量特征很明显

如果只是监测而没有断流，我觉得都差不多隐蔽，你说第二个更明显也可以。只是第一个方法需要用国外网站，受控制的国内网站用国外网站做统计就不是很自然。如果有断流现象，我觉得第一个方法更容易发现（前端数据收集），而第二个方法一般人不是很容易想到（侧信道），当然想到了也容易发现。

[RPRX]

我说得明白一点，我认为 iplc 机场相当有市场，很容易被底层科员使用。你觉得他们使用中端机场是”明显更好“的方案，所以我说的情况不存在。这里我不认可你说的”明显更好“而已。我说的也是推测，证明不了必要性，合理性是主观的，没必要再争了。

我觉得你总是曲解我的说法，不是说“明显更好”，而是除非有什么普遍的原因（必要性），底层科员的翻墙方式、高中低端机场等分布比例就符合常规分布，即，使用中端机场的人肯定比 IPLC 多得多，因为 IPLC 少、贵、非必须，客观上是合理的

而如果你无法给出什么普遍的原因（必要性），那么这叫凭空想象“底层科员集中在 IPLC”而不能说是推测，客观上是不合理的

“我认为 iplc 机场相当有市场，很容易被底层科员使用”这句话有逻辑吗？

”不管怎么看“是你对未来管控政策的推测，或许你有内部消息帮助你判断，不过如果没有公开的信息源，我也没办法信服是不是。

首先你要认识到一个历史上的以及正在发生的事实：机场流行的协议必然会先凉，即使其它协议的特征更加明显 https://github.com/XTLS/Xray-core/issues/1767#issuecomment-1464882669

因为机场用户是最多的，自建的只是零头，而 GFW 就是一直在找人最多的下手，VPN、SSH、SS、SSR、WSS、Trojan，无一例外

那么现在压力来到了版本之子中转和 IPLC 这边，下一个凉的是什么已经很明显了吧？

如果只是监测而没有断流，我觉得都差不多隐蔽，你说第二个更明显也可以。只是第一个方法需要用国外网站，受控制的国内网站用国外网站做统计就不是很自然。如果有断流现象，我觉得第一个方法更容易发现（前端数据收集），而第二个方法一般人不是很容易想到（侧信道），当然想到了也容易发现。

不知道你说的断流是什么，GFW 要钓鱼当然会给它白名单，不会掐它，不然还钓什么

第二个也需要国外网站，另外第一个不必拘泥于我说的形式，还有很多非常合理、隐蔽的方式，写过 Web 的都能想出 N 种

---

我发现前面那个“审查者在这么做之前”你理解的问题了，可能是你只引了一半有点断章取义，我的意思是即使是对于你说的方法，当 GFW 的钓鱼资源被加载时它就已经知道翻墙服务器的 IP 了，就像产生回国流量时你就已经暴露了，到这一步时你就已经没了，下一步棋怎么走都是输，并不会影响既定结果，注意这是有先后顺序的，这个“局部”始终会比“全局”晚一步，从而失去了利用价值

当然你的方法局限性较大，GFW 要钓的话至少会用我的或更优的方法，还是那个话题：如果被代理目标有鬼，那肯定能找到代理

[RPRX]

补充两个情况：

1. 其实我就帮类似“底层科员”的人免费配置过节点，服务器他自行续费，所以说八仙过海各显神通，当然没人知道我是 RPRX
2. 之前说过我这边 WSS 的情况 #1750 (comment)，现在它是彻底凉了，WS 不带 TLS 却不封，即使不带 TLS 的话一眼翻墙

[KanakoMikami]

我感觉你的逻辑有一点矛盾的地方，你一方面说 iplc 少，没有必要性，另一方面又说 iplc 在机场流行，机场已经不得不用。我只能理解为，你认为中端机场用的协议属于故意留的口子，iplc 属于不受控的方式里面流行的，所以会被优先封杀。

我从来没有说过“底层科员集中在 iplc”，我想表达的是 iplc 占可观的比例，所以容易误伤。这个”可观“不是说大多数，只是说不太少。

总结一下就是前面说的”就是说用的多的话会伤到自己人，用的少的话根本不用管“。你不能单独得出两个结论，又说 iplc 客观上不会被用，又说 iplc 是版本之子必然会凉，你这两个结论只保留一个的话都还算合理。

---

”合理、隐蔽的方式有很多“，不意味着不容易被发现，前端逆向又不是没人会，而且审查者的效率往往不如社区。我还可以说每个人都能发明自己的加密算法，但很难没有漏洞。

前面那个不是你理解的这个问题，但总之这里我们看待问题的角度差异比较大，而且我也承认你的逻辑合理。

[RPRX]

这么说吧，比较是相对的，我说 IPLC 流行是相对于它以前备胎的角色，今年已经是一种疯狂的状态，达到了种种限制下的饱和，这已经是非常严重的监管失灵了。 你可以理解为 IPLC 是一个 独立的市场、有额外的监管，若市场大规模异常，治理就会到来。

如果从翻墙的总量来看，IPLC 占比就是少。今年机场以中转为主，中转迟早要凉，那时 IPLC 也跑不掉，因为中转是前置条件。

所以逻辑上是没有冲突的，相比以前，IPLC 已经能滥用的都滥用了，这叫流行，且它适用额外的监管，但供应量远少于常规线路。

另外怎么说呢，枪打出头鸟，“高端”机场拿 IPLC 标榜自己是非常扎眼的行为，就算它供应量少也会引来举报、调查等。 喵帕斯取保候审期间我和他聊过，他认罪态度良好，一切配合 JC，当然为了避免他拿我戴罪立功，我们没聊太多。

---

“合理、隐蔽”指的是就算你看到了他的业务逻辑，也不能确定他就是 GFW 安排来钓你的，因为他这个业务逻辑就是正常的。

或者说，有很多正常的业务都没想钓你但会造成钓到了你的事实，这是“分流”必然会有问题，早就被诟病过。

因为网站本来就都会追踪你，举个例子，有个子域在境外，Cookie 自动传过去，这不就巧了。

[RPRX]

To 群里：喵帕斯告诉我他把数据库交出去确实有很大帮助，再加上找个好律师还有希望不坐牢，当然我没关注后续

[RPRX]

还是想逐句回复一下，防止他人误解

我感觉你的逻辑有一点矛盾的地方，你一方面说 iplc 少，没有必要性，另一方面又说 iplc 在机场流行，机场已经不得不用。

往上翻，我从来没有说过“机场已经不得不用”，我说的是“IPLC 上位成了“高端”机场的标配，不管真假都宣传自己是 IPLC” 注意是“高端”机场，而“高端”机场数量是最少的，普通人没特殊需求就没必要高价买它，所以换成我实际说过的话，就没有矛盾了

我只能理解为，你认为中端机场用的协议属于故意留的口子，iplc 属于不受控的方式里面流行的，所以会被优先封杀。

这显然不是我的意思，前面我说过： “不是，不管用什么都会被监控，IPLC 可能监控更严，只是不封，反而 IPLC 上掉以轻心用不够安全的加密，对监控来说更方便” 了解一下 https://t.me/projectXtls/151?comment=2564432 https://t.me/projectXtls/151?comment=2564489 还有，中转国内段普遍是过时的 SS AEAD，然而 GFW 在每个城市都有，手机又不安全，SS 又没前向安全，情况就是这么个情况

我从来没有说过“底层科员集中在 iplc”，我想表达的是 iplc 占可观的比例，所以容易误伤。这个”可观“不是说大多数，只是说不太少。

原句是“也许很多时候出国的手段就是 IPLC”，所以我觉得我这个转述意思并没有差太多 当然这个“不太少”也是不对的，注意别被假 IPLC 宣传骗了，可能就个线路好点的中转

总结一下就是前面说的”就是说用的多的话会伤到自己人，用的少的话根本不用管“。你不能单独得出两个结论，又说 iplc 客观上不会被用，又说 iplc 是版本之子必然会凉，你这两个结论只保留一个的话都还算合理。

以前机场主流是那些直连协议时就有“自己人”“用的多”，GFW 最终还是封了那些协议，所以“自己人”“用的多”并不是护身符 “用的少”的协议确实不会管，但 IPLC 有额外的监管，翻墙在它的市场内疯狂就不能视而不见了，详见上面的回复

[KanakoMikami]

总结一下你的观点：你说 iplc 要凉是因为滥用相对以前严重，更能体现出监管失灵，且有高端机场引流。但这和之前的“机场流行的必然先凉”的理由无关，所以你重新说明“机场流行的是中转，iplc 只是顺带”。

这个论述只要“iplc 就是少”属实就合理，可以认可。

---

“机场已经不得不用”是来自 https://t.me/projectXtls/147 的“机场是没办法，就算成本高风险大也得上中转甚至 IPLC”。虽然原话首先说的是中转，但上下文把两者高度并列（且把 iplc 放在前面），难免出现一点理解偏差。

---

关于误伤：我是认为审查者大部分时候相当保守，有可观测的误伤就不会轻易实施，所以我说的“很多”不意味着比例多么大。我感觉你不这么认为，一个理由是历史上代理协议多次被大范围封杀。但问题是不管哪一次也没有真正封完。你现在说流行的协议都被封了，并给出了多份用户报告，那我也很好奇现在的个人或者机场都是怎么连接国外网络的。

---

关于隐蔽性：我觉得能用来钓鱼的网站都比较官方，所以单是用到了国外网站就值得怀疑，这个我前面也说过了，你可能没在意。

[RPRX]

总结一下你的观点：你说 iplc 要凉是因为滥用相对以前严重，更能体现出监管失灵，且有高端机场引流。但这和之前的“机场流行的必然先凉”的理由无关，所以你重新说明“机场流行的是中转，iplc 只是顺带”。

这个论述只要“iplc 就是少”属实就合理，可以认可。

是有关的，如果没有“高端”机场对 IPLC 的滥用、没有黑心机场的假 IPLC 宣传，IPLC 就不会吸引到这么多的关注，可能比中转先凉

“机场已经不得不用”是来自 https://t.me/projectXtls/147 的“机场是没办法，就算成本高风险大也得上中转甚至 IPLC”。虽然原话首先说的是中转，但上下文把两者高度并列（且把 iplc 放在前面），难免出现一点理解偏差。

相比于中转，显然 IPLC 问题性质更严重，这种“不过墙”的特殊线路本来就有非常严格的审批、审计和监管，今年这种情况就是打脸

当然我是不觉得奇怪的，到处都是不受监督的权力、贪污腐败的官员，不出这种问题才有鬼。那位 炮 一开始还说没贿赂，结果自己举了个反例。我想说第一天来中国？在这个守法办事都有可能被权力寻租、吃拿卡要的国家，你干这种明显违规的事情没给上面好处，监管凭什么闭一只眼当没看见？就为了掉自己的乌纱帽？

关于误伤：我是认为审查者大部分时候相当保守，有可观测的误伤就不会轻易实施，所以我说的“很多”不意味着比例多么大。我感觉你不这么认为，一个理由是历史上代理协议多次被大范围封杀。但问题是不管哪一次也没有真正封完。你现在说流行的协议都被封了，并给出了多份用户报告，那我也很好奇现在的个人或者机场都是怎么连接国外网络的。

问这个显然是你不了解今年的情况，平时多看看社区讨论就了解了。

如果说开源软件觉得被云厂商拿去卖云服务都很不爽，那么中转这种方式的伤害就更大。以前说过中转只会给 GFW 喂海量数据，却对社区发展没有任何帮助，毕竟连名字都不会提，客户端也是用旧的就行，导致普通用户都不知道/关注新协议、新客户端了。

属于是喂的数据最多，credit 却一点都没给。

昨晚微软 TLSv1.3 炸了，我看到有个人连夜修改 200 台机的 REALITY dest，一看就是卖中转的，因为 REALITY 机场暂时没这规模。

以前 VLESS 出那么久都没什么机场，今年我还没正式 release REALITY 就有一些机场了，看来确实是被 GFW 逼得没办法。

关于隐蔽性：我觉得能用来钓鱼的网站都比较官方，所以单是用到了国外网站就值得怀疑~，这个我前面也说过了，你可能没在意~。

这你就错了，你觉得拼多多干了这么多事，中国为啥一声不吭？我们发现某浏览器插件干的事更明目张胆，时机合适再爆料是谁。

[KanakoMikami]

是有关的，如果没有“高端”机场对 IPLC 的滥用、没有黑心机场的假 IPLC 宣传，IPLC 就不会吸引到这么多的关注，可能比中转先凉

你之前说“机场流行的必然先凉”的理由是“用户多封掉打击大”，这里是说和这个理由无关，因为用户不多，不是说和这一现象无关。

问这个显然是你不了解今年的情况，平时多看看社区讨论就了解了。

我是想说在我的主观印象中，今年能连接国外网络的人数并没有减少。你说用中转，中转最后也需要一个代理协议出国，那么就是没封完，你总不至于说最后用的都是 REALITY。

这你就错了，你觉得拼多多干了这么多事，中国为啥一声不吭？我们发现某浏览器插件干的事更明目张胆，时机合适再爆料是谁。

审查者和私有企业都合作相对地不会那么深远，因为企业会给自己留底。当然这种情况确实需要考虑，你是对的。

[RPRX]

你之前说“机场流行的必然先凉”的理由是“用户多封掉打击大”，这里是说和这个理由无关，因为用户不多，不是说和这一现象无关。

有没有一种可能，同一句话可以有多个含义，若单独拎出来、脱离上下文，很难说它就是什么意思。

我是想说在我的主观印象中，今年能连接国外网络的人数并没有减少。你说用中转，中转最后也需要一个代理协议出国，那么就是没封完，你总不至于说最后用的都是 REALITY。

当然不是，如果是的话这么短一句话我直接打出来不就行了。就是因为情况非常复杂，我懒得描述了，所以让你多去看看了解下。

[RPRX]

说实话我觉得和你聊天是比较累的，尤其是，你总是会错误推导出一些我根本没有的意思，我又要澄清，或许你以后别这样推导了

还有就是比较耗时，我每天只花一点时间在这上面，你还喜欢无限追问细节，前几天和你聊几句，时间直接没了

况且你是一个刚注册的小号，这让我觉得更加不值，因为时间都不知道花到谁身上了，可能不好听，总之这就是我的真实感受

[chika0801]

水墨近期日常 https://hostloc.com/thread-1188475-1-1.html nnr 近期日常 https://www.nodeseek.com/post-13544-1

卖转发的，卖“专线”的近况。这位不是混mjj圈不了解业界建议不要回他了。我刚发现 rprx 说的真是符合近段时间vps圈现状，⑥

[RPRX]

水墨近期日常 https://hostloc.com/thread-1188475-1-1.html nnr 近期日常 https://www.nodeseek.com/post-13544-1

卖转发的，卖“专线”的近况。这位不是混mjj圈不了解业界建议不要回他了。我刚发现 rprx 说的真是符合近段时间vps圈现状，⑥

刚说完 IPLC 和中转的问题，这两天就全是网络强国，快进到我真是 GFW 供应商？

[KanakoMikami]

~说实话我觉得和你聊天是比较累的，尤其是，你总是会错误推导出一些我根本没有的意思，我又要澄清，或许你以后别这样推导了~

~还有就是比较耗时，我每天只花一点时间在这上面，你还喜欢无限追问细节，前几天和你聊几句，时间直接没了~

~况且你是一个刚注册的小号，这让我觉得更加不值，因为时间都不知道花到谁身上了，可能不好听，总之这就是我的真实感受~

首先感谢你耐心的回复。

我总是推导在一定程度上是因为你没有一开始就把话说清楚，你把澄清的部分一开始就说了也就不需要澄清了。

另外你经常会补充很多与主题没有直接关联的背景，就我而言我很感谢你的补充，我的很多追问也是关于这部分。

讨论敏感话题注册小号是常规操作吧。以前没有注册是因为以前还没有讨论相关话题所需的基本的技术理解。抱歉给你带来不好的印象。

[RPRX]

虽然但是，我还是需要说一下

关于误伤：我是认为审查者大部分时候相当保守，有可观测的误伤就不会轻易实施，所以我说的“很多”不意味着比例多么大。我感觉你不这么认为，一个理由是历史上代理协议多次被大范围封杀。但问题是不管哪一次也没有真正封完。你现在说流行的协议都被封了，并给出了多份用户报告，那我也很好奇现在的个人或者机场都是怎么连接国外网络的。

这个“我感觉你不这么认为”，我澄清一下，我的看法不是一两句话就能概括的，很多时候是要具体分析，GitHub 上已经积累了不少

我是想说在我的主观印象中，今年能连接国外网络的人数并没有减少。你说用中转，中转最后也需要一个代理协议出国，那么就是没封完，你总不至于说最后用的都是 REALITY。

这句话之前我并不确定你说的“没封完”指什么，这句话说它包括“仍有协议能用”，恰恰说明了对某一协议/方式来说，“自己人”“用的多”并不是护身符，因为它不具有不可替代性，被封了人们就会用其它协议/方式，从这个角度来说严管 IPLC 也并不怎么伤“自己人”

---

还是简单说一下各协议 2023 现状（对于中国大多数地区）

1. SS 全随机数类秒封 IP；IPv6 不一定封，因人品而异；绕过“省钱规则”曾经不封，目前不知道，但若流行了肯定会封，参考 SSR
2. Trojan、WSS 隔天封端口；Cloudflare 不封但干扰会很严重，因地区而异
3. 黑名单是单连接 TLS in TLS 握手典型特征，因为用强 padding（Vision）或开 mux 就能绕过，注意不要让猪队友客户端连接
4. REALITY 类偷白名单域名的话即使有上述特征也不封；甲骨文等太黑的 IP 段偷大厂/偷别人不一定连得上
5. Hysteria、TUIC 不一定封，因配置、地区而异；可能会遇到 QoS 限速，因运营商而异；总之就是使用体验严重因人而异

所以你可以看到以前的流行协议在今年是什么样的存活状况，事实上今年自建的大都是新协议，非 IPLC 中转用的协议原理也没差 你的主观印象中“今年能连接国外网络的人数并没有减少”，严格来说就是因为自建，一些人把它透明化了，卖中转给机场和个人

[chika0801]

Hysteria、TUIC 不一定封，因配置、地区而异；可能会遇到 QoS 限速，因运营商而异；总之就是使用体验严重因人而异

说下我个人的看法：TUIC协议版本V5出了一段时间了，在群里约一段时间前（印象中7-10天前）讨论热度很高时，有大于3人（靠印象）反映用了段时间客户端不通，换端口好。我当时还想我也测试过，运气好我没遇到。

~Hysteria 2，作者一直在测试。设计思路是流量是quic，服务端可反代一个其它网址。我也这样在用（测试），我自己有1个VPS（我不能保证UDP 443只用了Hysteria 2，中途偶尔也测过TUIC）这VPS的UDP443我用了到现象大约10-15来天了。刚刚客户端不通，排查了下原因，发现换端口立马好，恢复成UDP443就不通。此VPS的TCP443是nginx监听并反代的一个网站。HY2的配置中反代的是本机用的域名的网址（原因出处 https://github.com/apernet/hysteria/discussions/632 ） 。比如我域名 www.abc.com指向 VPS IP tcp443由nginx监听。hy2配置中填的反代的网址就是www.abc.com。补充下目前Hy2连不上，客户端日志是表现超时，服务端是收不到任何请求。我没条件换其它运营商如手机共享热点就换IP（懒了）。和目前才遇到约1小时，再观察一下吧。更新不更新记录不保证。~

~这次正好有这台VPS做样本可以观察下。 当时就觉得你的观点 https://github.com/XTLS/Xray-core/issues/1767#issuecomment-1464882669 有理，现在回看确实大写我是服~

12小时后测试，UDP443端口恢复了。能正常用了。

[RPRX]

@chika0801 你遇到的应该是运营商限速，偶尔会给你的端口限到 0，表现就是服务端收不到包。GFW 认为你是翻墙的话，封你端口就不会短时间给你恢复了，除非它在确认、标注、炼丹。GFW 尚未大范围对 QUIC 翻墙下手，我觉得比较有可能是明年动手。

[chika0801]

@RPRX 我那台用Hy2协议的VPS，我会留着，我过段时间再用它。我这用UDP，我倒时没遇到过QoS，那天晚上突然遇到后，我还是激活了一些，是应该睡一觉再观察是否自行恢复的。听了你的看法，我也觉得你说的是对的。

现在我找了另一台VPS，是小众商家，非CN优化线路，我认为它的IP是干净的。我就只开TUIC最新版本协议来用，开8443端口。我的目的是测试下能不能遇到群友反应的用TUIC端口被封。

[chika0801]

@RPRX

现在我找了另一台VPS，是小众商家，非CN优化线路，我认为它的IP是干净的。我就只开TUIC最新版本协议来用，开8443端口。我的目的是测试下能不能遇到群友反应的用TUIC端口被封。

已遇到了。协议使用TUIC，客户端突然不通，查看服务端日志如下。此时修改服务端配置换一个端口，客户端配置也相应修改端口，立即就通了。

[2023-07-20T12:44:01Z WARN ] [0xffffffff] [本地IP:57253] [unauthenticated] aborted by peer: the application or application protocol caused the connection to be closed during the handshake

你遇到的应该是运营商限速，偶尔会给你的端口限到 0，表现就是服务端收不到包。GFW 认为你是翻墙的话，封你端口就不会短时间给你恢复了，除非它在确认、标注、炼丹。GFW 尚未大范围对 QUIC 翻墙下手，我觉得比较有可能是明年动手。

用Hy2的那台VPS，前几天日常用时，也有再次遇到UDP443端口突然不通（客户端表现就是连不上），我遇到后不继续用，明天来看它又自己恢复的现象。

我这地区我印象中，之前对UDP类的都很畅通（我之前都没遇到1次这种现象），有可能是我这地区的力度上来了吧。