常见问题：四层 排查、五席位与三条计费口径

§01

连接类：握手上不去、连上不通、频繁掉线

连接问题的排查顺序是「时间 → 方向 → 模式 → 规则」。系统时间偏差会让握手失败且不报错，是最容易被忽略的一项；方向与模式决定是否被运营商阻断；规则决定是否走错出口。

为什么时间偏差会导致握手失败

隧道建立依赖证书有效期与时间戳校验，偏差超过 5 分钟时服务端会直接拒绝，而客户端只看到「正在握手」。这是设计上的取舍：不暴露具体的拒绝原因，避免被用于探测。

掉线的三种频率对应三种原因

每分钟一次多为本地网络抖动；每小时一次多为隧道密钥轮换失败；每天一次多为运营商侧的线路维护。按频率判断比看日志更快，日志里三者看起来都像「连接中断」。

§02

速度与测速：为什么和宣传数字不一样

宣传数字是测量值，测量值绑定条件。读者的宽带、接入方式、目标站点与时段只要有一项不同，结果就会不同，这不是虚标，而是没有说明条件的宣传才叫虚标。

带宽与延迟不是同一件事

带宽决定一次能搬多少数据，延迟决定每一次往返要多久。视频会议在意延迟与抖动，大文件下载在意带宽。把两者混为一谈，会让优化方向完全跑偏。

FAQ 为什么不放「一键诊断」按钮

诊断需要采集本机信息，与「不上传连接详情」的边界冲突。我们把诊断做成可由用户主动执行的命令，报告在本地生成、本地查看，是否发送由用户决定。

为什么表格不给结论

同一个现象可以对应多种原因，给出单一结论反而会误导。表格列的是「现象与归因」，读者需要自己完成最后一步判断，这一步无法代劳。

四个数字决定一次网页加载

DNS 解析、TCP 握手、TLS 握手与首字节时间，四项相加才是页面开始渲染前的等待。加速影响的是后三项，DNS 在本地完成。理解这个拆分，就不会把「页面慢」全部归给线路。

为什么单线程下载跑不满

单条 TCP 连接受拥塞窗口与往返时间共同限制。在 150 毫秒往返的链路上，单连接的理论上限约为 8 至 12 MB/s，多线程才能用满带宽。这是协议特性，不是线路问题。

§03

账号与多端：五个席位怎么算

同时在线按设备计，不按系统计。桌面端与移动端共享五个席位，超出后最早登录的设备被挤出。同一账号的订阅、收藏与规则在登录后自动同步。

为什么不是无限席位

席位限制的是并发，不是设备注册。十个席位意味着十条隧道同时在跑，背后的带宽与通道配额是真实成本。把限制写清楚，比事后发现被限速要好。

收藏与规则是否跟着账号走

节点收藏、手动锁定与自定义分流规则都存在账号侧，换设备登录后同步。本地日志与连接详情不跟账号走，换设备后从零开始记录，这是隐私边界的一部分。

换设备需要注销吗

不需要。在新设备登录后，旧设备会在下一次心跳时收到挤出通知并断开，用户可在新设备的「设备管理」里看到当前在线列表。

§04

计费与退款：口径写在前面

计费按订阅周期与通道配额结算，不按流量。退款按未使用天数比例计算，扣除已产生的通道成本。这两条口径写在购买页与本节，避免事后理解偏差。

为什么不按流量计费

流量计费会让用户在看视频时反复计算，体验成本高于收益。按周期计费的前提是配额与席位可控，这也是席位限制存在的经济原因。

发票与合同

需要合同的用户在下单时勾选，合同金额与订阅周期一致，不含任何浮动条款。发票按实际支付金额开具，退款后对应发票需作废重开，这条流程通常在 3 个工作日内完成。

退款为什么要扣成本

通道配额是按周期向运营商采购的，退款当天起这部分成本已经发生。扣成本不是惩罚，而是把已发生的支出结清，剩下的按未使用天数退。

§05

安全与隐私：哪些记录有，哪些没有

这一节只描述事实，不做承诺式表述。有记录的、没记录的、保留多久，逐条列出，读者可据此判断是否符合自己的要求。

• 有记录：握手结果（时间、成功与否、出口节点名），保留 90 天，用于可用性统计。
• 有记录：连接详情的域名与规则编号，仅本地保留 500 条，不上传。
• 无记录：访问的完整 URL、页面内容、请求体与响应体。
• 无记录：DNS 查询内容，解析在本地完成，不经过我们的解析器。
• 保留期：原始握手记录 90 天，聚合结果长期保留且不含账号标识。
• 导出：用户可随时导出本地连接详情，导出内容不含 URL。

