这个栏目只写有具体结论的东西：改了哪个参数、为什么改、代价是什么。写不了结论的选题我们就不发，所以更新不快——三篇，都还在有效期内。
探测越频繁，发现拥塞就越快——这个直觉没错，但它只在探测本身不产生代价时成立。早期版本我们设成 5 秒一轮，128 个节点，每台客户端每秒往外发二十多个探针包。单机看不出问题，十万台在线时，探针本身就成了一股值得注意的跨境流量，而且它集中在整点附近同步发出，等于自己给自己制造微拥塞。
更麻烦的是误判。跨境链路的抖动是秒级的，5 秒采样会把一次正常的抖动读成"链路劣化"，然后切走；切过去发现差不多，又切回来。用户看到的现象是延迟数字疯狂跳，实际体验比不切还差——我们管这叫选路抖动，它比选错路更伤。
最后改了三处。一是间隔放到 30 秒，并把各客户端的起始相位打散，避免同步爆发。二是改成三次探测取中位数，单次异常直接丢掉。三是加迟滞：新路径要连续三次优于当前 15% 以上才切，否则不动。改完之后切换次数降了七成，用户的延迟方差反而收窄了。
代价也要说清：链路真的断了，最坏情况要 30 秒才发现。所以我们另开了一条轻量 TCP 保活走当前链路，1 秒级判断"还在不在"，30 秒那套只负责"哪条更好"。两件事分开，比用一个频率硬扛两件事要干净。
多路径的收益上限不由带宽决定，由两条路丢包的相关性决定。如果两条线同时丢同一批包，发两遍等于白花一倍流量。地铁里有效，是因为蜂窝网络在切换基站时丢包是突发且局部的，两条路走不同基站，丢包基本不相关，这时候冗余立刻兑现成流畅。
家里的情况是另一回事：一条固定宽带出口，两条路在运营商侧很快就并到同一根管子上，丢包高度相关。你在家开着多路径，除了多耗 6% 流量和一点电量，感知不到差别。这就是为什么我们没把它默认全开，而是按网络类型自动决定——检测到蜂窝或公共 Wi-Fi 才启用双路。
想自己验证很简单。客户端诊断页有丢包相关性这一项，跑一分钟会给出一个 0 到 1 的数。低于 0.3 说明两条路基本独立，多路径能拿到接近翻倍的稳定性收益；高于 0.7 就关掉，省电。这个数我们原本不想暴露给用户，后来发现不解释清楚，大家要么全开要么全关，都吃亏。
前向纠错也是同样的逻辑。FEC 比例跟着实时丢包率走，丢包低于 1% 时几乎不加冗余，涨到 5% 以上才开始补。固定比例的方案在低丢包时白耗带宽、高丢包时又补不够，自适应这一层写起来麻烦，但省下来的流量是实打实的。
先说防住的。节点从内存加载系统，不挂硬盘，所以没有"日志写在盘上忘了删"这类事故——这类事故在行业里出现过不止一次。会话元数据存在内存的环形缓冲区里，新数据覆盖旧的，90 秒一轮；机器断电或者重启，内容直接消失，没有恢复路径。
再说没防住的，这部分通常没人写。第一，运行时内存里确实有数据，能物理接触到机器的攻击者理论上可以读走当前这一轮的会话信息。我们靠机房准入和内存加密来压这个风险，但它是"难以做到"，不是"不可能"。第二，计费需要知道你用了多少字节，所以我们有账号维度的聚合流量计数。它不含目标地址，也无法和会话元数据对上——两者之间没有可关联的键值，这是刻意设计的，不是顺便。
第三，也是最容易被忽略的：客户端在你自己设备上。DNS 查询、连接目标这些，在你本机是可观测的，任何能读你进程的人都能看到。隧道保护的是链路上不被第三方看到，不保护你的终端本身。想解决这一层得靠系统级隔离，不是加速器能给的。
所以我们不说"绝对隐私"这种话。准确的说法是：我们把能留存的东西在架构上删掉了，剩下的风险边界上面三条都列出来了。你要判断的是这个边界够不够用，而不是信不信一句承诺。
三个方向，都从用户的真实报障里长出来。
为什么这一刻选了新加坡而不是香港，客户端该不该把评分明细摊给用户看。摊开会被人拿去做套利，不摊开又像黑箱——我们倾向摊开，正在做脱敏方案。
不同运营商的跨境拥塞时段差异很大，很多人换加速器其实该换的是接入时段。我们在攒三个月的分时数据，够样本了就发，附原始曲线。
被问得最多的问题。结论其实取决于你要"访问得更快"还是要"跑一个服务"，这篇会把成本、维护量和风险都摊开算，包括我们自己不划算的那些情况。
想看某个具体问题的拆解，可以走 FAQ 页的客服入口提，报障量够大的选题会优先写。