海豚机场测评｜用户侧体验｜测速频道

对比ss-trojan刷网页的真实耗时.png

《SS / Trojan 刷网页的实际延迟对比：下篇》

可能有人想问 v2ex.com 不是有挂 Cloudflare CDN？难道CDN不能改善加载耗时吗？

3️⃣ 访问挂载 CDN 的网站，其 #动态文件 的加载延迟依然对「用户侧耗时」拖后腿，属于压死骆驼的最后一根稻草。

例如 v2ex，其静态文件（CSS、部分图片）可通过 CF 全球/就近分发，但动态内容（帖子、评论等）则必须从美国 #建站鸡 拉取。

➤#动态文件 链路：🇺🇸源服务器 ➜节点 ➜你家，越接近 “直线” 就越快。
➤#静态文件 链路：🌎临近CDN ➜节点 ➜你家，就近分发。

再回头看图，就不难理解为何从快到慢依次是 🇺🇸 ＜🇯🇵 ＜🇭🇰 ＜🇩🇪。 🇺🇸节点对 #美国鸡 有东道主优势。

4️⃣ 那么，所有的 CDN 都无法扭转东道主优势吗？

答案：未必，要看网站类型。例如 #油管 (某种程度上) 、#网飞 等以分发静态视频为主的网站，其体验又主要由 CDN 决定。

甚至，谷歌、微软 对高优先级的 #搜索 业务，会采用高成本的全球分布式前端技术＋全球私有骨干网，无论用哪里的节点都快！

不过，前面提到的视频站，也有反例。

例如 XVi*、xHam* 等虽然挂 CDN，但未对太多视频上云（成本考量），所以仍要从 🇪🇺源服务器 拉取；P*Hub 也要从 🇺🇸源服务器 拉取。此时，因地制宜地用当地节点观影，首帧延迟、起速都更有优势。

反例之外，还有反转。

#YouTube 虽挂 CDN，且对视频资源上云，但每个 CDN 的视频缓存有着明显的「地域偏好」。或许有人已注意到，
➤ 用 🇭🇰🇸🇬 加载「简中＋部分繁中」视频很快，RTT < 25ms 也轻松跑 100w 娱乐分；但加载欧美视频，因要从🇺🇸🇪🇺服务器拉取，又变得很慢，娱乐分咔咔掉。毕竟 city-level CDN 体量小……
➤ 用 🇯🇵 加载「简繁中＋日文」视频很快，但其他的…也就比🇭🇰🇸🇬好一点，但不多……

总之，各家采购 CDN 策略复杂。

5️⃣ 我该用哪的节点？

很难一概而论，毕竟每个人的机场、节点状况、常逛网站等大相径庭。不如用 随附的 .js #油猴脚本 测试一下，并把你的结果＋机场分享到评论区。

对于本文环境，🇺🇸最佳、🇯🇵 其次、🇭🇰再次…

⚠️ 测试务必接网线，且最好💉打鸡血排除远距离掉速的干扰！

#漫谈 #技术杂谈 #rtt #延迟 #脚本

LoadingTime.js

7 KB

《SS / Trojan 刷网页的实际延迟对比：上篇》

不少一/二线同时提供 SS＋Trojan 协议。众所周知的是，这俩虽然 RTT 相同，但因 Trojan 多一次握手，所以其 HTTP(S) 延迟 > SS协议。那么，优先选 SS 吗？

此时，有必要引入一个相关的问题/争议。不少人认为，HTTP(S) 延迟才最反映刷网页的实际体验。沿着这一逻辑，继而认为，SS 协议的 HTTP(S) 延迟更低，那么在日常使用中就应优先用 SS 节点。

部分人的观念：RTT 延迟对于日常网页毫无参考价值，仅供意淫之用…🥲

👉 问题来了，节点『HTTP(S) 延迟』真的最能反映 “刷网页的实际耗时” 吗⁉️ 省流：不能，其参考价值还不如 RTT ！

—————
对此，本文专门进行检验，得到了一些有趣的发现：

1️⃣ 相同入口-相同专线-相同落地，同时搭 #SS 和 #Trojan 节点，两者 HTTP 延迟差异较大（≈1次 RTT），但开网页的实际耗时差异→0❗️

如4个子图的左/右箱体所示。仅有的差异来自网络自身的波动

2️⃣ 看到这里，似乎 RTT 才是决定「用户侧网页加载耗时」的关键？沿着这个逻辑，RTT 越低，访问网站就越快？

答案：对，但也不对。

➤『对』的理由：横向对比（同一地区内比较）RTT 相同的节点，网页加载耗时理应相同——图中 #SS 和 #Trojan 的「网页加载耗时」无差异，就提供了“逆否命题”的论据。

➤『不对』理由：纵向对比（跨地区比较），RTT 越低的节点，并不意味着更低的「网页加载耗时」，如图中的🇺🇸和🇭🇰。这是因为，还有一个巨大的干扰项 #动态文件 ——暂且搁置，到第3点再谈。

至此，不妨碍我们先提炼第二个有用的结论：

✍️ 严格意义上，节点的 RTT、HTTP(S) 两类延迟都有槽点，但 HTTP(S) 延迟的槽点更大、误导性更强❗️

原文有修改。因字数限制，展开一些论述后，必须剁成两篇

#漫谈 #技术杂谈 #rtt #http #https #延迟 #专线 #协议

对比ss-trojan刷网页的真实耗时.png

439.4 KB

海豚机场测评｜用户侧体验｜测速频道

《 MacBook 刘海的另一解法》 🍏 MacBook 系列的刘海，可谓是众所周知地恶心！应该不会有多少人能自适应吧？！ 目前主流的解法： Dozer (免费, 开源) 二阶收纳、Bartender (收费) 二阶收纳➕增加交互层级，等等。 最近发现一个更原生的解法：利用终端修改 《菜单栏 右侧》的 App icons 间距。非常简单、优雅。 # 在 macOS 终端中执行如下两行 defaults -currentHost write -globalDomain NSStatusItemSelectionPadding…

《 MacBook 刘海：复原篇》

有人会问，在修改菜单栏间距后，如果想要恢复原状，怎么办？有两种方法。

方法1️⃣：在终端执行如下两行

defaults -currentHost delete -globalDomain NSStatusItemSpacing

defaults -currentHost delete -globalDomain NSStatusItemSelectionPadding

# 随后 logout，再 login 即可生效！

方法2️⃣：或基于上回提到的两行命令，将行尾 -int 8 替换为 -int 16 后再次执行。然后 logout → login 即可生效。

—————

注意：修改 / 复原，都只针对「刘海 右侧」。效果对比如图。

—————

此外，若不喜命令行，也可借助 Menu Bar Spacing (免费) 来修改 App icons 间距。借助该程序，甚至无需 logout → login 即可生效❗️

#macos #刘海 #复原 #小技巧 #技术杂谈

《 MacBook 刘海的另一解法》