不记录与不收集的区别

不收集是指从未拿到，不记录是指拿到后不落盘。本站的 DNS 属于不收集，握手结果属于记录但不含内容。把两者分开说，是为了避免用「不记录」掩盖「其实收集了」。

为什么不做流量统计面板

流量统计需要持续采集每个会话的字节数并上传，这与「不上传连接详情」的边界冲突。我们选择不提供这个功能，而不是先提供再解释数据用途。

公共 Wi-Fi 场景的额外风险

在公共网络下，隧道的价值主要是把本地网络的窥探挡在外面。但账号密码仍建议使用二次验证，隧道不替代应用层安全。

§06

客户端故障：五个动作解决八成问题

故障处理顺序按「代价从低到高」排列：先重启客户端，再切模式，再换节点，再重装，最后才导出日志提工单。前两步能解决多数问题。

1. 退出客户端并确认后台进程已结束，重新启动。
2. 在设置里切换协议模式（自动 / TCP / UDP），保存后重连。
3. 换一个同方向的节点，观察是否只有单节点异常。
4. 检查系统时间、磁盘空间与防火墙规则，必要时临时关闭后重试。
5. 以上无效时导出日志（含规则编号与出口，不含 URL）并提交工单。

为什么先重启而不是先看日志

重启的代价是 15 秒，看日志的代价是 10 分钟。多数故障是状态残留，重启即可清除。把代价低的动作排在前面，是排障流程设计的基本原则。

§07

术语表：六个容易被混用的词

同一个词在不同语境里含义不同，混用会让讨论失焦。下表给出本站使用的定义，与行业通用口径一致。

往返延迟

客户端到落地出口的往返时间，非服务器间 ping

抖动

P95 减 P50，衡量尾部体验

回程

落地机房返回用户方向的路由

分流

按进程、域名或端口决定出口

粘性

同一站点在窗口期内保持同一出口

配额

入口带宽上限，超额限速而非扣费

为什么要把术语写在 FAQ 里

读者提出问题时的用词往往与定义不一致，例如把「抖动」叫「忽快忽慢」。在解答前先对齐定义，能避免答非所问，也让后续的技术页面有共同的参照。

§08

未收录的问题如何自查

FAQ 覆盖不了所有情况，但自查路径是有限的。下面四条能把多数问题定位到「本机」「线路」「目标站点」三者之一。

1. 换一个设备或换一条宽带测试，若问题消失则属于本机环境。
2. 换一个方向测试，若只有某一方向异常则属于线路侧。
3. 访问同一方向的另一个站点，若只有单站点异常则属于目标站点。
4. 在晚高峰与平峰各测一次，若只在晚高峰异常则属于排队而非故障。

自查记录该怎么写

记录四项即可：时间、方向、现象、已排除的变量。四条齐全的反馈，通常一次就能定位；只写「连不上」的反馈，平均需要三轮往返。

自查的时间成本

完整走完四条自查约需 12 分钟，其中换设备与换方向各占 3 分钟。相比提交工单后的平均 6 小时答复周期，自查仍是最快的路径，这也是我们把它写进 FAQ 的原因。

什么情况应该直接提工单

大面积无法连接、同一账号多设备同时异常、或者公告页已有同类条目但你的现象更严重。其余情况建议先自查，多数能在十分钟内解决。

§09

口径声明

本页所有答复都基于当前版本的行为，版本变化后答复会同步更新。涉及数字的答复标注了测量条件，未标注的视为定性描述。

• 版本：本页基于客户端 v3.7.2 与 2026-11 的规则库。
• 数字：涉及延迟的答复均为往返时间中位，条件见延迟测试页。
• 不承诺：不承诺任何站点的可用性，也不承诺特定延迟数值。
• 更新：答复随版本与公告更新，最后更新日期见页脚。

• 延迟实测记录数字的来源与口径
• 分流策略规则编号的含义
• 客户端下载版本与校验值
• 线路公告当前是否有已知问题

连接排查测速口径多端席位退款口径隐私边界

§10

数据快照与来源：可单独引用的六条记录

本节把页面内散落的数字集中成六条记录，每条都带测量条件与来源，可脱离上下文单独引用。按主题查阅请回到上文对应章节。