常见问题
节点越多越好吗？
不是。关键是入口离用户近、出口离目标近，并且路径之间可分辨。一百个质量雷同的节点不如三十个特征互补的节点。
为什么要按目标区域选出口？
因为客户端列表里的延迟是到节点的延迟，不是端到端延迟。访问日本服务应该选亚太出口。
高峰期为什么会变慢？
运营商互联拥塞。调度系统会重排候选集并切换出口，但物理层面的拥塞无法完全规避。
边缘节点会不会看到我的数据？
加密隧道的端点在我们的出口节点，边缘节点只做接入转发。数据在传输过程中始终是密文。
支持几台设备？
同账号多设备在线，各自独立选择接入与出口。
试用覆盖全部功能吗？
覆盖。
智能路径选择
路径选择不是查一张静态路由表，而是一个持续进行的动态过程。融合使用多种网络资源，动态根据网络状况调整数据传输路径。
- 收集各候选路径的实时质量指标。
- 按目标服务的区域归属缩小候选集。
- 剔除当前质量不合格的路径。
- 在剩余候选中选综合评分最高的一个。
- 在传输过程中持续复测，劣化即触发重算。
第 2 步常被忽略但很重要：访问日本服务的流量不应该被送到欧洲出口，即使那个节点的「节点延迟」看起来更低。
四步判断问题出在哪一层
跨境访问变慢可能出在四层中的任意一层，四步可以逐层排除。
- 本地接入层：本机到入口的时延是否正常，异常则先解决本地网络。
- 跨境链路层：中段时延与丢包是否随时段变化，异常则应调整路径策略。
- 出口与目标层：更换出口后是否改善，不改善则问题可能在目标侧。
- 终端与协议层：CPU 占用与协议选择是否成为瓶颈，必要时更换协议形态。
分层判断与处置
| 层 | 判断依据 | 处置 |
|---|---|---|
| 本地接入 | 接入时延高于同区域基线 | 排查本地网络与路由器 |
| 跨境链路 | 高峰时段劣化明显 | 启用路径调度，避免固定远端节点 |
| 出口与目标 | 更换出口无改善 | 属于目标侧问题 |
| 终端与协议 | CPU 占满或重传多 | 更换协议形态或降低并发 |
怎么判断是不是目标侧的问题？
用同一出口访问其他同类目标，若都正常则说明问题在目标侧。
路径调度会不会频繁更换出口？
不会。只有在质量指标明显劣化时才会切换，避免无谓抖动。
协议形态可以手工切换吗？
可以在设置中切换，但通常建议交给自动策略处理。
实现细节与参数取值
边缘节点解决的是「第一跳」问题。如果入口离用户很远，第一跳就消耗掉了本可以在骨干段省下的时间。我们在全球部署边缘节点，用户请求先就近接入，再由边缘节点进入优化后的骨干路径。
软件定义广域网把「算路」和「转发」拆开：控制面根据实时测量计算路径，数据面按算好的路径转发，测量面持续探测并反馈。三者构成闭环，任何一层的调整都不需要改动其他两层。
| 平面 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 控制面 | 路径计算 | 质量指标 + 节点负载 | 选定路径 |
| 数据面 | 按路径转发 | 控制面决策 | 实际数据流 |
| 测量面 | 探测与反馈 | 主动探测 + 被动统计 | 质量指标 |
性能数据与测量方法
路径选择是持续进行的动态过程，而不是查一张静态路由表。系统融合多种网络资源，动态根据网络状况调整数据传输路径，确保在网络拥堵时仍能维持可用体验。
以上数据的测量方式统一为：同一台设备、同一时段、同一目标服务，开关对应功能各测三轮并取稳定段均值。我们公开测量方法的原因很简单——没有方法的数字无法验证，也无法复现。
边界条件与已知限制
| 限制 | 原因 | 影响 | 缓解方式 |
|---|---|---|---|
| 共享瓶颈 | 两条路径同一上游 | 多路径收益接近于零 | 更换出口区域 |
| 水位过高 | 容量不足 | 高峰期丢包上升 | 触发扩容 |
| 回程未优化 | 只测量去程 | 实时业务体感差 | 双向分别测量 |
节点列表里的延迟数字是客户端到节点的延迟，不是端到端延迟。访问日本服务不应该被送到欧洲出口，即使那个节点的数字看起来更低。
关于网络层的常见疑问
| 疑问 | 回答 |
|---|---|
| 节点越多越快吗 | 不是。关键是入口离用户近、出口离目标近，且路径之间可分辨 |
| 为什么要按目标区域选出口 | 客户端显示的延迟是到节点的延迟，不是端到端延迟 |
| 高峰期为什么变慢 | 运营商互连拥塞。调度会重排候选并切换出口，但物理拥塞无法完全规避 |
| 边缘节点能看到数据吗 | 隧道端点在出口节点，边缘节点只做接入转发，全程密文 |
| 为什么有时速度不如预期 | 先排除本地无线瓶颈，再检查所选出口是否匹配目标区域 |
免费试用快连
注册即获试用额度，全功能开放，无需绑定支付方式。
下载客户端 查看常见问题