🍏 MacBook 系列的刘海，可谓是众所周知地恶心！应该不会有多少人能自适应吧？！

目前主流的解法： Dozer (免费, 开源) 二阶收纳、Bartender (收费) 二阶收纳➕增加交互层级，等等。

最近发现一个更原生的解法：利用终端修改 《菜单栏 右侧》的 App icons 间距。非常简单、优雅。

# 在 macOS 终端中执行如下两行 
defaults -currentHost write -globalDomain NSStatusItemSelectionPadding -int 8
defaults -currentHost write -globalDomain NSStatusItemSpacing -int 8
# 然后，log out 当前用户，再 log in 即可生效！
# 最终效果如图所示（on macOS Tahoe 26.1 public Beta）

如果常驻 Apps 特别多，也可叠加 Dozer 使用。截图便是实例。

———————————————
若想要复原，见 下一篇的说明 👈
———————————————

#macos #小技巧 #技术杂谈

海豚机场测评｜用户侧体验｜测速频道

《从 GFW 泄露文件审视网络代理的未来》 9 月 11 日，一份从 GFW 内部流出的文件（见 gfw.report 的报告, 或 TG 推文）颠覆了许多人对代理安全的既有认知：已快进到 通过植入证书来进行 MitM。 1️⃣ 当前主流的代理方式 或不再安全 泄露文件及其讨论 1、讨论 2 等指出：只要你设备的 “证书” 被污染，无论套多少层加密或隧道技术，对于 #GFW 都不过是衣不蔽体。 ⚠️25-09-20 注：积至 (Geedge) 和 GFW 的关联性 争议不休！ 2️⃣ 积至的新技术：以主动…

《积至 和 GFW 究竟有无关联？》

自 gfw.report 该报告 (简称《报告》) 和本频道上回推文发布以来，大量争议聚焦在 ”积至公司“ 是否为 GFW 的关联实体 (含技术共享、白手套)，以及墙是否迎来大幅升级。

争议相关的 三方论点 梳理如下

🔻否定论点，如：
{⓵} 积至有关 FET 组件的部分代码抄袭自开源项目 apernet/ OpenGFW，意味着积至无法获取 GFW 源码，继而推定其不属于 GFW 的关联实体；
{⓶} 若积至与 GFW 无关联，那么基于《报告》所作的推定难免危言耸听；
{⓷} 如果风向走歪，仅凭积至的技术储备，足以让代理上网回归解放前，开发新协议也无解；
{⓸} 方某某 2016 年从北邮病退后，不再牵头 GFW 项目。人走茶凉，积至与 GFW 互不隶属，致使积至技术难以输往 GFW 迭代。
……

🔺肯定论点，如：
[⓵] GFW 为涉密 “9** 计划” 项目成果，自带 “密级”，其主持人 (方某某) 若非执意踩缝纫机，断不敢在他处复刻，故 否论{⓵} 的立论依据缺乏保密常识；
—注：涉密项目与商业项目的工作逻辑迥异。如某知名 985 保密规定覆盖全体 8**、9** 项目。
[⓶] 积至若非 GFW 的实体/白手套，其创立仅 1 年时就接到外国政府的建墙订单，实在不可思议；
[⓷] 积至公司即 GFW 的白手套，却被有意包装为与 GFW 无关，其原因包括：规避潜在的舆论风波、迎合 “密级” 需要，等；
[⓸] 尽管 GFW 和北邮深度绑定，但依惯例，高校总是授予 “领域大专家” 带话语权的终身席位，直至身故——意味着看似在野的积至，其技术库仍能反哺 GFW。
—注：方某某既是院士，又曾主持 9**，更曾任北邮校长，显然备受北邮尊重且话语权应不低。
……

🔷 共识论点，如：
(⓵) 积至虽为中小企业，但偏偏短小精悍，跨国承建了巴、哈、缅、埃塞等国 “GFW”，期间还调动高贵的 国资央企 联合作业；
—注：国资央企仅 98 家，国企 > 40万 家，民企 > 5000万 家
(⓶) 积至参与了新疆、江苏等省墙搭建，即《报告》的此点论述属实；
(⓷) 在特色制度背景下，省墙意味着某种政策的早期试点，但争执双方对试点扩张的概率预期不同。
—注：据哈佛对 1980~2020 年🇨🇳实施政策统计，约 58% 的试点夭折、不再推广全国。
……

✍️ 读者请自行判断更接受哪种论点？ 欢迎补充其他论点……

#漫谈 #技术杂谈 #GFW #积至公司 #积至 #geedge

《从 GFW 泄露文件审视网络代理的未来》

9 月 11 日，一份从 GFW 内部流出的文件（见 gfw.report 的报告, 或 TG 推文）颠覆了许多人对代理安全的既有认知：已快进到 通过植入证书来进行 MitM。

1️⃣ 当前主流的代理方式 或不再安全

泄露文件及其讨论 1、讨论 2 等指出：只要你设备的 “证书” 被污染，无论套多少层加密或隧道技术，对于 #GFW 都不过是衣不蔽体。

⚠️25-09-20 注：积至 (Geedge) 和 GFW 的关联性 争议不休！

2️⃣ 积至的新技术：以主动 MitM 来监管流量

据悉，积至公司的新技术，可通过 蜜汁证书➕MitM 随时监控、解密你的流量——只需通过各种手段，把它的《蜜汁证书》悄悄植入，成为潜伏在你设备里的内鬼，丝滑小连招即成。

该思路与 iOS 部分代理 #App 的 MitM 去广告等场景类似。只是在 #去广告 场景中，你是主动安装第三方证书。而在积至的新技术场景中，你是被动植入第三方 (投毒) 证书❗️

3️⃣ 今后的安全标准：或不能停留在 “传统加密”

RPRX (Xray-core 和 VLESS 开发者) 称其 Reality 协议和抗量子加密 (Post-Quantum Encryption, 简称 Encryption) 特性都独具优势。

开发者推介 ⓵ Reality 对 MitM 的抗性；⓶ 号召中转机场从 SS 切至 Encryption。

频道注：#Reality 至少在 GFW Pro Max 的新疆，表现独一档；但后者的整体表现如何，还有待观察。

━ #专线 机场中，S* 等个别引入 Encryption，又如 L*、Y* 等意外改用 Reality；
━ 现仅 ⓵ Xray >= v25.9.5 [9月5日更新]、⓶ Mihomo >= v1.19.13 [8月27日更新] 等极个别核心的新版本支持 Encryption 特性❗️
━ 基于上述核心的 App 名单，见海豚测速-代理工具篇。可利用版本号按图索骥，跟踪 协议 / 新特性 支持动向。

倘若情况变得更加严峻，#代理协议 开发者与 GFW 免不了新一轮的斗智斗勇。明天，你还会翻墙吗？

（⚠️ 25-09-21 全文内容有调整 ）

#漫谈 #技术杂谈 #vless #抗量子 #encryption #xray #mihomo

《千兆单线程跑不满的常见原因》

