由TG散户群体自发形成的测速社区。专注*用户测*的体验:单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org

欢迎所有 用户👨🏻‍💻 和 机场主🕋 投稿,共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项,仅受理*原投稿人*。

讨论群: @haitunspeed
频道: @haitun_channel
海豚机场测评|用户侧体验|测速频道
窝里斗 第二阶段:代理协议的开发者/拥趸 之间的互殴 如果说 2025 年机场主(或 DDoS 攻击者)发起的入口相互举报/通报是「第一阶段」,那么今天浮出水面的代理协议开发者/拥趸之间的举报即是「第二阶段」。 本轮互殴的概要: 某代理 app 区 KOL 在今日推送一篇有关 VLESS-Reality 探测手段的博文,随后在 Surge Pro 群内称:他已将相关论文递交给华为、派网、新华三、深信服。 ——— 一些时间线: 1. 某代理 app 区 KOL 在博客发文《杀死那只鹦鹉 —— 「白话文」讲解一种探测…
代理圈自己的春晚,起承转合已经比 CCTV 春晚还精彩!

———
RPRX 回应节选 (原文在 Github 👈 ):

1. 某 KOL 及其合作者针对 Reality 协议所指的 maxUselessRecords 错漏,实际上早在 2023 年的某次 commit 中就已修改为 32,只因 2024 年的另一 commit 失误合并上游代码时未经核验而导致取值不慎返祖
预计:当相关参数回溯 2023 版后,该报告第 2.3.2 节和表 2.5-1 及之前所提出的「初步 探测手段」就失效了。

注:实际上,RPRX 本人也曾在 crypto/tls 的 PR (2023年) 提及过取值 16 存在安全风险,所以该报告的相应章节及表的探测思路不算新的发现


2. RPRX 坦言:很遗憾鹦鹉却是反审查中很难避开的一环,REALITY 的“特征”其实还有很多,比如说 server handshake 消息 TCP 分包发送/粘包发送,data record 的 max size 与切换策略(XTLS 也有这个问题,不过 REALITY 的大规模普及在一定程度上扰乱了公网流量特征)、广泛存在的 timeouts 等,即使全解决了也顶多做到特征符合“端口转发”……
按:这段话并未 address 该报告的 4.4 节及表 2.5-2~2.5-6,尤其源自 Go 库本身的 16 上限问题确实是个硬伤(假设 GFW 算力 → ∞ 的话)

RPRX 称:以前没说那么多是因为不想给 GFW 提供弹药,等它自己研究出来我再改,这样可以延长拉锯时间……所以 REALITY 成了一个不得不长期存在、维护的协议

值得注意的是,另有开发者绕开 Go,转而用 Rust 重构 Reality & XHTTP,见 undead-undead/xray-lite,或许是一个新的破局思路?【新项目,暂无临床证据】


3. 余下内容是 RPRX 对某 KOL (那些人) 的道德看法。
可能那些 KOL 有着自己的道德坐标系?本文不予置评看客们若有兴趣,可移步原文


———

频道按:

结合 2022 年底官方统计数据,京+沪+穗 三地四网的出入口局(挂载 #GFW 服务器)的带宽处理规模加总 ≈ 18.04 Tbps。同期,它们连接的海缆总容量达 746.36 Tbps。
利用率仅 ≈ 2.4% ❗️
—— 若计入内蒙+新疆+黑龙江的中欧陆缆、云南+广西+西藏的南亚陆缆,该比率只会更低。

如此低的利用率,与国际通行的海缆 10%—30% 点亮率之间,存在数量级的鸿沟。这似乎暗示了 GFW 的算力极其吃紧,或许该报告所述的 「深度行为分析」在理论上自洽,但在现实中的可行性需要打一个问号


———

当某代理 app 和 Xray-core 开发者/拥趸激烈交战时,华为、派网、新华三、深信服的工程师可能坐在家里边嗑瓜子、边看代理界春晚中的抖包袱。这些工程师,或许都已经计划好在初八上班后开一个新 project 提取特征,为 GFW 添砖加瓦,争取在马年升职加薪。这或许才是这场闹剧的最大悲哀!

顺祝各位看官在马年也升职加薪!🚀🚀🚀


#吃瓜 #窝里斗 #第二阶段 #续集 #xray #reality #vless #rprx #sukka
 
 
Back to Top