变更记录 · 2026-10 至 2026-11
线路公告：9 条变更、四类标签与一次中断复盘
10 月至 11 月共记录 9 条变更：4 条节点、2 条容量、2 条规则、1 条版本，另有一次 47 分钟的光缆中断；每条都标注影响范围与可观测指标，缺一项即退回重写。
公告参数 / changelog spec
- 条目数
- 9
- 分类
- 4 类
- 灰度比例
- 10% 起
- 预告期
- 72 小时
- RSS 条目
- 8 条
- 归档起点
- 2025-01
- 不做删改
- 追加补充
§01
2026 年 11 月：三条变更与一次灰度
11 月的变更集中在上游调整与客户端修复。每条公告保留「日期、类型、变更内容、影响范围、可观测指标」五要素，缺任何一项都会被退回重写。
| 日期 | 类型 | 变更 | 影响范围 | 可观测指标 |
|---|---|---|---|---|
| 2026-11-08 | 节点 | 东京 03 接入 NTT 直连 | 日本方向，灰度 10% | 东京中位 46 毫秒，无上升 |
| 2026-11-06 | 规则 | 域名表新增 36 条流媒体分组 | 全量用户 | 锁定次数无异常 |
| 2026-11-04 | 版本 | 客户端 v3.7.2 发布 | 全量用户 | 休眠唤醒后重连失败率降至 0.2% |
| 2026-11-01 | 容量 | 香港配额余量降至 29% | 香港方向 | 峰值负载 88%，触发限流 12 分钟 |
9条变更
10 月至 11 月合计，四类标签分别计数，不含故障与维护。
72小时预告
节点与容量变更的最短预告期，规则变更不预告。
47分钟中断
10 月 2 日广州通道光缆中断的实际时长。
11 月已知问题：Android 12 及以下系统在切换 Wi-Fi 与蜂窝时偶发隧道重建延迟 3 至 5 秒，已定位为系统网络回调的时序问题，修复排期在 v3.7.3。该问题不导致断连，只延长切换期间的不可用窗口。
§02
2026 年 10 月：六条变更与一次中断
10 月最值得记录的是广州通道的光缆中断。它检验了冷备迁移流程，也暴露了长连接迁移的短板，复盘结论已写进变更流程。
| 日期 | 类型 | 变更 | 影响范围 | 结果 |
|---|---|---|---|---|
| 2026-10-29 | 节点 | 洛杉矶 03 换上游为 Cogent | 美国西岸 | 北京移动方向下降 21 毫秒 |
| 2026-10-26 | 容量 | 上海通道配额 32 → 40 Gbps | 上海接入口 | 峰值余量回到 22% |
| 2026-10-22 | 维护 | 新加坡 01 BGP 调整 | 新加坡方向 | 90 分钟窗口，回程切 CMI |
| 2026-10-15 | 规则 | 域名表扩容至 1.8 万条 | 全量用户 | 上线 6 分钟后回滚 |
| 2026-10-08 | 节点 | 香港 05 备用裸纤上线 | 香港方向 | 主备切换 45 秒降至 8 秒 |
| 2026-10-02 | 故障 | 广州通道光缆中断 | 华南出口 | 47 分钟，92% 会话 8 分钟内迁走 |
| 变更 | 原定放量 | 实际放量 | 原因 |
|---|---|---|---|
| 洛杉矶 03 换上游 | 100% | 30% | 抖动上升，暂停放量 |
| 香港 05 裸纤上线 | 100% | 100% | 指标全部达标 |
| 上海配额上调 | 100% | 100% | 容量类变更无灰度必要 |
| 域名表扩容 | 100% | 回滚 | 通用域名误归类 |
光缆中断的复盘结论
中断本身不可控，可控的是迁移速度。复盘发现长连接（首字节时间敏感）迁移失败率 8%，原因是客户端在迁移时优先保证短连接可用。v3.7.2 起改为「按会话类型排队迁移」，长连接获得更高优先级。
一次回滚的三小时
10 月 15 日的规则回滚从触发到全量恢复用了不到 20 分钟，但事后核查用了三小时：需要逐条比对 412 条新增规则与用户锁定记录。这段核查时间此后被定义为「回滚后的必要成本」，写进流程。
§03
版本历史：近六个版本的变更
版本记录只写「改了什么、影响谁、怎么验证」三件事，不写营销语。每个版本都附回滚方式，因为更新本身也是一次变更。
| 版本 | 发布日期 | 主要变更 | 回滚方式 |
|---|---|---|---|
| v3.7.2 | 2026-11-04 | 修复休眠唤醒后隧道未重建 | 保留 v3.7.1 还原点 |
| v3.7.1 | 2026-09-18 | 新增 QUIC 通道与游戏优先队列 | 保留 v3.7.0 还原点 |
| v3.7.0 | 2026-08-06 | 规则引擎重写，匹配耗时降至 0.1 毫秒 | 保留 v3.6.9 还原点 |
| v3.6.9 | 2026-07-02 | 分应用代理支持通配进程名 | 保留 v3.6.8 还原点 |
| v3.6.8 | 2026-06-11 | 连接详情新增规则编号 | 保留 v3.6.7 还原点 |
| v3.6.7 | 2026-05-08 | 内网白名单扩展至十个网段 | 保留 v3.6.6 还原点 |
| 月份 | 发布版本 | 间隔 | 备注 |
|---|---|---|---|
| 5 月 | v3.6.7 | — | 白名单扩展 |
| 6 月 | v3.6.8 | 34 天 | 规则编号可见 |
| 7 月 | v3.6.9 | 21 天 | 通配进程名 |
| 8 月 | v3.7.0 | 35 天 | 规则引擎重写 |
| 9 月 | v3.7.1 | 43 天 | QUIC 通道 |
| 11 月 | v3.7.2 | 47 天 | 休眠唤醒修复 |
为什么版本号跳过了几个数字
内部构建号与对外版本号不同步，对外只发布经过灰度验证的版本。跳号不是遗漏，而是把未通过灰度的构建留在内部。对外版本号的规则是「主版本按架构变化，次版本按功能，修订号按修复」。
旧版本的支持边界
v3.6 及更早版本在 2026 年 12 月 31 日后停止规则库下发，届时分流效果会逐步退化。升级窗口为两个月，公告会提前 30 天置顶提示。
§04
维护窗口规则：什么时候会动线路
维护窗口只安排在两个时段：本地时间 02:00 至 05:00，或与国内晚高峰完全错开的周末上午。任何落在 20:00 至 23:00 的变更都需要额外审批。
- 提交变更单，写明变更内容、影响方向、预计时长与回滚方案。
- 由值班工程师评估是否落在禁止窗口，落在禁止窗口的变更需二次审批。
- 提前 72 小时在公告页与 RSS 发布维护通知，含开始与结束时间。
- 变更期间每 5 分钟记录一次握手成功率，低于 95% 立即回滚。
- 变更结束后 24 小时内发布结果公告，含实际影响与偏差说明。
为什么维护多安排在凌晨
凌晨的跨境流量只有晚高峰的 12% 至 18%，同样一次 90 分钟的中断，凌晨影响的会话数约为晚高峰的六分之一。把维护放在低峰不是偏好，而是把影响面压到最小。
| 时段 | 是否允许 | 说明 | 例外 |
|---|---|---|---|
| 20:00 至 23:00 工作日 | 禁止 | 晚高峰，影响面最大 | 需二次审批 |
| 00:00 至 02:00 | 谨慎 | 仍有少量夜间流量 | 需说明理由 |
| 02:00 至 05:00 | 允许 | 低峰，默认窗口 | 无 |
| 法定节假日首日 | 禁止 | 流量结构异常 | 需二次审批 |
紧急变更的口子怎么开
只有两种情况可以跳过 72 小时预告：一是安全事件，二是正在发生的故障。两者都要求事后 24 小时内补充公告，并说明为何未能预告。
§05
灰度与回滚：10% 是怎么定的
新建节点与规则变更都先灰度 10% 用户，观察 24 小时后再全量。10% 这个比例来自经验：它足以在一天内暴露多数问题，又不至于让大面积用户承担风险。
| 阶段 | 比例 | 最短观察 | 放量条件 |
|---|---|---|---|
| 灰度一 | 10% | 24 小时 | 握手成功率不低于 99%，无集中投诉 |
| 灰度二 | 30% | 24 小时 | 延迟中位与基线偏差小于 5 毫秒 |
| 灰度三 | 60% | 12 小时 | 无回滚事件 |
| 全量 | 100% | — | 进入常规监控 |
2026 年 10 月的灰度实例：洛杉矶 03 换上游在灰度一阶段发现北京移动方向的抖动上升到 38 毫秒（基线 29 毫秒），延迟虽下降但抖动变差，因此暂停放量并调整队列参数，两天后恢复灰度。若只看中位延迟，这次变更是「成功」的。
§06
订阅方式：RSS 与公告页同步
公告只有两个出口：本页与 rss.xml。两者内容一致，RSS 便于聚合工具订阅，本页便于人工翻阅。不通过邮件列表推送，避免把公告变成营销渠道。
# 订阅地址
https://kuaimiavpn.com.cn/rss.xml
# 用 curl 查看最近三条
curl -s https://kuaimiavpn.com.cn/rss.xml | grep -E "|<pubDate>" | head -6</div><dl class="kv-kv"><div><dt>RSS 地址</dt><dd>/rss.xml，含最近 8 条</dd></div><div><dt>更新频率</dt><dd>有变更即更新，通常每周 1 至 3 次</dd></div><div><dt>公告语言</dt><dd>中文，日期为北京时间</dd></div><div><dt>历史归档</dt><dd>保留全部条目，不删改</dd></div></dl><h3>为什么不发邮件</h3><p>邮件列表一旦建立，就难免被用于促销；公告的可信度依赖「只发变更」这条纪律。RSS 没有群发压力，读者按需订阅，退订也没有成本。</p><h3>订阅量与实际阅读量</h3><p>RSS 订阅者约 1.2 千人，公告页日均访问 300 余次，其中约四成来自搜索引擎的日期检索。这说明公告不只是给现有用户看的，也是外部评估线路稳定性的公开证据。</p><h3>公告的机器可读性</h3><p>每条公告的标题以日期开头，正文首句包含影响方向与可观测指标。这样的结构既便于人读，也便于抓取工具按日期与方向切分。</p></section><section class="kv-sec" id="taxonomy"><p class="kv-no">§07</p><h2>变更分类：四类与优先级</h2><p>公告的类型只有四类：节点、容量、规则、版本。故障与维护单独标注，因为它们的时间语义不同：前四类是计划内，后两类包含计划外。</p><table class="kv-tbl"><caption>变更分类定义 · 与公告标签一致</caption><thead><tr><th>类型</th><th>含义</th><th>典型影响</th><th>是否预告</th></tr></thead><tbody><tr><td class="n">节点</td><td>机房上线、下线或更换上游</td><td>单向延迟与冗余度</td><td>提前 72 小时</td></tr><tr><td class="n">容量</td><td>配额调整、队列参数变更</td><td>峰值时段的可用带宽</td><td>提前 72 小时</td></tr><tr><td class="n">规则</td><td>分流规则库的增删改</td><td>特定站点的出口</td><td>不预告，随更新下发</td></tr><tr><td class="n">版本</td><td>客户端发布</td><td>功能与修复</td><td>发布当天</td></tr><tr><td class="n">维护</td><td>计划内停机</td><td>该方向的可用性</td><td>提前 72 小时</td></tr><tr><td class="n">故障</td><td>计划外中断</td><td>该方向的可用性</td><td>发生后 24 小时内补公告</td></tr></tbody></table><h3>为什么规则变更不预告</h3><p>规则库每 12 小时下发一次，预告会让「什么时候生效」变得模糊。规则变更的补偿手段是回滚与手动覆盖，而不是提前通知。</p><h3>公告与延迟记录的交叉核对</h3><p>读到一条节点变更公告后，可在延迟测试页对应方向的逐周记录里找同一周的数字，两者应当一致。若公告说下降 21 毫秒而逐周记录看不出变化，说明公告的指标写错了，这是我们最不希望出现的错误类型。</p><h3>公告为什么不写感谢</h3><p>感谢与致歉在公告里只占位置，不提供信息。真要表达歉意，就把「下次如何避免」写清楚，这比一句抱歉更有用。这一条是 10 月复盘中临时增加的写作规则。</p><h3>公告页为什么保留已经解决的问题</h3><p>删掉「已修复」的条目会让站点看起来更干净，但也会让读者无法判断某个问题是否曾经发生。保留它，等于承认线路有历史，这比一份永远干净的记录更可信。</p><h3>公告与灰度的关系</h3><p>每条节点变更公告都会写明灰度比例与阶段，读者看到「灰度 10%」就知道自己未必受影响。这个字段曾经被省略过，结果引发了「公告说改了但我没感觉」的困惑，此后成为必填项。</p><h3>公告的检索方式</h3><p>公告标题以日期开头，站内检索与搜索引擎都按日期切分；页内锚点也使用日期，因此可以直接链接到某一天的记录。这样的结构让「上次维护是什么时候」这类问题一秒可答。</p><h3>公告页为什么不做评论</h3><p>评论区会把变更记录变成投票现场，而线路决策需要的是指标而不是声音。反馈走工单，公告只承载事实。这一条从建站起就写在编辑规范里。</p><h3>公告写作的三条硬规则</h3><p>一是日期开头，二是首句给出影响方向，三是必须有一个可核对的数字。三条都来自读者的实际检索方式：他们先在搜索里找日期，再确认方向，最后核对数字。</p><h3>公告与工单的关系</h3><p>每条公告都关联一张内部工单，工单里有完整的变更单、审批记录与回滚日志。公告只对外暴露结论，工单对内保留过程。这种分离让公告保持简洁，同时保留可追溯性。</p><h3>分类标签的稳定性</h3><p>六类标签自 2025 年建站起未变，新增类型需要同时修改公告模板、RSS 结构与检索逻辑。稳定性比分类的完备性更重要，因为搜索引擎与读者都依赖这套标签做筛选。</p><h3>分类为什么重要</h3><p>分类决定了读者该关注哪一项：关心稳定性的人只需看维护与故障，关心速度的人看节点与容量，关心某个站点能否访问的人看规则。把类型标在标题前，是为了让筛选成本降到一眼。</p><figure class="kv-fig" style="aspect-ratio:1200/675"><img src="assets/kv-orbit.png" alt="变更分类的轨道示意图，四条椭圆轨道分别对应四类变更" width="1200" height="675" loading="lazy" decoding="async"><figcaption>图 4：四类变更的轨道。内圈为高频的规则变更，外圈为低频的容量变更。</figcaption></figure></section><section class="kv-sec" id="reading"><p class="kv-no">§08</p><h2>如何读一条公告</h2><p>一条合格的公告应该让读者在 15 秒内判断出「这次变更是否影响我」。下面的六条要素就是为此设计的，缺任何一条，公告都会被退回。</p><ul class="kv-ul"><li><b>日期：</b>北京时间，精确到日，标题以此开头。</li><li><b>类型：</b>节点、容量、规则、版本、维护、故障六选一。</li><li><b>变更：</b>一句话说明做了什么，不写动机与过程。</li><li><b>影响范围：</b>哪个方向、哪类用户、是否灰度。</li><li><b>可观测指标：</b>变更后应当看到什么数字变化。</li><li><b>回滚：</b>若结果不符预期，如何退回上一状态。</li></ul><table class="kv-tbl"><caption>一条公告的六要素示例</caption><thead><tr><th>要素</th><th>内容示例</th></tr></thead><tbody><tr><td class="n">日期</td><td>2026-10-29</td></tr><tr><td class="n">类型</td><td>节点</td></tr><tr><td class="n">变更</td><td>洛杉矶 03 更换上游为 Cogent</td></tr><tr><td class="n">影响范围</td><td>美国西岸方向，全量</td></tr><tr><td class="n">可观测指标</td><td>北京移动方向中位下降 21 毫秒</td></tr><tr><td class="n">回滚</td><td>回切 GTT，保留 24 小时观察期</td></tr></tbody></table><h3>一个反例</h3><p>「优化了部分线路，体验更佳」这样一句话包含零个可验证事实：不知道哪个方向、什么时候、变化多少、怎么验证。这类公告在本站不允许出现，即使它读起来更「友好」。</p><h3>为什么写可观测指标最难</h3><p>写指标要求作者事先想清楚「怎么算成功」。多数变更在提交时并没有明确定义成功标准，因此指标一栏经常被退回补充。这条纪律反过来提高了变更本身的质量。</p><figure class="kv-fig" style="aspect-ratio:1200/675"><img src="assets/kv-mesh.png" alt="公告要素之间关系的网状示意图，二十二个节点以细线相连" width="1200" height="675" loading="lazy" decoding="async"><figcaption>图 5：六要素之间的关系。变更与影响范围关联，指标与回滚互为验证。</figcaption></figure></section><section class="kv-sec" id="archive"><p class="kv-no">§09</p><h2>历史归档与反馈</h2><p>公告不做删改，只做追加。已发布的条目即使事后发现措辞有误，也以「补充说明」的形式追加，而不是回改原文。这样任何一次引用都能追溯到当时的信息。</p><ul class="kv-ul"><li><b>归档范围：</b>自 2025 年 1 月起的全部条目，含故障与维护记录。</li><li><b>不做删改：</b>措辞更正以追加形式呈现，原文保留。</li><li><b>可引用：</b>每条公告可单独引用，URL 锚点为日期。</li><li><b>反馈渠道：</b>公告页底部提供问题反馈入口，48 小时内答复。</li></ul><p>一份可追溯的变更记录，本身就是线路质量的一部分证据：它让「这个方向最近稳不稳」这个问题有了可查的答案，而不是只能凭印象判断。</p><ul class="kv-lnk"><li><a href="latency-test.html">延迟实测记录</a><span>变更后的数字对照</span></li><li><a href="gia-line.html">CN2 GIA 线路</a><span>通道与配额说明</span></li><li><a href="download.html">客户端下载</a><span>版本更新的安装方式</span></li><li><a href="about.html">信息来源与边界</a><span>公告口径的完整说明</span></li></ul><p class="kv-tags"><span class="kv-tag">变更记录</span><span class="kv-tag kv-tag-a">维护窗口</span><span class="kv-tag">灰度放量</span><span class="kv-tag kv-tag-a">版本历史</span><span class="kv-tag">RSS 订阅</span></p></section><section class="kv-sec" id="facts"><p class="kv-no">§10</p><h2>数据快照与来源：可单独引用的六条记录</h2><p>本节把页面内散落的数字集中成六条记录，每条都带测量条件与来源，可脱离上下文单独引用。按主题查阅请回到上文对应章节。</p><div class="kv-facts"><p>10 月至 11 月共记录 9 条变更，其中节点 4 条、容量 2 条、规则 2 条、版本 1 条，统计口径为公告页全量条目。</p><p>10 月 2 日广州通道光缆中断 47 分钟，92% 会话在 8 分钟内迁至上海通道，数据来自调度系统事件流。</p><p>灰度比例从 10% 起、观察 24 小时，握手成功率不低于 99% 才放量，测试条件见同月的节点变更实例。</p><p>上海通道配额从 32 Gbps 上调至 40 Gbps、工单周期 26 天，依据是连续 5 个工作日峰值超过 85%。</p><p>客户端版本平均发布间隔 36 天，2026 年共 6 个版本，版本记录含 3 项必填字段。</p><p>公告页日均访问 300 余次、RSS 订阅约 1200 人，统计窗口为 2026 年 10 月，采样不含爬虫。</p></div></section></main><aside class="kv-aside" aria-label="本页目录"><div class="kv-toc"><p>本页目录 / toc</p><ol><li><a href="#nov">2026 年 11 月</a></li><li><a href="#oct">2026 年 10 月</a></li><li><a href="#versions">版本历史</a></li><li><a href="#window">维护窗口</a></li><li><a href="#canary">灰度与回滚</a></li><li><a href="#subscribe">订阅方式</a></li><li><a href="#taxonomy">变更分类</a></li><li><a href="#reading">如何读公告</a></li><li><a href="#archive">归档与反馈</a></li></ol></div><div class="kv-mini">当前测量窗口 <b>2026-11-10 19:00 +08:00</b><br>线路公告每周一更新。<br>数据来源与口径见<a href="about.html#source">信息来源</a>。</div><div class="kv-mini">入口：<a href="download.html">Windows 客户端</a><br>测速：<a href="latency-test.html#method">测量方法</a></div></aside></div>
<footer class="kv-foot"><div class="kv-foot-in"><div><h4>快喵VPN · 工程台</h4><p>这里记录节点清单、CN2 GIA 回程走向、延迟实测与路由策略。所有数字来自自有探针与公开测试工具，测量条件写在对应页面内。</p><p class="kv-sm">站点为技术资料与客户端分发入口，不含在线支付与账号托管。</p></div><div><h4>线路</h4><ul><li><a href="nodes.html">全球节点清单</a></li><li><a href="gia-line.html">CN2 GIA 专线</a></li><li><a href="latency-test.html">延迟实测记录</a></li><li><a href="routing-policy.html">分流与回程策略</a></li></ul></div><div><h4>使用</h4><ul><li><a href="download.html">Windows 客户端下载</a></li><li><a href="download.html#mac">macOS 与移动端</a></li><li><a href="updates.html">版本与线路公告</a></li><li><a href="faq.html">常见问题</a></li></ul></div><div><h4>关于</h4><ul><li><a href="about.html">站点说明与信息来源</a></li><li><a href="about.html#legal">备案与合规</a></li><li><a href="rss.xml">RSS 订阅</a></li><li><a href="sitemap.xml">站点地图</a></li></ul></div></div><div class="kv-legal"><span>© 2026 快喵VPN 工程台 · kuaimiavpn.com.cn</span><span><a href="https://beian.miit.gov.cn/" rel="nofollow noopener" target="_blank">京ICP备20269273号-4</a> · 本站备案号为占位编号，用于结构演示</span></div></footer>
<script>(function(){var e=document.getElementById("kvClock");function p(){var d=new Date(Date.now()+8*3600e3);e.textContent=d.toISOString().slice(11,19)+" +08:00";}p();setInterval(p,1000);})();</script>
</body>
</html>