测速跑不满、货不对板……算是TG圈的老生常谈。

现总结几个常见的瓶颈点：

1️⃣ #软路由 CPU性能：坑最多！

在招募后端时，我们曾遇到不少：
━ J1900 (早年爆款)、RK3328 (如R2s)、MT7981、S905D (斐讯N1)、RK3528 (如瑞莎e20c) 等低性能CPU
━ ARM v7的古早架构，甚至缺AES硬解

上述芯片通常能跑满国内千兆单线程，会魅惑性地让你以为也能跑满千兆翻墙的单线程？实则不然！

📍实例：黑龙江移动1G🟧、[曾经]广西移动1G、[曾经]浙江联通1G、[曾经]江苏移动1G

🔧1G 建议：X86换 N4500、J4125 及以上，或ARM换 RK3568、MT7986 及以上CPU
🔧2G 建议：X86选 N5105 及以上，ARM选 RK3582、MT7988 及以上CPU

2️⃣ #光猫/猫棒的性能瓶颈：极易忽视

FTTH办理较早/采购偷工减料的光猫性能羸弱，甚至国内测速都跑不满千兆单线程。

📍实例：四川联通1G🟨、广东移动3G🟧、广西电信1G🟫、[曾经]成都联通1.4G、[曾经]安徽电信1G

🔧建议：更换光猫/猫棒

3️⃣ 多层NAT的隐形影响

光猫拨号 + 路由器NAT + 软路由NAT + …（3层及以上NATs），每层转发都有性能损耗和延迟累积

📍实例：[曾经]江西电信1G、[曾经]重庆联通2G

🔧建议：光猫桥接，减少NAT层数

4️⃣ #物理距离 制约：本频道的老生常谈

本机—入口 RTT > 25ms 后的单线程 断崖式掉速

📍实例：《未标注 💉》的远距离后端，如
━ 张家界移动1G（卡在~25ms边缘，🇭🇰/🇯🇵均有 好线路跑得满、差线路跑不满 的“冰火两重天”）
━ 上海电信1G（跑不满🇭🇰）
━ 深圳电信2G、广州移动 1G、清远移动II 1G（跑不满🇯🇵）

🔧建议：参考 粤港远距离、沪日远距离临界线，及解决思路 上篇 和 下篇 。

📚另注：Win系统自带鸡血补丁！

对于本群bot，在 #招募后端 时我们都做过一对一的问题排解。暂未解决的，也都用🟨🟧🟫做过标记（颜色越深，越跑不满）

——
💊经验上，先天跑不满千兆单线程的 #地狱省市 暂不存在！只是，有些家户的网络环境、设备有问题。但切勿把这种个例当一般。

#技术杂谈 #打鸡血 #测速 #千兆单线程

测速问题排查（若追求千兆单线程）.png

416.3 KB

海豚机场测评｜用户侧体验｜测速频道

移动-不同省市到🇭🇰延迟梯度.png

上回基于香港节点分析得出：当本机到入口RTT超过25ms时，会面临两个问题：❶ YouTube娱乐跑分无法突破100w，同时 ❷ 测速也无法跑满千兆单线程。

今天我们来探讨三个与日本节点相关的问题：

1️⃣ 日本节点在国内能否跑到100w油管跑分？

答案：不能。

如图所示，即便是访日最快的上海，通过👑👑超顶尖入口到🇯🇵的RTT也已达32ms。根据这一延迟水平，🇯🇵油管的跑分只能达到约90w。

除非未来上货 "上海-大阪" 专线，将RTT压到20ms左右。

2️⃣ 日本节点会跑不满单线程千兆吗？

答案：不会。

➤ 跑不满单线程千兆主要取决于本机到入口的RTT，而非节点延迟。虽然入口到🇯🇵的延迟远高于入口到🇭🇰的延迟，但通过简单计算可知：跑满日本节点的千兆单线程比跑满香港节点反而容易得多！

➤ 事实上，对于电信宽带 ➜ 沪电入口，全国超过50%的地区都能跑满日本节点的千兆单线程。相比之下，香港节点仅能在广东及其相邻省市才能达到这一水平❗️

3️⃣ 🇯🇵节点延迟高于🇭🇰，访问网站就一定更慢？

答案：未必！

➤首先，对于大部分省市，日本和香港节点的延迟差距在30ms以内。甚至，在江浙沪皖、山东、京津冀、东北的差距仅2～15ms（如图2）。

➤其次，您可以下载 《网页加载分析(改)》 的 #油猴 脚本亲自验证。

➤最后，一个可能令人意外的发现：
即使在日本-香港延迟差距达30ms的国内某城市，对于大多数同时部署了两地CDN的网站，🇯🇵节点延迟虽看似更高，实际加载速度却往往更快！

那么，您平时是更喜欢用🇯🇵还是🇭🇰呢？

#技术杂谈 #软路由

三网-不同省市到🇯🇵延迟梯度.png

496.1 KB

不同省市的🇭🇰与🇯🇵延迟差距.png

345.4 KB

《RTT和HTTPS，哪种延迟更有参考价值？》
#技术杂谈 #延迟 #RTT #HTTPS #时延 #mihomo

很多人在纠结 Mihomo核心 #统一延迟 是否☑️ 时，常面临两种观点：有人坚持 RTT 延迟测试"自欺欺人"，有人推崇 RTT 作为首选指标。

✍️全文省流：
在2025年，选RTT/统一延迟未尝不可！
但若回到2019年之前，那就HTTP(S)延迟

1️⃣ RTT vs HTTPS延迟的区别

见 往期推文 👈

2️⃣ 为什么说RTT在今天更有参考价值？

❶ 连接复用技术普及
➤ HTTP Keep-Alive 已成为标准配置
➤ HTTP/2 和 HTTP/3 支持多路复用，标志着网络瓶颈从"建立连接的耗时"转移到了"往返延迟RTT"❗️
➤ TLS 1.3 优化（从2-RTT减至1-RTT，支持0-RTT恢复）

🔰根据 HTTP Archive 对近3000万个网站样本的统计，早在2023年支持HTTP/2的网站就已超过70%。

❷ 实测验证
➤ 在已建立连接后，无论是主文档(document)、图片，还是其他放置在CDN的素材，加载时间都更接近RTT值❗️
➤ 经测试ChatGPT、谷歌、v2ex等网站的素材加载均如此。

3️⃣ 实用结论

❶ 初次访问🟡：完整HTTPS延迟更有参考价值

🔰此类访问示例：
打开 aaa.com 后立即舍弃，然后访问 bbb.com 后立即舍弃，继续 ccc.com ……
（周而复始，永不重样！但脱离了正常场景❓）……

❷ 持续访问🟢：RTT最关键，特别对于：
➤ 重复访问的网站及子页面
➤ 使用HTTP/2或HTTP/3的现代网站 （今天的绝大多数❗️）
➤ 使用CDN的网站
➤ 交互式App（如社交媒体、音视频/会议、游戏等）

