上手步骤
- 下载并安装按系统选择对应版本。
- 登录账号首次启动拉取节点列表与规则。
- 确认接入点客户端会自动选择最近的边缘接入点。
- 按目标选出口按要访问的服务所在区域选择出口。
边缘节点：把入口放到用户身边
跨境延迟的大头往往不在最后一公里，而在跨国骨干段。但如果入口离用户很远，第一跳就吃掉了本该省下的时间。
快连在全球范围内部署边缘节点，用户请求先就近路由到最近的边缘节点，再由边缘节点接入优化后的骨干路径。这样做的直接效果是减少数据传输距离和时间。
安装后四步确认路径调度生效
安装完成只是开始。四步确认路径选择与切换能力都在正常工作。
- 重启系统：让网络层组件完全加载。
- 跑一次判定测量：对固定目标测十次，记录基线。
- 观察候选路径数量：客户端应给出多个候选而非单一出口。
- 做一次切换演练：限制本机带宽观察是否更换路径，确认不中断。
平台安装要点
| 平台 | 关键步骤 | 验证方式 |
|---|---|---|
| Windows | 管理员权限安装并重启 | 测量基线与切换演练 |
| macOS | 允许网络扩展 | 测量基线与切换演练 |
| Android / iOS | 授予网络权限并加入省电白名单 | 切网后确认会话重建 |
| 路由器插件 | 确认固件满足要求 | 断线后观察多线路切换 |
为什么需要多个候选路径？
单一出口在劣化时无法规避，多候选是故障切换的前提。
移动端能做路径演练吗？
可以做简化版：在蜂窝与 Wi-Fi 之间切换，观察会话是否重建。
安装后提示重启必须执行吗？
必须。否则网络层组件可能只加载一部分，表现为部分流量未被处理。
常见问题
节点越多越好吗？
不是。关键是入口离用户近、出口离目标近，并且路径之间可分辨。一百个质量雷同的节点不如三十个特征互补的节点。
为什么要按目标区域选出口？
因为客户端列表里的延迟是到节点的延迟，不是端到端延迟。访问日本服务应该选亚太出口。
高峰期为什么会变慢？
运营商互联拥塞。调度系统会重排候选集并切换出口，但物理层面的拥塞无法完全规避。
边缘节点会不会看到我的数据？
加密隧道的端点在我们的出口节点，边缘节点只做接入转发。数据在传输过程中始终是密文。
支持几台设备？
同账号多设备在线，各自独立选择接入与出口。
试用覆盖全部功能吗？
覆盖。
实现细节与参数取值
边缘节点解决的是「第一跳」问题。如果入口离用户很远，第一跳就消耗掉了本可以在骨干段省下的时间。我们在全球部署边缘节点，用户请求先就近接入，再由边缘节点进入优化后的骨干路径。
软件定义广域网把「算路」和「转发」拆开：控制面根据实时测量计算路径，数据面按算好的路径转发，测量面持续探测并反馈。三者构成闭环，任何一层的调整都不需要改动其他两层。
| 平面 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 控制面 | 路径计算 | 质量指标 + 节点负载 | 选定路径 |
| 数据面 | 按路径转发 | 控制面决策 | 实际数据流 |
| 测量面 | 探测与反馈 | 主动探测 + 被动统计 | 质量指标 |
性能数据与测量方法
路径选择是持续进行的动态过程，而不是查一张静态路由表。系统融合多种网络资源，动态根据网络状况调整数据传输路径，确保在网络拥堵时仍能维持可用体验。
以上数据的测量方式统一为：同一台设备、同一时段、同一目标服务，开关对应功能各测三轮并取稳定段均值。我们公开测量方法的原因很简单——没有方法的数字无法验证，也无法复现。
边界条件与已知限制
| 限制 | 原因 | 影响 | 缓解方式 |
|---|---|---|---|
| 共享瓶颈 | 两条路径同一上游 | 多路径收益接近于零 | 更换出口区域 |
| 水位过高 | 容量不足 | 高峰期丢包上升 | 触发扩容 |
| 回程未优化 | 只测量去程 | 实时业务体感差 | 双向分别测量 |
节点列表里的延迟数字是客户端到节点的延迟，不是端到端延迟。访问日本服务不应该被送到欧洲出口，即使那个节点的数字看起来更低。
客户端与网络层的配合方式
客户端不只是网络层的使用者，它同时也是测量端。理解这个双重角色，就知道为什么客户端版本会影响连接质量。
| 客户端职责 | 产生什么数据 | 被谁使用 |
|---|---|---|
| 发起探测 | 各候选路径的质量样本 | 控制面算路 |
| 上报匿名统计 | 规则覆盖率、路径质量分布 | 规则库与节点运营 |
| 执行调度决策 | 按控制面指令切换路径 | 用户无感知 |
| 本地防护 | 异常连接检测 | 本机安全 |
第三项是用户最无感的：所有的路径切换都由客户端静默执行，用户不需要知道刚才发生过一次调度。
免费试用快连
注册即获试用额度，全功能开放，无需绑定支付方式。
下载客户端 查看常见问题