公布绿茶VPN 最近 30 天（2026 年 9 月 12 日至 10 月 11 日）的可用性台账：全部节点线路的月度在线率 99.97%，累计中断 47 分钟，共发生三次影响连接的中断，最长单次中断 6 分钟。按分钟折算，用户平均每月遇到不可用的时间约为 0.8 分钟。
这份台账来自 12 个外部探测点，分别部署在香港、东京、新加坡、洛杉矶、法兰克福与悉尼，每 30 秒对全部节点的入口地址发起一次 TCP 探测，任一点连续两次失败即记为一次中断，恢复后累加时长。统计口径在月初固定，不因事后复盘而调整。
监控口径与统计方法
探测只判断入口是否可达，不评价速度，因此在线率 99.97% 只能说明「连得上」，不代表「连得好」。为了避免探测点自身故障导致误报，任一探测点报出中断时，系统会要求至少两个地理上不同的探测点同时失败才判定为真实中断，并把判定过程写入事故记录。
在线率按节点加权计算：单个节点的中断时长先除以当月总分钟数，再按该节点的用户占比加权求和。这样做的结果是，用户集中的香港与东京节点权重更高，边缘节点短暂中断不会显著拉低整体数字。团队同时公布未加权的算术平均值 99.94%，供不同口径的对照。
三十天台账与三次中断复盘
第一次中断发生在 9 月 19 日 21:14，持续 6 分钟，原因是香港一处机房的供电切换，12 个节点同时失联，用户被调度到其余节点，实际受影响连接约 4300 条。第二次在 9 月 28 日 03:02，持续 4 分钟，法兰克福回程的一条上联被运营商维护，影响 2 个节点。第三次在 10 月 6 日 10:37，持续 3 分钟，调度服务发布配置时的灰度批次出错，回滚后恢复。
其余 34 分钟为单节点级别的短时抖动，单次均不超过 90 秒，用户多数感知为重连一次。按设备类型拆分，桌面端受影响比例 0.41%，移动端 0.63%，移动端偏高主要来自网络切换导致的探测失败被计入。三次中断合计影响用户会话 1.2 万条，占当月总会话数的 0.09%。
补偿规则与下一步动作
按公开的服务承诺，月度在线率高于 99.9% 时不触发时长补偿，因此本次不发放补偿。若后续出现月度在线率低于 99.9% 的情况，系统会在次月自动为付费账号叠加对应时长的补偿，用户无需申请，补偿明细可在账号中心查看。
针对三次中断，团队已排了三件事：第一，为香港机房增加一路独立供电的备用接入，预计 11 月完成；第二，法兰克福回程改为双运营商并行，避免单条上联维护时整片失效；第三，调度配置改为分批发布并加入自动回滚，灰度批次出错时 60 秒内恢复到上一版本。
「在线率是结果，不是目标。我们更关心的是中断发生后用户多久能恢复，这次三次中断的平均恢复时间是 4.3 分钟，比上季度的 9.1 分钟缩短了一半。」谭亦舟 · 运维值班负责人
下个月起，这份台账会固定在每月 12 日更新，口径与本次一致，并补充各节点的独立可用性明细。用户可在资讯中心订阅更新，客户端也会在重大中断后推送说明。
想自己验证线路表现，可在客户端连接后查看实时延迟与丢包，或对同一节点连续测速 30 次取中位数。客户端 5.0.4 已修复测速结果偶尔显示 0 的问题。
相关阅读
用户评论
9 月 19 日那次我正好在开会，掉线大概五分钟后自动换到别的节点，会议没断太久，希望供电这块尽快补上。
敢把中断次数和时长都写出来，还给出未加权的平均值，这个态度比只报一个好看的数字强。
凌晨三点那次我根本没感觉，早上看公告才知道。桌面端受影响比例比移动端低，估计是移动网络切换造成的误判。
每月固定更新台账挺好的，建议把各节点的独立可用性也做成表，方便挑稳定节点。
补偿自动叠加这个规则清楚，不用像别家一样填表申请，希望保持。