🔰此类访问示例：
¹ 利用 DoH、DoH3、DoQ 等协议查询 DNS。
² 打开 telegram.org 后，点击二级页面 FAQ，然后转去 Moderation 继续浏览。
³ 在 TG群、Reddit、V2ex等灌水，在 YouTube、TikTok、网飞等刷视频，在谷歌、必应、ChatGPT等获取资讯

在2025年还在固守成见——认定RTT是”自欺欺人“。对此，你怎么看？

统一延迟：勾不勾？.jpg

158.4 KB

日趋主流的HTTP2和HTTP3.png

388.6 KB

《关于YouTube跑分和入口距离两个看似不相关的问题》

1️⃣ 先谈谈 YouTube 跑分

许多人喜欢用 油管跑分 作为节点优劣的评估工具，看谁能突破「100万、200万、…」。但实际上，这种 #油管娱乐分，和你本地的带宽关联不大！

🎯 举个极端例子：
假设有人在 上海 拉来一条 #万兆宽带，或许会 误以为 YouTube 跑分能突破100万？

No way！

如果按上海电信走👑👑超顶尖专线到🇭🇰的29ms RTT来估计，闲时的YouTube跑分也很难超过90w——哪怕你用10G家宽，甚至40G IDC宽带。

💡据观察，在谷歌RTT ＞ 25ms (大约) 时，YouTube跑分上限的估算公式：
上限分 = 130 - RTT * 抖动惩罚系数

💡或，更粗略的：
上限分 ≈ 120 - RTT [电/联]
上限分 ≈ 110 - RTT [移动]

若想突破200w分，谷歌RTT则要控制在10ms以内➕千兆宽带（不刚需2000M宽带）❗️

注意共同的前提条件必须满足：终端设备🉑硬解4k油管视频，且有线连路由器，且本地宽带＞500M。

既然 YouTube 跑分和带宽的关系不大，那还剩下什么意义呢？它可以辅助对比节点表现。例如，你有同样25ms RTT的两个节点，如果其中一个娱乐分100w，另一个90w，那么100w分的节点 #抖动 无疑更低。仅此而已！



2️⃣ 25ms RTT 的另一个“魔咒”

在 Linux / BSD 默认参数下，TCP 吞吐在 RTT 超过 25ms 后会明显下降。

这个问题在本频道早前的《TCP 鸡血补丁》推文中曾有讨论。另外，谷歌云☁️ 也提供了详细的原理讲解。

事实上，这个原理恰好又表现成两个看似不相关的症状：

✅ 后端到入口 ＞25ms ➜ 跑不满 千兆单线程
✅ 终端到节点 ＞25ms ➜ YouTube 娱乐跑分 达不到100w

注意：仅广东及周边省市能够同时化解以上2个症状，如图所示❗️

虽然前者能通过 sysctl.conf #打鸡血 来攻克，但后者因谷歌(利用RTT估算用户侧带宽)的算法写死，无法逆转。


🧩 所以，25ms RTT 既是 #远距离 临界线，也是 #油管娱乐分 的百万分水岭。你看到的“突破”，其实都是这条延迟线在背后捣鬼！

#技术杂谈 #软路由

电信-不同省市到🇭🇰延迟梯度.png

498.9 KB

联通-不同省市到🇭🇰延迟梯度.png

455.5 KB

移动-不同省市到🇭🇰延迟梯度.png

459.2 KB

电信：今天次优的深圳BGP ⚔️ 曾经Top1的唯云

电信宽带-深圳BGP对比唯云.png

237.8 KB

联通宽带-深联163对比唯云.png

220.3 KB

移动宽带-深联BGP对比唯云.png

272.3 KB

#技术杂谈
以下是综合整理的IP检测与落地检测网站列表：

———

1️⃣ IP检测类工具
1. 综合信息查询
1. IP2Location.io
   - 网址：https://www.ip2location.io
   - 特点：提供IP地理定位（国家、城市、经纬度、ISP、ASN、连接速度等）及代理检测（是否使用VPN、服务器代理等），支持API集成和批量查询。 
   - 适用场景：企业级网络安全管理、跨境电商IP质量筛查、广告精准投放。

2. IPinfo.io
   - 网址：https://ipinfo.io 
   - 特点：提供IP的地理位置、ASN、ISP、IP类型（机房/商业）等详细信息，支持API集成，可判断IP是否为数据中心或住宅IP。 
   - 适用场景：基础IP信息查询，判断IP归属及服务商资质。

3. ip.sb
   - 网址：https://ip.sb 
   - 特点：支持IPv4/IPv6地址查询，提供纯文本和JSON格式的GeoIP信息（国家、城市、经纬度），适合开发者通过命令行快速获取公网IP。 
   - 适用场景：快速查询出口IP，结合API集成到脚本中。

4. IPLocation.net
   - 网址：https://www.iplocation.net 
   - 特点：多数据源交叉验证地理位置，显示代理/TOR节点状态，适合快速查询基础信息。

5. IP2Proxy Demo
   - 网址：https://www.ip2proxy.com/demo#proxyresult 
   - 特点：在线检测IP是否为代理，显示代理类型（如VPN、TOR、数据中心）、威胁等级、使用类型（如ISP、商业）、ASN等详细信息，支持开发者API集成。
   - 适用场景：精准识别代理IP类型及风险。

———

2. 风险评分与黑名单检测
1. Scamalytics
   - 网址：https://scamalytics.com 
   - 特点：通过欺诈评分（0-100分）评估IP风险，检测是否涉及垃圾邮件、网络攻击或黑名单，支持代理类型识别（VPN/服务器）。 
   - 适用场景：跨境电商账号注册前筛查高危IP。

2. AbuseIPDB
   - 网址：https://www.abuseipdb.com 
   - 特点：社区驱动的黑名单数据库，用户可举报恶意IP，提供IP滥用报告和威胁类型分类。

———

3. 代理与匿名性检测
1. ping0.cc
   - 网址：https://ping0.cc 
   - 特点：精准检测IP类型（原生/广播IP）、风控值（0-100分）及地理位置一致性，通过大数据分析IP段实际用途（家庭或机房）。 
   - 适用场景：跨境电商/TikTok运营规避平台风控，验证IP是否被标记为机房IP。

2. Whoer.net
   - 网址：https://whoer.net 
   - 特点：检测代理/VPN使用情况，提供匿名度评分（0-100%），显示DNS泄露、浏览器指纹等隐私信息。

3. IP111.cn
   - 网址：https://www.ip111.cn
   - 特点：国内专用工具，检测IP封禁状态及代理情况。

———

2️⃣ 入口/落地的TCPing及路由检测
1. 网络性能与延迟测试
1. 站长工具（BOCE）
   - 网址：https://www.boce.com 
   - 特点：国内测速平台，支持Ping检测、HTTP响应测试，模拟用户本地打开速度，提供全国多节点延迟数据。

2. ITdog.cn 
   - 网址：https://www.itdog.cn 
   - 特点：多地Ping测试，覆盖电信、联通、移动及海外节点，实时显示最快/最慢/平均延迟，适合排查网络拥堵。

