由TG散户群体自发形成的测速社区。专注*用户测*的体验：单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
《参数汇总：代理工具的协议支持 & Apps与通用核心的隶属》
如两张图所示
网页版地址 (持续/优先更新) :
🆕 Latest Version: 2025.10.30
https://www.haitunt.org/cheatsheet.html
⚠️ 这不是一份测评，而是纯粹的协议参数速查表
#app #协议 #代理工具 #代理核心 #代理协议 #mihomo #singbox #xray #v2ray #v2fly #dae #大鹅 #surge #小火箭 #loon #stash #qx #surfboard #vless #reality #encryption #hy2 #anytls #windows #win #macos #linux #openwrt #路由器 #华硕 #小米 #软路由 #插件 #内网穿透 #参数 #速查表 #cheatsheet
如两张图所示
VLESS 家族过于庞杂，仅节选机场节点常用的特性/分支。
待有统计数据后，会再补充一些信息……
To be announced……
网页版地址 (持续/优先更新) :
🆕 Latest Version: 2025.10.30
https://www.haitunt.org/cheatsheet.html
⚠️ 这不是一份
#app #协议 #代理工具 #代理核心 #代理协议 #mihomo #singbox #xray #v2ray #v2fly #dae #大鹅 #surge #小火箭 #loon #stash #qx #surfboard #vless #reality #encryption #hy2 #anytls #windows #win #macos #linux #openwrt #路由器 #华硕 #小米 #软路由 #插件 #内网穿透 #参数 #速查表 #cheatsheet
新代理App：
使用 此处配置文件 的注意事项：
1. 务必使用 ref1nd 分支，否则报错。替换二进制核心的路径为
2. 建议先看《带注释》版本，确定哪些需要，哪些不需要，然后再自行调整
3. （对于懒人）只需基于
#momo #singbox #app #代理软件 #软路由 #代理插件 #openwrt
momo使用 此处配置文件 的注意事项：
1. 务必使用 ref1nd 分支，否则报错。替换二进制核心的路径为
/usr/bin/sing-box，如图所示2. 建议先看《带注释》版本，确定哪些需要，哪些不需要，然后再自行调整
3. （对于懒人）只需基于
template-momo-reducedform.json 修改第12行、第26行的两处 Clash/Mihomo格式的 机场订阅🔗，即可运行。该配置文件借鉴 七尺宇：同时添加redir＋tproxy＋tun入站，以便随时在 momo LuCI 切换模式。
➊ template-momo.json
➋ template-momo-带注释.json
➌ template-momo-reducedform.json
➊和 ➋的唯一区别是 ”有无注释“。
➌是剔除 《"💵 北美站" 本地规则集示例》后的简化版 —— 避免有人没删干净而报错。
#momo #singbox #app #代理软件 #软路由 #代理插件 #openwrt
新代理App：
由 知名nikki插件作者 新写的、基于
✅ TCP:
✅ UDP:
1️⃣ 使用步骤
2️⃣ momo的使用条件，同时满足：
3️⃣ 插件特色：
欢迎讨论、交流经验…
#momo #singbox #app #代理软件 #软路由 #代理插件
momo由 知名nikki插件作者 新写的、基于
sing-box 核心的一款 openwrt 代理插件。支持模式：✅ TCP:
Redir / TProxy / Tun✅ UDP:
TProxy / Tun示例环境：arm64 ＋ OpenWrt 24.10 (cooluc固件)
1️⃣ 使用步骤
➊ 参照 作者 GitHub 说明书 进行安装
➋ 进入momo的 luci 界面，选择”配置文件“标签页，上传.json配置文件。
➌ 返回”插件配置“标签页，选择已上传的配置文件，勾选"启动"，保存并应用。
——其他都不动，完毕！
2️⃣ momo的使用条件，同时满足：
✅ OpenWrt >= 24.10
✅ Linux Kernel >= 5.13
✅ fw4 (nftables) 防火墙
3️⃣ 插件特色：
➊ #OpenWrt 平台的代理插件。
➋ 部署简单、便捷。仅需上传.json配置文件，即可成功启动。
默认模式为 Redir (TCP)＋Tun (UDP) 模式
➌ 依托强大的 OpenWrt/Linux ，代理性能无需担心。
在 350元档的 RK3576 软路由下，本地娱乐回环＞35Gbps
❹ 支持手动替换核心，如 sing-box ref1nd 分支 。
随附 .json配置文件（real-ip）
欢迎讨论、交流经验…
#momo #singbox #app #代理软件 #软路由 #代理插件
最强代理方案：sing-box 遇上 Linux
1️⃣ 确保以下条件，同时满足：
2️⃣ 随附2个
3️⃣ 性能表现：
4️⃣ 运行方案：
➡️ 法㈠：
➊ 创建
➋ 从 ref1nd 频道 下载 1.12.x 版核心，并放入
➌ 启动仅需1行：
➡️ 法㈡：Procd 自启（更建议，但略）
欢迎讨论、交流经验…
#singbox #app #代理软件 #软路由
此文示例：裸核运行 real-ip，配置文件随附
1️⃣ 确保以下条件，同时满足：
✅ OpenWrt / Linux
✅ ref1nd 分支的sing-box 1.12.x
✅ fw4 (nftables) 防火墙 —— 因要开启auto_redirect
⚠️但若 软路由 防火墙为 ipt，则要改 inbounds.auto_redirect 为 false
——或，inbounds 调整为 Tproxy 或其他
2️⃣ 随附2个
.json配置文件➊ refind-v3b-带注释.json
➋ refind-v3b.json
两者的唯一区别是 ”有无注释“
3️⃣ 性能表现：
一句归纳：Sing-box 1.12 (Linux) 的效率，近乎 Surge Mac 6.0 (macOS) 的十倍❗️
⚔️对比：
➊ RK3582➕sing-box 1.12
操作系统：Openwrt / iStoreOS 24.10
iperf3🔺吞吐量: 39Gbps
～Surge Mac的 1.3倍❗️
iperf3🔻吞吐量: 36Gbps
～Surge Mac的 1.6倍❗️
☢️ 以上表现是在仅需～Mac mini M4的 15% CPU性能 下达到的!
➋ M4➕Surge Mac 6.0
操作系统：Surge官方未列明
iperf3🔺吞吐量: 31Gbps
iperf3🔻吞吐量: 23Gbps
🛸由此，singbox效率可见一斑，相对 #Surge 等app简直是《外星科技》！
4️⃣ 运行方案：
➡️ 法㈠：
➊ 创建
/etc/sing-box/ 文件夹，并在此套娃创建 ruleset 文件夹➋ 从 ref1nd 频道 下载 1.12.x 版核心，并放入
/etc/sing-box/ 文件夹，建议重命名为 sing-box，然后 chmod +x /etc/sing-box/sing-box 赋执行权限➌ 启动仅需1行：
/etc/sing-box/sing-box -c /etc/sing-box/refind-v3c.json run➡️ 法㈡：Procd 自启（更建议，但略）
欢迎讨论、交流经验…
#singbox #app #代理软件 #软路由
猜猜这是哪个代理app的网页体验？
1️⃣
2️⃣
3️⃣
4️⃣
5️⃣ 经过核心的 TCP 性能：
➤
➤
➤ 均为单线程打流
🎯 答案公布：
⚙️ 部署环境 #软路由：
🔲 CPU型号：Rockchip
～ 2017H2 的 iPhone X 手机 A11 性能
～ 2018H2—2019H1 的 安卓 骁龙855 、麒麟980 性能
#singbox #代理软件 #软路由 #app
1️⃣
谷歌：🇭🇰香港 （RTT～40ms）2️⃣
Spotify：🇭🇰香港 （RTT ～40ms）3️⃣
百度：河北保定 （RTT～40ms）4️⃣
新浪：省内 （RTT～5ms）5️⃣ 经过核心的 TCP 性能：
➤
iperf3 Lan：～2.5Gbps拉满➤
iperf3 WiFi：～1.7Gbps 🍏网卡辣鸡没办法➤ 均为单线程打流
测试环境
➤ 节点天梯：👑 顶尖＋的🇭🇰
➤ 操作系统：🍏 macOS 26 Tahoe (dev beta)
➤ 浏览器：Edge 隐私模式
➤ 宽带： 联通 —— 猜猜是哪？🤔
➤ 代理App：猜猜是哪个？🤔
🎯 答案公布：
⚙️ 部署环境 #软路由：
✅ OpenWrt/Linux (aarch64) // iStoreOS 24.10 ✅ nftables➕auto_redirect ✅ real-ip🔲 CPU型号：Rockchip
RK3582 ～ 2017H2 的 iPhone X 手机 A11 性能
～ 2018H2—2019H1 的 安卓 骁龙855 、麒麟980 性能
这里推荐 reFind 分支的 sing-box 核心，其优势：
➤ 支持 订阅provider
➤ 与官方核心相同的优势：性能极其强悍、体感遥遥领先其他代理工具
➤ ……
Github: https://github.com/reF1nd/sing-box/tree/reF1nd-dev
TG频道: https://t.me/sing_box_reF1nd
Singbox交流群: https://t.me/sing_box_community
#singbox #代理软件 #软路由 #app
《千兆单线程跑不满的常见原因》
测速跑不满、货不对板……算是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的网站，🇯🇵节点延迟虽看似更高，实际加载速度却往往更快！
那么，您平时是更喜欢用🇯🇵还是🇭🇰呢？
#技术杂谈 #软路由
《关于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 既是 #远距离 临界线，也是 #油管娱乐分 的百万分水岭。你看到的“突破”，其实都是这条延迟线在背后捣鬼！
#技术杂谈 #软路由
#技术杂谈
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）可以提高网络吞吐量，特别是在高延迟或高带宽的网络环境中。较大的接收缓冲区允许更多的数据在传输过程中被缓存，从而减少了数据包丢失和重传的可能性。
