由TG散户群体自发形成的测速社区。专注*用户测*的体验：单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
小三通指数：哪个省会距离三大入口表现得更像 三边形战士？受测评 vps 国际互联的帖子启发，本推文提出一个好玩（但可能属于 “没啥大用” 的冷知识）的综合指标——
小三通指数。提起 “哪个省翻墙最舒服”，很多人第一反应多半是
广东，毕竟到🇭🇰只要 5-19ms，堪比省内网。但，真的是这样吗？如果我们既要🇭🇰，又要日本🇯🇵和欧洲🇪🇺节点呢？
事实上，本推文构造的「
小三通指数」很直观反映出：广东到日本、德国的延迟偏高，较偏科，反倒不如中部省份百搭！如湖南、江西的省会，到香港也就 15ms 左右，体感上和广东一样顺滑，但去日、欧的延迟却优秀得多。
———
简洁但略枯燥的统计思路：
为了让小三通指数能够反映各个省会的整体表现，我们需要收集尽可能多维度的信息。但为了对比方便，1 维信息又是更直观的。
在目前机场主流的专线/入口中，粤港、沪日、京德属于三大主流。所以，我们首先收集各个省会→三大主流入口的延迟表现（三维信息），然后用经验累计分布函数（eCDF）构造 3 个相应的子指标，便于对比某个城市在使用某一专线时的相对表现。最后对某个城市的 3 个子指标用加权几何平均数进行降维，其中权数用统计月报的测试数据，以便反映大众的、真实的地区偏好。
为求直观，再把上述结果规范化为 1 与计算结果之差（并乘 100，转为百分制），旨在让数值越大代表越优质。见图 0 的说明。
———
「
小三通指数」的主要结果：T1 第一档（>= 75 分）：南昌、武汉、长沙、合肥
T2 第二档（>= 上三分位）：南京、杭州、广州、福州、上海
T3 第三档（>= 中位数）：郑州、贵阳、南宁、济南、西安、石家庄
…
最惨档：
乌鲁木齐、拉萨、哈尔滨、长春
#小三通指数 #百搭 #专线 #统计 #没用的冷知识 #技术漫谈 #技术杂谈
中国移动：
主要看点
1️⃣ 再次印证：出资多少海缆，就能增加多少 Peering。
2️⃣ 「公共互联」暴增的重点区域，与政策层面的 “一带一路”＋“中欧合作” 高度重合。
3️⃣ 和电信所不同的是，中国移动把大部分境外「公共互联」堆料到平价的 CMI。
4️⃣ 商业策略上，#移动 仅割低延迟区域客户的韭菜，但对余下大多数区域的互联十分慷慨。
#统计 #中国移动 #cmi #cmin2 #国际互联 #公共互联 #public #peering #直连 #技术杂谈
CMI 和 CMIN2 的「公共互联」变化趋势主要看点
1️⃣ 再次印证：出资多少海缆，就能增加多少 Peering。
这点从上期的 中国电信 中亦可看出端倪。
对于移动，SJC2 海缆拉通后，2025 年在🇯🇵日本的互联随即暴增；2Africa 分段建设期内，在🇿🇦南非、🇰🇪肯尼亚随即暴增。
但，并非所有运营商都把资源明牌。#联通 就更爱套马甲（把出资海缆获得的 Peering 资源划拨给关联公司 #PCCW 及 #HKT 享用），下次再展开……
✍️ 按：联通是 PCCW 的第二大股东，而 PCCW 全资控股 HKT。
2️⃣ 「公共互联」暴增的重点区域，与政策层面的 “一带一路”＋“中欧合作” 高度重合。
非洲＋拉美＋中美贸易战后的🇪🇺，都属于中资企业出海的重点区位。
在这一点上，中国移动与 中国电信 的战略依然相似。
3️⃣ 和电信所不同的是，中国移动把大部分境外「公共互联」堆料到平价的 CMI。
大部分＝除 东亚＋东南亚 之外的区域
有趣的是，日、新、港台等亚洲内「公共互联」的资源，则主要分配给了高溢价的 CMIN2。难怪亚洲 VPS 售价/成本打下不来？以及 CMI 从 2024 年起在🇭🇰🇸🇬链路上难以承载暴涨的流量而开始疯狂 QoS？
4️⃣ 商业策略上，#移动 仅割低延迟区域客户的韭菜，但对余下大多数区域的互联十分慷慨。
可能的解释是，移动想拿用户基数更大的 CMI 的「公共互联」摊大饼赚吆喝（降低全球 Transit 成本），以便先做大、后做强、加快挤进 Tier-1，同时不耽误把 日、新、港台 等低延迟地区单拎到 CMIN2 割韭菜。
而电信，则是把投资海缆所获的绝大多数 Peering 私藏到 CTG 溢价网，无差异地割 所有客户的韭菜。只有在容量冗余过多的🇪🇺🇿🇦等地，才会匀给平价的 163 进行免费互联。
#统计 #中国移动 #cmi #cmin2 #国际互联 #公共互联 #public #peering #直连 #技术杂谈
哪些省市 使用 哪个入口 无需打鸡血就能跑满千兆单线程？
如果很不凑巧，同时不满足，该怎么办呢？
—————
附件补档一些省市的
#鸡血补丁 #tcp调优 #测速 #千兆单线程 #技术杂谈 #打鸡血
特别地，对于粤港 🇭🇰节点，
━➊ < 25ms RTT
━➋ YouTube 100w
━➌ 单线程千兆跑满 （打鸡血可破）
这三个情况通常 同时满足 或 同时不满足。
如果很不凑巧，同时不满足，该怎么办呢？
若你本地不满足 ➊ 和 ➋，只能靠「搬家」才能破局。
但若退而求次 ，只追求 ➌ 的话，不妨试试 打鸡血（TCP调优）。不需要搬家即可破局。
—————
附件补档一些省市的
sysctl.conf 文件，适用于 Linux/OpenWrt若你在使用 Windows 设备翻墙，就不用在意了。因自带一定剂量的鸡血，你试试 Windows 下面跑 SpeedTest 单线程，哪怕你在 青海 都能跑满。
#鸡血补丁 #tcp调优 #测速 #千兆单线程 #技术杂谈 #打鸡血
中国电信：最近忙于修炼「国际互联」
关键看点 如下：
1️⃣ 北美方向：在 🇺🇸 Public Peering 彻底定格在 30 Gbps。
2️⃣ 亚非拉方向：在 🇧🇷巴西 、🇿🇦南非、🇰🇪肯尼亚 等地 Public Peering 暴增，多元化改善。
3️⃣ 欧洲 + 两亚方向：互联大跃进！
4️⃣ 电信-国际互联 新主轴 初见端倪：
5️⃣ 溢出效应：优化直连 终将卷出新低价
曾经高贵的电信优质线路 将越趋普遍、卷出新低价📉！ 欢迎补充其他看法…
#统计 #中国电信 #国际互联 #公共互联 #public #peering #直连 #技术杂谈
关键看点 如下：
1️⃣ 北美方向：在 🇺🇸 Public Peering 彻底定格在 30 Gbps。
符合 2018 贸易战以来的现实：美资主导的新建海缆 (如 Echo /Apricot) 一律绕开 陆港澳，以此实现物理层面的「去中化」。
从前「跨太平洋」海缆首选登陆 上海＋香港 的时代已成历史。加之 2021 年起 🇺🇸 FCC 陆续撤销中资运营商 214 牌照，电信在美扩容已无可能。
⚠️唯一不确定的是 #私有互联 (Private Peering) 存量几何？但因数据黑箱，全貌不可知。
2️⃣ 亚非拉方向：在 🇧🇷巴西 、🇿🇦南非、🇰🇪肯尼亚 等地 Public Peering 暴增，多元化改善。
复刻 NTT、Telstra、TATA …的玩法，为他国出资修「非中国登陆」海缆，置换互联资源。
3️⃣ 欧洲 + 两亚方向：互联大跃进！
在 欧洲 (荷/德/法/英) + 亚洲 (新/日/阿) 的 Public Peering 自 2023 年暴增！
用投资「亚洲内 方向」的 ALC 海缆及「亚-非-欧 方向」的 PEACE 等海缆，置换新加坡、阿联酋、欧盟及英国的互联。
4️⃣ 电信-国际互联 新主轴 初见端倪：
❶ 南向:
香港/海口/昆明 ⇋ 🇸🇬新加坡
❷ 西南:
昆明 ⟷ 老/泰/新 ⇋ 🇪🇺欧洲
❸ 西向:
喀什 ⟷ 巴基斯坦 ⇋ 🇪🇺欧洲
❹ 北向:
北京 ⟷ 俄罗斯 ⇋ 🇪🇺欧洲
(涉俄，受地缘政治影响)
❺ 东向:
上海/青岛 ⇋ 日/韩 ⇋ 🇺🇸美国
(受 美/日/韩 政策摇摆)
5️⃣ 溢出效应：优化直连 终将卷出新低价
虽说 Public 只是总量的一环 (总量 = Public + Private)，但其惊人的增量充分昭示着 #电信 国际互联总量已今非昔比。
鬼故事：电信的国际公共互联，2024 年已赶超 #移动 同期水平 (≈ 950G)，今年更超 #移动 的两倍！
这也印证了 Sharon, YxVM, ISIF 等主打 HK/SG/JP 等亚洲优化 (163Plus / CN2) 商家，为何时至近两年才频出⁉️
曾经高贵的电信优质线路 将越趋普遍、卷出新低价📉！ 欢迎补充其他看法…
#统计 #中国电信 #国际互联 #公共互联 #public #peering #直连 #技术杂谈
《SS / Trojan 刷网页的实际延迟对比：下篇》
可能有人想问 v2ex.com 不是有挂 Cloudflare CDN？难道CDN不能改善加载耗时吗？
3️⃣ 访问挂载 CDN 的网站，其 #动态文件 的加载延迟依然对「用户侧耗时」拖后腿，属于压死骆驼的最后一根稻草。
4️⃣ 那么，所有的 CDN 都无法扭转东道主优势吗？
5️⃣ 我该用哪的节点？
#漫谈 #技术杂谈 #rtt #延迟 #脚本
可能有人想问 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 #延迟 #脚本
《SS / Trojan 刷网页的实际延迟对比：上篇》
不少一/二线同时提供 SS＋Trojan 协议。众所周知的是，这俩虽然 RTT 相同，但因 Trojan 多一次握手，所以其 HTTP(S) 延迟 > SS协议。那么，优先选 SS 吗？
此时，有必要引入一个相关的问题/争议。不少人认为，HTTP(S) 延迟才最反映刷网页的实际体验。沿着这一逻辑，继而认为，SS 协议的 HTTP(S) 延迟更低，那么在日常使用中就应优先用 SS 节点。
👉 问题来了，节点『HTTP(S) 延迟』真的最能反映 “刷网页的实际耗时” 吗⁉️ 省流：不能，其参考价值还不如 RTT ！
—————
对此，本文专门进行检验，得到了一些有趣的发现：
1️⃣ 相同入口-相同专线-相同落地，同时搭 #SS 和 #Trojan 节点，两者 HTTP 延迟差异较大（≈1次 RTT），但开网页的实际耗时差异→0❗️
2️⃣ 看到这里，似乎 RTT 才是决定「用户侧网页加载耗时」的关键？沿着这个逻辑，RTT 越低，访问网站就越快？
原文有修改。因字数限制，展开一些论述后，必须剁成两篇
#漫谈 #技术杂谈 #rtt #http #https #延迟 #专线 #协议
不少一/二线同时提供 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 #延迟 #专线 #协议
有人会问，在修改菜单栏间距后，如果想要恢复原状，怎么办？有两种方法。
方法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 系列的刘海，可谓是众所周知地恶心！应该不会有多少人能自适应吧？！
目前主流的解法： 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 究竟有无关联？》
自 gfw.report 该报告 (简称《报告》) 和本频道上回推文发布以来，大量争议聚焦在 ”积至公司“ 是否为 GFW 的关联实体 (含技术共享、白手套)，以及墙是否迎来大幅升级。
争议相关的 三方论点 梳理如下
✍️ 读者请自行判断更接受哪种论点？ 欢迎补充其他论点……
#漫谈 #技术杂谈 #GFW #积至公司 #积至 #geedge
自 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
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性能：坑最多！
2️⃣ #光猫/猫棒的性能瓶颈：极易忽视
3️⃣ 多层NAT的隐形影响
4️⃣ #物理距离 制约：本频道的老生常谈
对于本群bot，在 #招募后端 时我们都做过一对一的问题排解。暂未解决的，也都用🟨🟧🟫做过标记（颜色越深，越跑不满）
——
💊经验上，先天跑不满
#技术杂谈 #打鸡血 #测速 #千兆单线程
测速跑不满、货不对板……算是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，在 #招募后端 时我们都做过一对一的问题排解。暂未解决的，也都用🟨🟧🟫做过标记（颜色越深，越跑不满）
——
💊经验上，先天跑不满
千兆单线程的 #地狱省市 暂不存在！只是，有些家户的网络环境、设备有问题。但切勿把这种个例当一般。#技术杂谈 #打鸡血 #测速 #千兆单线程
上回基于香港节点分析得出：当本机到入口RTT超过25ms时，会面临两个问题：❶ YouTube娱乐跑分无法突破100w，同时 ❷ 测速也无法跑满千兆单线程。
今天我们来探讨三个与日本节点相关的问题：
1️⃣ 日本节点在国内能否跑到100w油管跑分？
2️⃣ 日本节点会跑不满单线程千兆吗？
3️⃣ 🇯🇵节点延迟高于🇭🇰，访问网站就一定更慢？
那么，您平时是更喜欢用🇯🇵还是🇭🇰呢？
#技术杂谈 #软路由
今天我们来探讨三个与日本节点相关的问题：
1️⃣ 日本节点在国内能否跑到100w油管跑分？
答案：不能。
如图所示，即便是访日最快的上海，通过👑👑超顶尖入口到🇯🇵的RTT也已达32ms。根据这一延迟水平，🇯🇵油管的跑分只能达到约90w。
除非未来上货 "上海-大阪" 专线，将RTT压到20ms左右。
2️⃣ 日本节点会跑不满单线程千兆吗？
答案：不会。
➤ 跑不满单线程千兆主要取决于本机到入口的RTT，而非节点延迟。虽然入口到🇯🇵的延迟远高于入口到🇭🇰的延迟，但通过简单计算可知：跑满日本节点的千兆单线程比跑满香港节点反而容易得多！
➤ 事实上，对于电信宽带 ➜ 沪电入口，全国超过50%的地区都能跑满日本节点的千兆单线程。相比之下，香港节点仅能在广东及其相邻省市才能达到这一水平❗️
3️⃣ 🇯🇵节点延迟高于🇭🇰，访问网站就一定更慢？
答案：未必！
➤首先，对于大部分省市，日本和香港节点的延迟差距在30ms以内。甚至，在江浙沪皖、山东、京津冀、东北的差距仅2～15ms（如图2）。
➤其次，您可以下载 《网页加载分析(改)》 的 #油猴 脚本亲自验证。
➤最后，一个可能令人意外的发现：
即使在日本-香港延迟差距达30ms的国内某城市，对于大多数同时部署了两地CDN的网站，🇯🇵节点延迟虽看似更高，实际加载速度却往往更快！
那么，您平时是更喜欢用🇯🇵还是🇭🇰呢？
#技术杂谈 #软路由
《RTT和HTTPS，哪种延迟更有参考价值？》
#技术杂谈 #延迟 #RTT #HTTPS #时延 #mihomo
很多人在纠结 Mihomo核心 #统一延迟 是否☑️ 时，常面临两种观点：有人坚持 RTT 延迟测试"自欺欺人"，有人推崇 RTT 作为首选指标。
1️⃣ RTT vs HTTPS延迟的区别
2️⃣ 为什么说RTT在今天更有参考价值？
3️⃣ 实用结论
在2025年还在固守成见——认定RTT是”自欺欺人“。对此，你怎么看？
#技术杂谈 #延迟 #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是”自欺欺人“。对此，你怎么看？
《关于YouTube跑分和入口距离两个看似不相关的问题》
1️⃣ 先谈谈 YouTube 跑分
许多人喜欢用 油管跑分 作为节点优劣的评估工具，看谁能突破「100万、200万、…」。但实际上，这种 #油管娱乐分，和你本地的带宽关联不大！
既然 YouTube 跑分和带宽的关系不大，那还剩下什么意义呢？它可以辅助对比节点表现。例如，你有同样25ms RTT的两个节点，如果其中一个娱乐分100w，另一个90w，那么100w分的节点 #抖动 无疑更低。仅此而已！
2️⃣ 25ms RTT 的另一个“魔咒”
事实上，这个原理恰好又表现成两个看似不相关的症状：
虽然前者能通过
🧩 所以，25ms RTT 既是 #远距离 临界线，也是 #油管娱乐分 的百万分水岭。你看到的“突破”，其实都是这条延迟线在背后捣鬼！
#技术杂谈 #软路由
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 既是 #远距离 临界线，也是 #油管娱乐分 的百万分水岭。你看到的“突破”，其实都是这条延迟线在背后捣鬼！
#技术杂谈 #软路由
以下是综合整理的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、#广港专线 入口的潮流变化
2、那么跨网、跨省问题解决了吗？
3、#深圳联通 入口的跨网/跨省延迟及体验。
4、#深圳电信 入口的跨网/跨省延迟及体验。
5、对于不幸的省份×运营商组合，怎么办？
#技术杂谈
1、#广港专线 入口的潮流变化
采用深联入口的机场，从早期“十三太保"，逐渐扩大阵容，至今或已有数十家。因联通的跨境专线向来质优（较之移动）、价廉（较之电信），备受阿里云、华为云等大厂的跨境服务所青睐。
然而，随着三大运营商打击PCDN，相继祭出跨网、跨省流量结算政策，#广港 方向的节点表现受到较大波及，致使部分省份×运营商的用户体验堪忧。
随即，少部分机场增加广东电信入口（如 穗电、惠电，以及四家 #一线机场 的深电），旨在解决跨网QoS问题。
2、那么跨网、跨省问题解决了吗？
简单剧透：解决了一部分，但未完全解决
⁉️
下面用两家一线机场的 深圳电/联 入口简单演示。
3、#深圳联通 入口的跨网/跨省延迟及体验。
💥剧透
：联通宽带->联通入口全国正常，其他宽带视省份＋运营商有差异。
❶ 电信宽带（图1a）：
❌ 建议回避：福建、江苏、江西、四川、重庆
💔 勉强可用：湖南、陕西，以及除深圳外的广东城市
✅ 基本正常：余下省份＋深圳市内
❷ 联通宽带（图1b）：
✅ 全国都基本正常
❸ 移动宽带（图1c）：
❌ 建议回避：河南、辽宁、吉林、山东、四川、西藏、广西
💔 勉强可用：海南、贵州、福建、江西，江苏、北京、河北，以及广东省内
✅ 基本正常：余下省份
4、#深圳电信 入口的跨网/跨省延迟及体验。
💥剧透
：
① 电信入口哪怕对
电信宽带用户
都未必是解药
② 电信疯起来，自家宽带的跨省流量也丢包⁉️
❶ 电信宽带（图2a）：
✅ 基本正常：仅江西、海南、福建、宁夏、西藏，部分江苏城市
💔 勉强可用：上海、天津，以及除深圳外的广东城市
❌ 建议回避：余下
❷ 联通宽带（图2b）：
✅ 基本正常：仅四川、陕西、甘肃、海南、贵州、广东
💔 勉强可用：西藏、河北、湖北、江苏
❌ 建议回避：余下
❸ 移动宽带（图2c）：
✅ 基本正常：仅北京、吉林、天津、青海、宁夏、西藏
💔 勉强可用：江苏、河北、广西、陕西、黑龙江，广东
❌ 建议回避：余下
5、对于不幸的省份×运营商组合，怎么办？
任选其一：
❶ 树挪死、人挪活——抛弃🇭🇰🇸🇬，拥抱沪日/京德
❷ 加钱上大厂云或自建
❸ 换宽带
#15分钟看懂测试结果 #近期需要关注的入口QoS #FAQ #技术杂谈
1. 测试结果的4个核心构成：
2. 拓扑图中的入口及参考点：
👉三网专线入口天梯表(持续更新)👈
3. 拓扑图中的落地：
4. 测速带宽的参考点：
🔐远距离用户突破千兆单线程限速之法：上篇 & 下篇🔐
5. 延迟结果的类型及参考点：
6. 延迟多少算好？
＋5ms为参考；
🇸🇬：以香港＋40ms为参考；
🇺🇸：以日本＋90ms/150ms作为美西/美东的参考。
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作为美西/美东的参考。