———

2. 地理位置与DNS出口检测
1. ip.skk.moe
   - 网址：https://ip.skk.moe 
   - 特点：综合地理位置、DNS出口IP、CDN命中节点检测，支持国内外IP查询，适合验证网络环境是否被CDN代理。 
   - 适用场景：排查DNS污染或CDN配置问题。

2. IPjiance.com
   - 网址：https://www.ipjiance.com 
   - 特点：检测IP纯净度、黑名单状态、云服务关联性，支持跨境电商平台合规性验证。


仅供参考，欢迎评论区留言补充！

《远距离用户侧跑不满千兆单线程翻墙之谜 & 破解之道：下篇》

#技术杂谈

承上篇👈

1️⃣ #打鸡血 💉一定奏效吗？

对。只要某机场在入口省市能跑1G，那么理论上，#远距离 也能跑到近乎同样速度。已利用 #一线机场 #二线机场 实测，总是奏效！

感兴趣见谷歌云☁️的论述

2️⃣ 参数的试错风险和注意事项

建议二次修改《评论区上传的sysctl.conf》，节省试错时间：
❶ 先选一个距你家最近的 /etc/sysctl.conf 作为蓝本，
❷ 再基于此调试net.ipv4.tcp_rmem的最小值、默认值、最大值，取值大小俗称“剂量”。

⚠️ 这3个参数，因你的城市、运营商、带宽及软路由CPU架构而异。
➤若剂量太离谱，会导致断流
➤若剂量不精细，抖动不够优雅

📝 剂量建议：
➤性能差的软路由，需更大剂量
➤移动宽带，比电/联需更大剂量
➤省会、地市、县城、乡镇，逐级加剂量
➤总之，越导致你家⇄入口RTT＞临界延迟的干扰，越要加大剂量

📐该临界延迟约在25～30ms之间

若追求完美毕业，务必反复尝试➕仔细打磨。纯属💦体力活！

3️⃣ 鸡血实验的操作台

✅首选：Linux。能做到大胆改，随便试，毫无后遗症！若效果不佳，另调剂量并替换到/etc/sysctl.conf，重启后又是一条好汉。
⭕️次选：Win。因Windows修改注册表后，恢复或会带记忆性，不如Linux无损试错。建议利用专业版Win附赠的 #HyperV 虚拟一个 #Openwrt 进行尝试。
❌勿选：近4年的 #macOS、#iOS，或未root的 #安卓，因参数已锁死，无解💀💀💀

注意：
调试时建议🔌有线➕一线机场，尽量排除干扰！

4️⃣ 进阶参数

数据包排队规则net.core.default_qdisc也可改：
➤fq，默认，稳妥之选
➤fq_pie，抖动控制很香，但性能开销加剧，仅建议x86或临近入口省份的arm尝试
➤cake，适合武汉等 #先天圣地 的精益求精。离多个入口距离不一者慎选！

其他：欢迎补充✍️

5️⃣ 主/旁路由💉鸡血后，局域网设备能否跟着沾光？

能。但翻墙须部署在鸡血路由上（若其为虚拟机，翻墙插件也要挂在同一虚拟机内）。否则，buff无法传递。具体见图“二”。

⚙️更专业的资料，请参考谷歌云☁️Google Cloud教程


欢迎在评论区补充、分享经验，让鸡血补丁更臻完善。

《远距离用户侧跑不满千兆单线程翻墙之谜 & 破解之道：上篇》

#技术杂谈

1️⃣ 远距离路由器→专线机场入口的单线程掉速问题和表现。

当你家的路由器距离专线入口（或前置）较远时，想在默认状态下跑满本地宽带的上限几乎是不可能的❗️

该问题的诱发情形：
- 距 广东 较远，如在江苏、河南、西南、东北，使用🇭🇰粤港专线
- 距 上海 较远，如在两广、西南、西北、东北，使用🇯🇵沪日专线
- 距 北京 较远，如在湖南、两广、东南、西南，使用🇩🇪京德/🇪🇺京欧专线

- 其他节点的入口/前置➕用户侧地理区位，同理。

经验上，一个共性诱因是：当你家本地路由器→入口的TCP Ping

超过25～30ms之间的某个门槛值后，单线程速度*必然*锐减

，至高会卡在650Mbps左右。

有趣的是，YouTube娱乐跑分与RTT延迟也密切相关，甚至比真实带宽的重要性还要大得多！油管正是通过测量RTT，来间接估算本地带宽容量（娱乐跑分）的，毕竟绝大多数用户都使用各类操作系统的默认TCP参数

。

🍀🍀🍀
当然，如果你家恰好

在

#武汉

#合肥

#上海

等

省会城市，那么恭喜你身处先天圣地🎉！因为你家→三大入口都不远，三花聚顶，“先天”都能跑满！制约你跑满千兆单线程的干扰因素，只会来自机场本身，后文的内容就不用看了。

2️⃣ 那么除了搬家之外，有无破解之道？

有。但需要在家里部署一个基于Linux/BSD内核的软路由，如 #Openwrt，且翻墙环境也要部署在该软路由之上！

通过修改软路由的TCP Buffer参数（俗称 #打鸡血 ），借助它作为主路由或透明网关（旁路由），即可显著提升网络性能，使局域网内的所有设备都能蹭到“鸡血状态”。

⚠️注意：
- 对于Mac Mini软路由。由于macOS 12.x Monterey开始，🍎限制了sysctl.conf修改。因此，只能考虑在macOS里运行一个Linux虚拟机，然后利用该虚拟机

同时充当透明网关＋挂载mihomo/singbox翻墙等服务

。否则，也无解。
- 对于iOS/Apple TV。情况与macOS类似，在早几年前的某个版本之后，哪怕越狱也无法修改。
- 对于Android。如果无root，就无法修改sysctl.conf。

3️⃣ 具体如何操作？

若有 #软路由，其实很简单，仅需一步！

🛠思路：调整Linux软路由的 /etc/sysctl.conf ，尤其是有关TCP接收缓冲区tcp_rmem的一行关键参数：

net.ipv4.tcp_rmem = . . . (此处的三个数值，最好基于你所在的省市➕本地带宽进行微调)

为什么这样做有效？因为，调整TCP接收缓冲区（recv buffer）可以提高网络吞吐量，特别是在高延迟或高带宽的网络环境中。较大的接收缓冲区允许更多的数据在传输过程中被缓存，从而减少了数据包丢失和重传的可能性。

《深圳联通/电信入口的QoS：哪些省市、哪家宽带用户应回避？》

#技术杂谈

1、#广港专线 入口的潮流变化

采用深联入口的机场，从早期“十三太保"，逐渐扩大阵容，至今或已有数十家。因联通的跨境专线向来质优（较之移动）、价廉（较之电信），备受阿里云、华为云等大厂的跨境服务所青睐。

