由TG散户群体自发形成的测速社区。专注*用户测*的体验:单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿,共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项,仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿,共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项,仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
Clashbox 为 HarmonyOS Next 系统代理工具(基于 mihomo 核心),其频道于 4 月 25 日晚推文称:
Clashbox 2.0 发布后,小白工坊所有涉及 VPN 功能应用都停止更新。团队转赚钱应用开发去了,VPN 这垃圾东西拜拜啦
—————
这里有瓜🍉…… 断更的起因疑似某 app 用户的言论惹恼开发团队。
第 ❶ 回合:该用户在 app 群(小白鸿蒙clash交流群)撒泼打滚
那你们至少把…
那你们至少应该…
店大欺客,反正没人跟你们抢生意,你们就已经急了
稍微说几句都不行吗?
虽然群名是交流群,但感觉像是在运营粉丝群
杀伤力最强的可能是以下两句
在国内做还这么招摇,还敢收钱,还是先小心一下自己,别哪天进去了吧
——频道按:Clashbox 是一个免费 app
祝作者做大做强,再创辉煌,也希望作者也能找到新的增长点和成长点
第 ❷ 回合:该用户跑到软路由固件群(iStoreOS)炫耀战绩
鸿蒙的 clash 停更了
不曾想引来围殴
这不是你努力的结果吗?
色鸡群非常需要这样的人才
——频道按:他其实一直在 Surge Pro 群
你不是嫌弃做好饭,还没喂你嘴里吗?
这能叫提建议???这不纯纯找喷,自己没本身写,还怪人家写的不行…
他倒是提个建设性的建议啊,比如解决方法之类的,也行啊,自己屁不会,还挑三拣四
并被送合订本,见该链接👈
据悉,该用户现已从 FlClash、NobyDa Script 等群退出或被执法除名
#app #clashbox #吃瓜 #harmonyos
按闹分配的小反转
继上次舆论反噬后,@Surge 又发布消息,并没有在协议支持上松口,而是将矛盾点转移到 功能订阅更新频率 以及 曾经投入了许多精力到用户看不见的底层技术之上。
不过 Surge 官方似乎善意地推出了一项改进,原话称「如果 Surge iOS 连续 90 天都没有推出新功能,那么在这期间存在订阅期的用户,订阅期将自动延期 90 天。」
———
这一做法,固然是一种改善。但新的问题是:
1、新功能的边界在哪?那些用户感知不到、摸不着的功能更新是否算数?
2、90 天计时器是否诱发 策略性卡点?
说到底,一个不需要调用服务器资源的本地工具软件,采用周期性功能订阅制本身就自带槽点。强如 Adobe 系列,即便它在某些领域近乎垄断,其订阅制也伴随着非议。
更何况,在代理工具这个赛道,2026 年早已不是 2016 年时的市场结构,优秀的竞业者已不少。不仅谁都做不到垄断,反而落后还会被淘汰。
大家还有什么看法,欢迎评论……
#吃瓜 #surge
继上次舆论反噬后,@Surge 又发布消息,并没有在协议支持上松口,而是将矛盾点转移到 功能订阅更新频率 以及 曾经投入了许多精力到用户看不见的底层技术之上。
不过 Surge 官方似乎善意地推出了一项改进,原话称「如果 Surge iOS 连续 90 天都没有推出新功能,那么在这期间存在订阅期的用户,订阅期将自动延期 90 天。」
———
这一做法,固然是一种改善。但新的问题是:
1、新功能的边界在哪?那些用户感知不到、摸不着的功能更新是否算数?
例如,微信、美团等国产 App 惯用的「修复若干小问题」等,或粉饰称增加一个微小功能的版本,这些策略性更新是否算数呢。
2、90 天计时器是否诱发 策略性卡点?
事前一旦缺乏公开透明的、可追溯的 Roadmap for Update,那么人为推迟/策略性操纵更新时间很是容易。
例如,基于众数到期日卡点或每隔 89 天进行策略性更新,以便清空 90 天展期计时器;再等到 +1 天、+2 天…更新真正的「新功能」骗氪,似乎也不算违背今天的承诺。
说到底,一个不需要调用服务器资源的本地工具软件,采用周期性功能订阅制本身就自带槽点。强如 Adobe 系列,即便它在某些领域近乎垄断,其订阅制也伴随着非议。
更何况,在代理工具这个赛道,2026 年早已不是 2016 年时的市场结构,优秀的竞业者已不少。不仅谁都做不到垄断,反而落后还会被淘汰。
大家还有什么看法,欢迎评论……
#吃瓜 #surge
最近的 #拔线潮 让许多用户被迫从中转或专线回归自建方案。在自建过程中,VLESS 协议族尤其 Reality 和 Vision 等特性当属较为成熟的选择。甚至原本 (一贡献者) 表示不会支持 XHTTP 特性的 Mihomo,也自 v1.19.22 版本更新中引入了该特性。
在这个过程中,Surge 又一次成为众矢之的,如出处1、出处2、出处3、出处4 (ns)。这次 拔线潮 让 Surge 对 VLESS 协议支持度的舆论反噬开始蔓延。这种不满从原本 Surge 拥趸和 Xray-core 拥趸之间长期的相互看不顺眼,进一步扩散到了 Surge 内部不够虔诚的低纯度粉丝群体。
有趣的是,Surge 开发者 @YachenLiu 最近正值装修,本想在 𝕏 平台发文吐槽一些行业乱象。他提到
其原话:活干得好的工人,反而事情少 …… 活干的不好的工人经常被扣尾款,所以尽早想把钱先收了…… (这种) 工人没什么人找,也没有回头客,抓到一单就要尽量多榨一点油水。
这番感悟,没成想在评论区被用户贴脸开大、镜面反弹,画风急转「 批评与自我批评」现场,见截图的左侧。随即 @YachenLiu 关闭了 𝕏 的访客阅读权限,并清洗 Surge 官网论坛里的相关意见反馈。在堵不如疏之间,他选择了堵……👍
随着吃瓜群众增多以及各大频道的跟进报道,Surge 官方频道终于按捺不住对 VLESS 协议的支持问题进行应急公关,见 https://t.me/SurgeTestFlightFeed/359 。
该回应很拧巴,属于一个似是而非的拖字诀。
———
其实作为用户,既不是股东,也不必荣辱与共。理性选择,才是正道。如果这个工人消极怠工,换一个便是。如果它哪天幡然悔悟,再回头光顾也未尝不可。吊死在一棵树上毫无必要,包括但不限于代理工具或任意类型的 App。
v3: 完善一些表述 2026-04-15 08:30
#吃瓜 #surge #vless #拔线潮引发的舆论反噬
代理圈自己的春晚,起承转合已经比 CCTV 春晚还精彩!
———
RPRX 回应节选 (原文在 Github 👈 ):
1. 某 KOL 及其合作者针对 Reality 协议所指的
2. RPRX 坦言:
3. 余下内容是 RPRX 对某 KOL (那些人) 的道德看法。
———
频道按:
结合 2022 年底官方统计数据,京+沪+穗 三地四网的出入口局(挂载 #GFW 服务器)的带宽处理规模加总 ≈ 18.04 Tbps。同期,它们连接的海缆总容量达 746.36 Tbps。
———
当某代理 app 和 Xray-core 开发者/拥趸激烈交战时,华为、派网、新华三、深信服的工程师可能坐在家里边嗑瓜子、边看代理界春晚中的抖包袱。这些工程师,或许都已经计划好在初八上班后开一个新 project 提取特征,为 GFW 添砖加瓦,争取在马年升职加薪。这或许才是这场闹剧的最大悲哀!
#吃瓜 #窝里斗 #第二阶段 #续集 #xray #reality #vless #rprx #sukka
———
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
【Stash 疑似大面积“缝合”开源代码】
#快讯
接群友匿名投稿,知名代理软件 Stash Mac 涉嫌大量复制粘贴开源代码,涉及多个GPL、AGPL协议下的代码库。
🗣 投稿者:匿名群友
💥 爆料源:https://x.com/nek0hasekai/status/1941361311130235189
📣 据爆料源,Stash Mac 客户端的核心代码(时间戳20250520) 被指控“缝合”多项知名开源项目:
*
*
*
*
📣 爆料源还称,Stash Mac 在复制粘贴代码时,甚至忘了对
#群友投稿 #吃瓜
#快讯
接群友匿名投稿,知名代理软件 Stash Mac 涉嫌大量复制粘贴开源代码,涉及多个GPL、AGPL协议下的代码库。
🗣 投稿者:匿名群友
据悉 ta 之前已投稿多个频道未果,原来备胎竟是我自己?
💥 爆料源:https://x.com/nek0hasekai/status/1941361311130235189
📣 据爆料源,Stash Mac 客户端的核心代码(时间戳20250520) 被指控“缝合”多项知名开源项目:
*
Shadow-TLS: 疑似完全⬅️ SagerNet/sing-box (GPL授权)。Singbox 开发者公开指控 Stash Mac 抄袭其 Shadow-TLS 实现。*
SS2022: 疑似部分⬅️ database64128/shadowsocks-go (AGPL授权)。*
Vless: 疑似部分⬅️ SagerNet/sing-box (GPL授权)。*
Tun 的 system 栈: 疑似部分⬅️ Kr328/tun2socket(MIT 授权)。📣 爆料源还称,Stash Mac 在复制粘贴代码时,甚至忘了对
quic-go 依赖 去重,导致其在代码中重复出现两遍。GPL与AGPL协议的版权简介:
GPL协议(GNU General Public License)是开源社区的重要基石,其核心特点是“传染性”。这意味着,如果一个软件 完整或部分 使用了GPL协议的代码并进行分发,那么该软件的整体也必须以GPL协议开源,并提供完整的源代码。
AGPL协议(GNU Affero General Public License)则是GPL的延伸,专为网络服务(SaaS)设计。它规定,即使软件没有被直接“分发”给用户,只要通过网络向用户提供服务并使用了AGPL许可的代码,服务提供方就必须向用户提供其所使用的、修改后的完整源代码。
#群友投稿 #吃瓜