快喵VPN
01怎么读这份记录：三种标签
记录按时间倒序排列，每条都带日期与影响范围，便于把现象与变更对上。
三种标签分别是版本、策略与口径，前两种会改变实测数字，第三种只是改变统计方式。
把口径变更与前两种分开看，可以避免把统计方式的变化误读成性能变化。
记录的作用不是展示工作量和迭代节奏，而是为现象提供一个可回溯的时间轴。当你发现断流集中出现，第一件该做的事是把第一次出现的时间与本页的日期对一遍。如果两者接近，那么原因多半就在那条记录里；如果相差很远，就应当回到权限与网络两处去找。
版本类记录
客户端版本变化属于这一类，通常会带来可观测的行为差异。
- 版本记录会写清改动的方向与量级。
- 量级以实测中位的变化来表示。
- 版本变化之后需要重做一次基线。
- 记录里会标注受影响的页面。
策略类记录
心跳间隔与后台策略的调整属于这一类，影响面比版本变化更宽。
- 策略调整会同时影响驻留与耗电两组数字。
- 两类数字的变化方向往往相反。
- 记录里会同时写明收益与代价。
- 调整之后区间会在下一轮采样中更新。
口径类记录
统计方式的调整属于这一类，它改变的是数字的算法而不是实际表现。
- 口径调整不影响你的实际体验。
- 但会让区间与前一期不可直接比较。
- 记录里会写明旧口径停用的日期。
- 看到区间整体跳变时，先确认是否属于这一类。
022026 年 11 月：四次调整
十一月共有四条记录，其中两条会直接改变你的实测数字，另外两条属于采样与口径。
月初的版本发布是本期影响最大的一次变更，它把重连逻辑从等待超时改成即时重建。
月底的复测没有发现回程变化，因此切网页的区间维持原值。
十一月这两条改变数字的记录，影响的方向其实不同：版本发布让重连更快，口径调整让统计更细。前者所有人都能感受到，后者只有做过记录的人才会注意到差别。如果你的体感没有变化，那很正常，因为口径调整改变的是数字的解释方式，而不是链路行为本身。
2026-11-11 后台驻留采样本轮收尾
四台安卓机与三台 iPhone 的第四轮采样完成，区间数值同步到两页。
- 安卓区间维持在 9 到 14 小时。
- iOS 区间维持在 5 到 9 小时。
- 本轮没有发现与上一轮方向相反的偏差。
- 采样条件与上一轮一致，可直接比较。
2026-11-05 客户端 5.8 发布
重连逻辑改为通知到达即重建，不再等待业务超时，首包可用中位缩短约一秒。
- 首包可用中位从 3 到 6 秒降到 2 到 5 秒。
- 长尾样本的比例同时下降。
- 改动只涉及重建时机，不涉及加密流程。
- 升级后首日建议复查一次权限。
2026-11-02 切网耗时口径调整
把射频注册与隧道重建分开记录，对照表改为四段式，旧表格停用。
- 四段分别是发现变化、射频注册、隧道重建与首包重发。
- 旧口径把四段合并成一个数字，无法定位瓶颈。
- 新口径下总数与旧口径接近，但解释力更强。
- 本期之后的切网数字均按四段式记录。
版本更新之后，建议把权限与首日基线重新走一遍
看快喵下载与权限清单032026 年 10 月：一次策略调整，三次复测
十月有一条策略调整与三次复测，策略调整是本期唯一改变区间数值的变更。
心跳间隔从 30 秒调整到 45 秒，后台耗电整体下移，重连耗时上限增加约一秒。
三次复测分别覆盖回程、iOS 信任流程与双卡切换，结论都已写入对应页面。
十月这次策略调整是本期唯一一次收益与代价同时出现的变更，值得单独说明它的取舍逻辑。拉长心跳间隔能直接减少唤醒次数，属于线性的收益；而被服务端释放之后的完整握手带来的体感损失，是非线性的代价。两者相交的位置，就是当前采用的这个值。
2026-10-30 东京与新加坡回程复测
两条回程各复测两轮，延迟与丢包未出现显著变化，采样条件保持不变。
- 两条回程的延迟差异仍在原区间内。
- 丢包率没有观察到方向性变化。
- 因此切网页的区间维持原值。
- 下一轮复测计划放在十二月。
2026-10-22 心跳间隔默认值调整
后台心跳默认间隔由 30 秒调整为 45 秒，后台耗电区间整体下移。
- 后台挂着的耗电从一小时 2 到 4 个点降到 1.5 到 3 个点。
- 重连耗时上限增加约一秒。
- 被服务端释放的概率略有上升。
- 这属于策略类变更，收益与代价同时存在。
2026-10-15 iOS 描述文件信任流程更新
信任入口的位置说明按当前正式版修订，补上过期后重新安装的两步。
- 入口仍在通用设置的底部。
- 系统版本不同时措辞略有差异。
- 过期后需要重新安装并信任一次。
- 这两步已写入安装页与 iOS 页。
042026 年 9 月：口径与流程的整理
九月的三条记录都不改变实测数值，属于口径与流程的整理工作。
这类整理的价值在于让后续的数字可比较，短期看不出效果，长期影响明显。
如果你只关心数字变化，这一节可以跳过，直接看十一月的记录。
2026-09-26 安卓白名单路径修订
三个品牌的电池优化与应用管理入口按系统版本重新整理。
- 补入了用搜索框定位设置页这一条通用做法。
- 三个品牌的入口名称差异已逐条列出。
- 修订后安卓页的对照表按品牌分行。
- 路径类信息建议以系统实际措辞为准。
2026-09-18 流量统计与系统计数对照
两套计数在四轮采样中的差异均在两成以内，流量区间维持不变。
- 差异主要来自统计层次不同。
- 重传与心跳的计入方式也不一样。
- 两成以内视为有效样本。
- 超出两成的样本已剔除。
2026-09-09 首日基线流程上线
把首日需要记录的两组数字固定为流程，安装页与耗电页共用同一份口径。
- 两组数字是每小时流量与一夜待机掉电。
- 记录表只需要四列。
- 两页引用同一份定义，避免口径漂移。
- 后续所有对照都以这份基线为起点。
现象出现的时间点，往往能对上这里的一条记录
看掉线排查顺序052026 年 8 月：建站与最初的三个方向
八月是本站的起点，三条记录确定了最初的方向：后台驻留、切网重连与功耗口径。
首版的采样样本较少，区间范围比现在窄，后续随着样本增加逐步放宽。
把这段历史保留下来，是为了说明当前的区间并不是一次定下来的。
首版只有三台机器的样本，区间范围窄得有些失真，这也是后来把样本扩到七台的原因。样本增加之后，区间变宽是正常的，它反映的是真实的分布，而不是结果变差。理解这一点，你就不会把区间的每一次放宽都当成负面的信号。
2026-08-29 弱网阈值样本补充
地库与电梯两类场景各补 15 次，弱网下的成功率与耗电倍数写入切网页。
- 弱网下重连成功率降到四成以下。
- 单位时间耗电是常态的三倍以上。
- 两类场景的差异已分开记录。
- 这类补充采样的结论写在同一节里。
2026-08-20 省电模式对照实验
同机型开启与关闭各两轮，记录驻留与重连两组数据。
- 开启后驻留下降两到三小时。
- 重连耗时从 2 到 5 秒升到 6 到 12 秒。
- 两组数据分别写入安卓页与耗电页。
- 结论是取舍而非优劣。
2026-08-11 移动端专页建立
本站以手机端为主题建立，首版只覆盖后台驻留与切网重连两个方向。
- 首版的样本为两台安卓机与一台 iPhone。
- 首版区间比现在窄，因为样本少。
- 后续随着样本增加逐步放宽。
- 这段历史解释了区间的演变过程。
06后台策略变更：三次调整的累积效果
后台策略的三次调整方向一致：拉长心跳间隔以换取续航，同时接受重连变慢的代价。
累积效果是后台耗电下降约三成，重连耗时上限增加约两秒。
这个方向在采样中被反复验证，属于有意为之的取舍，不是性能退化。
判断一次策略调整是否划算，标准并不复杂：把省下的电量折算成可使用时长，再把多等的秒数折算成体感损失，两者相减为正就采用。这个折算当然粗糙，但它至少让决策有据可依，而不是在两次争论之间来回摇摆。任何一次后续调整都沿用同一套折算方法。
第一次：心跳从 20 秒到 30 秒
这次调整把后台耗电从一小时零点五度电级降到现在的量级。
- 调整发生在八月之前，作为基线写入首版。
- 后台流量随之下降。
- 重连耗时基本未变。
- 这是一次纯收益的调整。
第二次：从 30 秒到 45 秒
这次调整发生在十月，收益与代价第一次同时出现。
- 后台耗电下降约两成。
- 重连耗时上限增加约一秒。
- 被服务端释放的概率略有上升。
- 权衡之后仍然采用。
为什么不继续拉长
间隔超过 60 秒之后，被服务端释放的概率上升过快，收益不再划算。
- 释放之后的完整握手会带来三秒级耗时。
- 体感损失超过续航收益。
- 因此当前的 45 秒是权衡后的位置。
- 后续若有更稳的保持方式，这个值会再调整。
07切网重连：两次改进都在时机上
切网重连的两次改进都不涉及加密流程，只改重建的时机与触发条件。
第一次把触发从业务超时改为网络回调，第二次把触发细化到通知到达即开始。
两次改进叠加之后，首包可用中位从早期的 6 秒级降到现在的 2 到 5 秒。
这两次改进之所以有效，是因为它们都作用在同一段耗时上：从网络变化被发现到重建开始之间的那段等待。这段等待在早期占了总耗时的一半以上，却完全由客户端的实现方式决定。把等待省掉之后，剩下的时间基本都花在射频与握手这些无法加速的环节上。
第一次：改为网络回调触发
在此之前，重连要等业务请求失败才发现出口不可用。
- 等待超时的代价通常是五秒以上。
- 改为回调触发后，等待时间被省掉。
- 这一改动对体感的改善最大。
- 改动不涉及加密与鉴权。
第二次：通知到达即重建
5.8 版把触发点进一步前移到网络变化通知，不再等下一个心跳周期。
- 首包可用中位再缩短约一秒。
- 长尾样本比例同时下降。
- 改动只涉及时机，不涉及流程。
- 升级后无需改任何设置即可生效。
还剩下的两段
射频注册与系统广播两段不在客户端控制范围内，改进空间已经很小。
- 这两段合计仍占一半以上的耗时。
- 因此中位耗时的下限大约在两秒。
- 继续优化的方向是减少需要重建的次数。
- 固定节点是目前最有效的做法。
08功耗口径：三次调整让数字可比
功耗口径调整过三次，每次都不改变实际表现，只改变数字的算法。
三次调整分别涉及档位划分、是否接电源的标注与统计差异的剔除规则。
回溯之后，早期的数字已按新口径重算，避免出现前后不可比较的空洞。
第一次：三档划分
把使用强度分为前台、后台与待机三档，此前只有一档。
- 一档数字无法解释用户之间的巨大差异。
- 三档划分之后，区间收窄到可解释的范围。
- 这一调整改变了所有历史数字。
- 历史数据按新口径重算后重新发布。
第二次：标注是否接电源
接电源会关闭深度休眠，此前没有在记录里标注，导致部分样本不可比。
- 标注之后，接电源样本被单独归类。
- 待机区间只统计电池状态。
- 这一条现在写进了每一页的采样条件。
- 历史样本按标注能力重新筛选。
第三次：剔除统计差异
系统计数与客户端计数差异超过两成的样本被剔除，不再参与中位计算。
- 这一规则让区间略有收窄。
- 剔除比例在四轮中约为百分之五。
- 规则已写入耗电页的口径一节。
- 后续采样沿用同一规则。
09已知问题：三项尚未解决
已知问题共三项，都不影响正常使用，但会在特定场景下表现出来。
三项分别是定制系统的广播延迟、双卡场景的恢复比例与部分应用的绕过行为。
记录下来是为了让你遇到时不必怀疑是自身设置的问题。
三项已知问题里，前两项属于平台限制，第三项属于应用行为，三种性质不同。平台限制只能等系统或版本更新，应用行为则与你使用的具体软件有关。把这三类分开写在同一个清单里，是为了让你在遇到问题时能更快判断该找谁，而不是一律怀疑自己的设置。
定制系统的广播延迟
部分定制系统会延后网络变化广播，最长见过三秒，导致重连滞后。
- 这一项无法从客户端侧解决。
- 表现是切网后停留更久的等待。
- 飞行模式重置可以缓解单次情况。
- 长期方案取决于系统版本更新。
双卡场景的恢复比例
双卡场景的自动恢复比例低于单卡，实测在七成到八成之间。
- 失败多发生在两张卡信号都弱的区域。
- 手动点一次连接通常就能恢复。
- 固定数据卡可以改善一部分。
- 这一项仍在观察中。
部分应用的绕过行为
少数应用使用私有协议或直连地址，可能绕过隧道，导致出口归属不符。
- 表现是个别应用显示本地出口。
- 原因在该应用的连接方式，不在线路侧。
- 核对方式是打开出口查询页看归属。
- 这一类问题需要在应用侧处理。
10订阅与查看：三种方式
查看记录有三种方式：本页直接读、订阅 RSS 只收变更、或看 sitemap 的更新时间。
三种方式的数据源相同，区别只在于你希望被提醒的频率。
本页的更新与客户端版本发布同步，通常在同一天内完成。
三种查看方式的差别只在于提醒频率，数据本身没有差别。偶尔查看的人直接读本页就够了；需要被动提醒的人订 RSS 更合适；做技术核对的人看 sitemap 的更新时间最直接。无论用哪一种，日期都是北京时间，与采样条件里写的时段口径一致。
直接读本页
本页按时间倒序排列，最新的记录在最上面，适合偶尔查看。
- 每条的标题里都带日期。
- 影响范围写在正文的第一句。
- 与此前不可比较的变更会单独标注。
- 页面底部的邮箱可以反馈偏差。
订阅 RSS
RSS 只推送本期十三条记录中的最近十条，适合只收变更的读者。
- 订阅地址在页脚的 RSS 链接里。
- 条目里带日期与一句话说明。
- 更新频率与版本发布同步。
- 不需要注册也不需要邮箱。
查看 sitemap
sitemap 的更新时间可以反映整站的构建节奏，适合做技术核对。
- sitemap 在页脚有链接。
- 每条 url 都带 lastmod。
- 构建时间与版本发布时间一致。
- RSS 与 sitemap 由同一次构建生成。
11口径漂移：三个容易被忽略的细节
在整理这十三次记录的过程中，最容易出错的不是测量本身，而是几次不起眼的口径漂移。
漂移的共同特征是不会报错，也不会让数字变得难看，只是让前后两期悄悄失去可比性。
把三个容易忽略的细节写出来，是为了让后来做记录的人不必重复踩一遍。
三个细节都属于程序层面的疏忽，与方法本身无关，改起来也非常便宜。电量起点与是否接电源只需要在记录表里多两列，统计层次只需要一条剔除规则。真正难的是坚持把这些列填完，因为记录最枯燥的部分恰恰决定了它日后能不能用得上。
细节一：电量起点不一致
同一台机器从满电起测与从八成电起测，得到的驻留时长可以相差一小时以上，这一条在早期采样里反复出现。
- 系统在低电量时的收紧策略会让驻留提前结束。
- 起点不一致的两次记录不能放在同一张表里。
- 统一取满电之后，这一项漂移基本消失。
- 现在每一页的采样条件里都写明了电量起点。
细节二：是否接电源
接电源会关闭深度休眠，待机数字会明显变好，早期没有标注这一项，导致部分样本被高估。
- 接电源的样本现在被单独归类，不计入待机区间。
- 这一条对安卓与 iOS 都适用。
- 记录表里增加一列，成本很低。
- 漏标一次，前后的比较就要作废。
细节三：统计层次不同
系统流量页与客户端计数统计的层次不同，重传与心跳的计入方式也不一样，两成以内的差异属正常范围。
- 差异超过两成时才需要排查是否被绕过。
- 这一规则让早期若干样本被剔除。
- 剔除之后区间略有收窄。
- 规则已写进耗电页的口径一节。
12实测速查：记录里的九个数字
本节的数字对应记录中的关键节点，每条都能在时间轴上找到出处。
把记录里的数字按时间排开，你会发现区间的变化方向并不总是一致，有时变宽有时收窄，原因各不相同。样本增加会让区间变宽，口径收紧会让区间收窄，而策略调整则可能同时改变中位与上限。三种原因对应的解读完全不同，因此每条记录都单独标注了它属于哪一类，而不是混在一起统计。
对读者来说，记录最有用的部分往往不是数字本身，而是改动与现象之间的时间对应关系。当你发现某类断流集中出现在某个版本之后，第一件该做的事就是回看那一次调整动了什么。这也是每一条都写明影响范围的原因，它让你不必读完整篇，就能判断这条是否与自己遇到的情况相关。
另外，记录里的数字都是当期采样的中位，不代表任何一次单独测量的结果，引用时请连条件一起写清。
单次测量受当天信号与内存状态影响很大，同一台机器在同一位置的两次读数差出一小时并不罕见。
因此把单次读数当成结论，往往会在下一次复测时被推翻，反而增加对区间的不信任。
正确的用法是把单次读数放进区间里定位，看它落在中段还是边缘，边缘才值得进一步排查。
这条用法在四个专页里都成立，也是整站数字能够互相比较的前提。
版本与策略
这一组的三个数字分别对应一次版本发布与一次策略调整，日期见第二节。
- 当前客户端版本 5.8，2026-11-05 发布，首包可用中位缩短约 1 秒。
- 后台心跳默认间隔由 30 秒调整为 45 秒，后台耗电下降约两成。
- 调整后重连耗时上限增加约 1 秒，属于有意为之的取舍。
- 间隔超过 60 秒后被释放概率上升过快，因此停在当前值。
区间变化
区间变化的方向与幅度都来自四轮采样，单轮数据不作结论。
- 安卓驻留区间维持 9 到 14 小时，本轮未出现方向相反的偏差。
- iOS 驻留区间维持 5 到 9 小时，与上一轮的中位差不到 1 小时。
- 重连中位从 3 到 6 秒降到 2 到 5 秒，改动只涉及触发时机。
- 后台挂着耗电从 2 到 4 个点降到 1.5 到 3 个点，口径未变。
样本与口径
这一组说明记录的可靠性边界，样本量与剔除规则都写在这里。
- 采样覆盖 7 台机器四轮，单轮间隔不少于 24 小时，条件一致。
- 统计差异超过两成的样本被剔除，剔除比例约为百分之五。
- 首版只有 3 台机器，区间因此比现在窄，样本增加后自然放宽。
- 口径调整共 3 次，历史数字已按新口径回溯重算，见第八节。
T记录分类与影响范围对照表
| 分类 | 含义 | 是否改变实测数字 | 受影响的页面 | 本期条数 |
|---|---|---|---|---|
| 版本 | 客户端版本发布与功能调整 | 会 | 全站 | 1 条 |
| 策略 | 心跳间隔与后台行为调整 | 会，且方向相反 | 安卓、iOS、耗电 | 1 条 |
| 线路 | 回程节点与链路复测 | 通常不会 | 切网重连 | 2 条 |
| 口径 | 统计方式与档位划分调整 | 不改变实际表现 | 耗电、切网 | 3 条 |
| 采样 | 补充样本与复测 | 会微调区间 | 安卓、iOS、切网 | 4 条 |
| 流程 | 记录与排查流程的固定 | 不会 | 安装、耗电 | 2 条 |
D记录术语：十个词
本节术语用于本页与各专页，措辞与厂商文档可能不同，含义以本节为准。
- 版本类记录
- 客户端版本发布带来的行为变化，通常会带来可观测的实测差异。
- 策略类记录
- 心跳间隔与后台行为的调整，会同时改变驻留与耗电两组数字。
- 口径类记录
- 统计方式与档位划分的调整，改变数字的算法而不改变实际表现。
- 影响范围
- 一条记录所涉及的页面与区间，写在每条记录的第一句里。
- 回溯重算
- 按新口径重新计算历史数字的动作，用于避免前后不可比较。
- 中位变化量
- 调整前后实测中位的差值，用来描述变更的量级而不是方向。
- 长尾比例
- 耗时分布中靠近九十分位那部分样本的占比，改进后应当下降。
- 已知问题
- 已记录但尚未解决的现象，写出来是为了避免被误判为设置错误。
- 构建时间
- 整站产物的生成时间，与版本发布同步，可在 sitemap 里核对。
- 订阅源
- 只包含最近十条记录的 RSS 地址，适合只收变更的读者。
只关心区间变化，可以订 RSS 收这几条
看手机端总览