然而，随着三大运营商打击PCDN，相继祭出跨网、跨省流量结算政策，#广港 方向的节点表现受到较大波及，致使部分省份×运营商的用户体验堪忧。

随即，少部分机场增加广东电信入口（如 穗电、惠电，以及四家 #一线机场 的深电），旨在解决跨网QoS问题。

2、那么跨网、跨省问题解决了吗？

简单剧透：解决了一部分，但未完全解决

⁉️

下面用两家一线机场的 深圳电/联 入口简单演示。

3、#深圳联通 入口的跨网/跨省延迟及体验。

💥剧透

：联通宽带->联通入口全国正常，其他宽带视省份＋运营商有差异。

❶ 电信宽带（图1a）：
❌ 建议回避：福建、江苏、江西、四川、重庆
💔 勉强可用：湖南、陕西，以及除深圳外的广东城市
✅ 基本正常：余下省份＋深圳市内

❷ 联通宽带（图1b）：
✅ 全国都基本正常

❸ 移动宽带（图1c）：
❌ 建议回避：河南、辽宁、吉林、山东、四川、西藏、广西
💔 勉强可用：海南、贵州、福建、江西，江苏、北京、河北，以及广东省内
✅ 基本正常：余下省份

4、#深圳电信 入口的跨网/跨省延迟及体验。

💥剧透

：

① 电信入口哪怕对

电信宽带用户

都未必是解药
② 电信疯起来，自家宽带的跨省流量也丢包⁉️

❶ 电信宽带（图2a）：
✅ 基本正常：仅江西、海南、福建、宁夏、西藏，部分江苏城市
💔 勉强可用：上海、天津，以及除深圳外的广东城市
❌ 建议回避：余下

❷ 联通宽带（图2b）：
✅ 基本正常：仅四川、陕西、甘肃、海南、贵州、广东
💔 勉强可用：西藏、河北、湖北、江苏
❌ 建议回避：余下

❸ 移动宽带（图2c）：
✅ 基本正常：仅北京、吉林、天津、青海、宁夏、西藏
💔 勉强可用：江苏、河北、广西、陕西、黑龙江，广东
❌ 建议回避：余下

5、对于不幸的省份×运营商组合，怎么办？

任选其一：
❶ 树挪死、人挪活——抛弃🇭🇰🇸🇬，拥抱沪日/京德
❷ 加钱上大厂云或自建
❸ 换宽带

1a 电信 至 深圳联通.png

230.9 KB

1b 联通 至 深圳联通.png

177.6 KB

1c 移动 至 深圳联通.png

225.7 KB

2a 电信 至 深圳电信.png

228.9 KB

2b 联通 至 深圳电信.png

204.1 KB

3c 移动 至 深圳电信.png

220.2 KB

#15分钟看懂测试结果 #近期需要关注的入口QoS #FAQ #技术杂谈

1. 测试结果的4个核心构成：

延迟、带宽、入口、落地（出口）。不存在跨网QoS时，前两者是评判节点实际体验的核心之核心。在这4个构成中，延迟的门道最多，留在最后梳理。

2. 拓扑图中的入口及参考点：

在拓扑测试中，入口既有可能是节点的真正入口，也可能是入口的前置服务器。不过深究这个细节，对绝大多数场景的意义不大。

☢️ 目前，可能更值得注意的是跨网QoS问题。
❶ 自6月以来，三大运营商为打击PCDN，相继出台跨网流量的结算政策——流量上行需缴结算费。其中，移动最早开始，而联通和电信则从9月底开始。于是，机场入口受到波及，因入口需要转发国外数据回传给用户，这恰好对应入口的上行流量。
❷ 为降低支付给异网运营商的结算费，入口运营商（如深联）对高峰时段的上行流量进行QoS，导致延迟高企、带宽折损。

在三大入口省市中，广东的运营商最为毒辣！因此，
❶ 各机场的跨网问题都爆发在🇭🇰、🇸🇬等广港线路的节点
❷ 暂未影响到沪日、京德的节点，但不排除今后出现的可能性
❸ 若高度依赖🇭🇰🇸🇬节点，务必考虑与自己宽带同网的入口❗️

👉三网专线入口天梯表(持续更新)👈


3. 拓扑图中的落地：

更好的落地（出口）通常意味着更优质的互联、延迟、带宽，同时成本也更高。但对于挑选机场这件事来说，落地若非“月抛”，就不太需要着重关注——因为延迟和带宽能在很大程度上反映出落地的好坏。

4. 测速带宽的参考点：

主流测速bot均使用MB每秒。根据通行约定，MB是MByte的缩写，Mb是Mbit的缩写。两者之间存在1:8的换算关系，即125MB＝1000Mb。

【用户侧👨🏻‍💻】只需关注 单线程 测速❗️
❶ 刷网页、音/视频、浏览器自带下载等，均走单线程。注意：仅迅雷等专业下载器才涉及多线程。
❷ 网飞、油管等平台4K观影，建议≥50Mbps单线程。若进阶追求”拖动秒加载“，建议≥400Mbps（即50MB/s）甚至更高。

【商家侧🕋】更关注的一般是 多线程 测速，以便检查带宽的极限。

🔐远距离用户突破千兆单线程限速之法：上篇 & 下篇🔐


5. 延迟结果的类型及参考点：

首先，不同测速bot的延迟有不同结果：
➤对于HTTP延迟测试，结果包括RTT和HTTP延迟。
例如本频道此前发布的一系列《不同机场横向对比测试》中的“油管HTTP”延迟，以及海豚测速群的@gagacesu_bot即属此类。

➤对于HTTPS延迟测试，结果包括TLS-RTT和HTTPS延迟。
例如本频道此前发布的一系列《不同机场横向对比测试》中的“谷歌RTT”即在此类。

那么，哪种延迟更贴近实际使用场景呢？

❶ 对于 首次访问 某个网站，主要参考HTTP或HTTPS延迟。在这两者中，HTTP应用将逐渐淘汰，HTTPS现已成最主流，建议以后者为准。

❷ 对于 往复访问 同一网站或其子页面，以及游戏、即时通讯App、油管娱乐跑分等，主要参考(TLS-)RTT。

📌 值得注意：
在近年的浏览器、聊天软件及翻墙软件中，都默认启用 长连接（Keep-Alive）机制。所以在访问HTTP(s)网站时，只要仍在keep-alive状态下发起后续的网站访问、即时通讯等，都只需再进行1次TLS握手🤝，而不需要重新建立TCP连接和完整的TLS握手流程，此时参考TLS-RTT延迟即可。

综上，在正常情况下，延迟参考价值的优先级为：
(TLS-)RTT ＞HTTPS＞HTTP

6. 延迟多少算好？

1️⃣ 若以网页体验（起速非0时）粗略看，
❶ RTT ≤ 100ms，网页几乎秒开
❷ RTT ≤ 150ms，大多数网页秒开
❸ RTT ≤ 200ms，轻量网页秒开，但重型网页略有延迟

2️⃣ 若以苛刻标准评判节点质量，
❶ 🇭🇰RTT
—穗深 ≤25ms上乘，≤20ms顶尖【直连极限 深港7ms】
—武汉 ≤40ms上乘，≤35ms顶尖
—上海 ≤45ms上乘，≤40ms顶尖
—成都 ≤50ms上乘，≤45ms顶尖
—北京 ≤55ms上乘，≤50ms顶尖
—乌鲁木齐 ≤100ms上乘，≤95ms顶尖

❷ 🇯🇵RTT
—上海 ≤55ms上乘，≤45ms顶尖 【直连极限29ms】
—武汉 ≤70ms上乘，≤60ms顶尖
—北京 ≤80ms上乘，≤70ms顶尖
—穗深/成都 ≤85ms上乘，≤75ms顶尖
—乌鲁木齐 ≤110ms上乘，≤105ms顶尖

❸ 🇪🇺核心国RTT，以🇩🇪为例
—乌鲁木齐 [墙外TSR+] ≤85ms、二连浩特 [墙外ERMC+] ≤94ms
—北京 ≤160ms上乘，≤145ms顶尖【北京联通走ERMC 2020/旧线路，直连极限109/124ms】
—武汉 ≤180ms上乘，≤165ms顶尖
—上海 ≤185ms上乘，≤170ms顶尖 【上海电信走TSR 2021/旧线路，直连极限136/147ms】
—穗深/成都 ≤195ms上乘，≤180ms顶尖
—🇭🇰 RETN [乌鲁木齐-↩️︎TSR 2021/旧] ≈143/159ms，电讯盈科 [北京↩️︎ERMC 2020/旧] ≈146/169ms
—乌鲁木齐[墙内] ≤210ms上乘，≤195ms顶尖

注：
① 联通/电信的中欧陆缆，于2020/2021年新扩容的线路因不再绕行莫斯科、斯堪的纳维亚半岛，延迟有优化。
② 对于主流的英、新、美节点延迟：
🇬🇧：以德国/荷兰

＋5ms为参考；
🇸🇬：以香港＋40ms为参考；
🇺🇸：以日本＋90ms/150ms作为美西/美东的参考。

#深联十三太保 再见， #前海四杰 你好！
《对AS135061 深圳前海IXP的观察》

#技术杂谈

今日， #原唯云四杰 新换了 #深圳前海IXP 的BGP。从目前本频道掌握的信息来看，梳理如下几个常见疑问和可能的答案：

1️⃣ 深圳前海IXP是什么？

四大国家新型互联网交换中心（IXP）之一，属于2019年以来国家级战略“东数西算”配套设施，致力改善区内跨网及东/西部之间的网络性能。

新IXP分布：深圳前海、宁夏中卫、浙江杭州、上海临港。
✍️ 如前海已接入电、联、移、广四大运营商，华为、阿里、腾讯等大厂云，以及部分二级运营商和IaaS。

2️⃣ 新型IXP相对于旧的16个NAP有何优势？

❶ 提升跨运营商/IDC的网间互通性能。

✍️ 例如，杭州电信到杭州移动曾经跳数较多（杭电 -> 沪电 -> 上海NAP -> 沪移 -> 杭移），导致跨网时延居高不下。而IXP可实现在杭州本地互联，显著降低延迟。

❷ 改善远距离尤其东/西部间的网络性能。

✍️ 如宁夏-北京，从原本35ms（西安NAP）大幅降低至20ms（中卫IXP）。此外，中卫IXP周边大区也可从中获益。

3️⃣ 一个自然而然的问题，新型IXP入口的疗效究竟如何？

不看纸面，看疗效。本频道借助 #乌鲁木齐电信 后端对延迟进行测试。

该观测点的优势：
❶ 首先它是电信，契合AS135061的电/联双组网；
❷ 相对深圳，既符合远距离，也归属IXP重点优化的西部；
❸ 乌鲁木齐—宁夏IXP—深圳IXP，较之“乌市—西安NAP—广州NAP—深圳”的传统路由基本不新增绕路。

遗憾的是，我们 🚫

未找到🚫

前海IXP相对于深圳联通具有时延优势

的证据❗️
✍️ 如 #库洛米 (深IXP) 对比 #YTOO (深联) 的🇭🇰🇸🇬，延迟🈚显著优化；反倒略逊YTOO一筹，着实出乎意料！

4️⃣ 补充

10月1日
❌ 据成都电＋联、广州移动、湖北移动、广西电＋移的测试，丢包、掉速严重。
☢️ 晚高峰和闲时差异巨大：深圳/广州电信
✅ 带宽与延迟稳定：珠海/佛山联通，及走 #无锡Pub云 的上海、浙江。

有趣的是，以成都为例： ❶奶昔强改host到

无锡

入口后大幅改善。❷IMM的前海跨省性能，属四杰里唯一较安好的。

总之，IXP跨区跨网仍不完美，建议谨慎决定❗️
✍️ 其他区域体验，欢迎留言补充

#唯云四杰  #新疆电信  #深圳前海IXP

新疆电信-库洛米-前海IXP.jpg

274.3 KB

新疆电信-奶昔.jpg

734.4 KB

新疆电信-IMM.jpg

615.2 KB

新疆电信-Amy.jpg

503 KB

新疆电信-库洛米.jpg

349.7 KB

新疆电信-YTOO.jpg

488 KB

图例.png

232.4 KB

#技术杂谈
针对一些意见的回应：

1️⃣ 大、小包是指什么？

大小包的称呼是取自TG圈一种通俗化的说法，而非我们原创。严格来说，小包 指小尺寸的数据请求，大包 指较大的数据请求。

2️⃣ 数据请求多大算大，多小算小？

首先，我们不是基于“先验”来定义，而是基于各机场的实际表现进行“后验”概括。从之前的图来看，部分机场香港节点在2MB和5MB之间存在跳跃，那么姑且概括2MB及以下为小包，5MB及以上为大包。这仅仅是便于描述的概括。

3️⃣ 有无可能所谓“阴阳分流”指的是传输段，而不是落地？

确有可能。事实上，有关阴阳分流，暂可从大家集思广益中梳理如下可能：

❶

Github CDN优化策略

。这点首先排除。从基于相同控制变量的实测来看，部分机场有延迟跳跃，而与此同时的另2个(对照组)机场却无延迟跳跃。假如Github CDN有优化策略，那么没理由针对不同机场呈

歧视性差异

。
📝注1：DNS均套香港IP的ECS，只会就近连🇸🇬CDN。
📝注2：Github在亚太仅有🇯🇵🇰🇷🇸🇬三处CDNs，但香港至日(韩) RTT约52ms(76ms)，都远大于阴阳25ms剪刀差。

❷

国内段路由在测试时存在变化

。该可能性也可以排除，因控制变量包括同一软路由和宽带、深联入口、测试在短时间内一次完成。测试的网络环境既非广电宽带，也非二级运营商，且维持相同控制变量。

❸ 落地存在分流。这是最具争议的一种可能性，起源于坊间关于Jinx的传言及讨论。今日，我们又利用同处新加坡的VPS自建网盘实测，

虽不能彻底排除这一可能性，但其发生的概率应当降低

。理由是：我们通过测试自建VPS网盘的延迟，不论数据包尺寸，#原唯云四杰 和 #TKV 延迟均在145ms左右且IP均为同一落地IP——该延迟接近阴阳线路的“小包”延迟155ms，但高于阴阳线路的“大包”（或白名单）延迟130ms。

❹ 跨境线路的分流，或许是最大的可能性！可能的解释是：小包被路由到一条成本占优的链路连通落地，可能经过更多中间节点，因此延迟更高；大包则被路由到一条延迟较低（但成本不占优）的链路。

4️⃣ 再谈阴阳分流对用户和商家的影响。

如果可能性❹是成立的，就有必要从三方面来谈：

👥 用户体验

。
由于小数据请求场景中，网络性能要求不高，如常规网页场景，通常50ms内的

延迟差

都不易察觉。而流媒体场景，传输性能的敏感度更高（如YouTube娱乐分就与RTT延迟

负相关

），则适合走“大包”链路确保低延迟。其他场景就看商家的

白名单

如何设置了。

💼 商家成本

。
据Akamai统计，Smaller Packet（小包）虽单个包小，但累积量大，占全球70%以上流量。将小包流量通过较为经济的高延迟链路传输，节省带宽成本；而将大包通过低延迟、高成本链路，确保传输质量。这在运营成本上，也合乎情理。

💰 产品售价

。
阴阳分流的短板似乎不多，但好处呢？有助于在成本、售价和用户体验三者之间找到 #

平衡点

。
如果商家在削减自身成本的基础上，

进一步让利给用户，将售价定在甜点区

（如专线 ≤0.2元/GB），那必定喜闻乐见。例如回应过此事的机场/频道，就不失为一家在三者之间取得较好平衡的例子，也是值得推荐的。

1️⃣ 首先，我们从未试图给某些机场或服务商“定罪”，而是通过客观数据呈现现象，并鼓励用户自己分析和判断。我们的意图是帮助大家更好地了解机场节点的实际表现，而不是去刻意偏袒某一方。#技术杂谈

本频道从不以盈利为目的，无论是测速，还是推广。
本频道立场更倾向站在用户侧，而非机场主侧。甚至，既有评测也大多是自购订阅和群友送测。

2️⃣ 我们理解有些用户可能确实因为这些分流策略而受益，比如在某些场景下通过优化的节点获得更低延迟的体验。

哪怕这个体验仅仅来自刷新节点延迟、见到较低的纸面延迟而获取到的快感。

然而，这种策略在特定高风险场景下（如访问高安全性网站）*可能*导致意外后果。或许我们的测试暂时还不够全面，但真理永远是在正反驳斥中越辩越明。

📌为什么说只是一种*可能*？诚然，也有可能是线路段出现分流——这个细枝末节，我们会持续关注。但不论如何，更重要的一点是，降低成本却蒙蔽用户的行为，终归不可取。

我们希望抛砖引玉，呼吁更深入、更专业、更全面的讨论加入进来！

3️⃣ 网络技术和架构复杂多样，我们非常欢迎不同的意见和更多的讨论。通过多方探论，让大家能够更全面地认识到不同策略背后的利弊，真正成为受益者，而不是以某种上位者姿态宣布谁为“受益者”。

理性评估无疑好过感性评判，我们希望的是尽可能基于公开、透明、可复制的方法论得出客观的证据，而不是玩江湖、摆资历的泛泛而谈。

📌各类图中都有复现思路和关键步骤，见相应的Methodology for Replication

4️⃣ 我们的测试结果和分析是基于当前环境下的观察，旨在揭示一种可能的现象，而不是对大厂架构或特定策略的全面判断。我们很愿意与大家一同探讨这些策略的合理性，促进对机场节点的更深认识。

📌郑重强调：本频道从不鼓励因为某机场的某一方面很好就一味鼓吹，也不建议因为某一方面较差就一棒打死。

最后还有一句话：如果有建设性的驳斥，非常欢迎！但是 Please stop the cheap talk. Just show us data, show us evidence!

#原唯云四杰 #奶昔 #库洛米 #IMM #花云 #咸鱼加速器 #TKV #阴阳分流 #香港 #广港 #技术杂谈

1️⃣ 我们尝试厘清究竟是Jinx的阴阳分流策略，还是奶昔自己的策略。遗憾得知，不管是Jinx还是Eons落地节点，都存在阴阳分流。

2️⃣ 意外发现，TKV也*可能*存在大小包的阴阳分流。

控制变量：
❶ 同一个网络环境（含运营商＋Openwrt＋Openclash＋深联入口机场）排除软硬件和国内线路干扰。
❷ 相似的时间段：排除时段干扰。除此，每次对同一机场节点连续、每隔2秒一轮curl，且每轮都逐个curl不同大小包，以此循环100轮。
❸ Curl同一网站即Github的🇸🇬CDN：排除机场对流媒体（或其他正常分流需求）的识别干扰。

对照组：
❶ 符合常理的机场相应区域节点

FAQ：
❶ 这个图是什么？

这是折线图。
横轴：包大小(Packet Size)，由小至大依次是：512KB、1M、2M、5M、10M、25M。
纵轴：利用节点访问Github的HTTP延迟
图中的每一条线，代表某个机场的某个节点

❷ 这个图怎么看？
理论上，如果没有阴阳分流策略，不论数据包文件有多大，从客户端发出请求到接收到第一个字节响应的时间（Start Transfer Time）都应当趋同。
#️⃣ 例如 #FlowerCloud 和 #NexusCloud (咸鱼加速器) 的延迟近乎一根水平线，这才是正常情况。
反之，如果数据包大小能够改变延迟表现，那就意味着存在“大小包分流”。
#️⃣ 例如，图中 #Nexitally 、#Kuromis 、#IMM 、#TKV 都在2MB与5MB之间存在“延迟跳跃”（约25ms断层），那么就有理由怀疑，2MB及以下、5MB及以上走的实际链路是不同的。否则，不会出现这种反常情况。

❸ 只要用起来顺手，阴阳分流又能奈我何？

首先，2MB的数据包在网页浏览中已经不算小了，哪怕图片素材很少的谷歌搜索页面都在2~10MB左右。

然后，可以想象一个场景：如果一个页面是2MB，下一个页面是5MB甚至更高，那么浏览时因自动触发的阴阳分流，*可能*导致访问网站的IP反复横跳——此时，轻则触发部分网站的验证码；重则导致账号被封❗️

#️⃣ 这在访问 #OpenAI #ChatGPT #Claude #Twitter 等高风控网站时，*可能*非常危险☠️

1阴阳分流：原唯云四杰区分Jinx和Eons节点.png

273.4 KB

2阴阳分流：加入TKV.png

273 KB