SD-WAN 线路怎么选？从业务需求到上线验收

更新于 2026-11-01 · sailingnet.shop

简答：先确定业务对延迟、丢包、抖动、带宽和连续性的优先级，再选择单线路、双公网、专线+公网或专线+移动网络。SD-WAN 本身不是一条独立线路，而是利用一条或多条底层网络，并按策略和链路质量为应用选路；因此最终体验取决于底层线路、设备、路径、策略和运维。

定义：SD-WAN 线路选型，是根据业务、站点、地区和质量目标，为 SD-WAN 选择并组合公网、专线、移动网络或云互联等底层连接，同时通过 PoC 和 SLA 验证实际交付能力。

结论速查：先按业务和风险选组合

如果你正在比较多家线路，最短判断方法不是先问“多少兆”，而是先回答四个问题：业务是否实时、是否跨地区或跨境、单条线路中断能否接受、故障时是否需要自动切换。网络性能通常同时受到带宽、延迟、抖动、丢包、位置、拥塞和路由规则影响，不能用带宽一个指标代替全部体验。可先参考 AWS 混合连接性能说明和 AWS 混合网络设计原则。

业务或目标	优先关注	常见起步组合	上线前必须验证
普通办公、网页、邮件	成本、可用性、扩容	双公网或公网+4G/5G	高峰期丢包、DNS、故障切换
视频会议、VoIP、实时协作	抖动、丢包、连续性	质量较稳定的主链路+公网备线	语音和视频实际通话、切换时长、回切策略
ERP、数据库、交互式系统	往返延迟、稳定性、路径	专线或高质量企业接入+公网备线	真实事务响应、跨站点双向测试、峰值时段
跨境办公、跨境 SaaS	目标地区路径、国际段质量、故障绕行	专线或企业级连接+第二运营商公网	两端双向延迟、丢包、应用可达性和出口路径
大文件、备份、数据同步	吞吐、并发流、窗口期	高带宽公网或专线组合	单流与多流吞吐、TCP 传输表现、备份时段拥塞

一句话建议：实时业务优先稳定质量，普通办公优先冗余和成本，大流量业务优先吞吐与扩容；任何场景都应保留至少一个可验证的故障回退路径。

前置条件：采购线路前先把需求写成表

在询价前，先建立一张“业务—站点—线路—指标”表。AWS 的网络架构建议也要求记录延迟、带宽、协议、位置、流量模式、吞吐、加密、检查和路由规则等需求，不能只填写一个带宽数字。参考 AWS 网络性能要求清单。

业务：列出 ERP、视频会议、VoIP、跨境 SaaS、文件传输和备份，并标注是否实时、是否允许短暂中断。
站点：记录总部、分支、云区域、用户所在地、出口位置和预计新增站点。
流量：记录工作日平均值、峰值、并发用户、上下行比例，以及主链路故障时备线需要承载的最低流量。
质量：分别设定可接受的延迟、丢包、抖动、可用性和切换时间。没有实测数据时，不要把本文的示例组合写成服务承诺。
管理：确认是否需要应用识别、按业务选路、负载分担、链路回切、日志、告警和 API；具体能力必须以当前产品文档和合同为准。

SD-WAN 的关键在于它可以使用一个或多个底层连接，并按照策略管理应用流量。MEF 对 SD-WAN 的定义也明确提到底层连接、基于策略的流量管理、应用流和边缘之间的加密等特征；因此采购时应把“SD-WAN 控制能力”和“底层线路交付范围”分开核对，参考 MEF SD-WAN 服务属性资料。

最短流程：五步完成 SD-WAN 线路选型

先按业务排序。把业务分为实时、交互、大流量和普通办公四类，分别写出最不能接受的问题：卡顿、响应慢、同步超时，还是整体断网。
再选底层线路类别。公网宽带适合成本敏感和可用公网路径的业务；MPLS 常被用于企业站点互联和可控的运营商网络；DIA 通常强调企业独享的互联网接入属性；IPLC 更适合需要跨地域专用连接的场景；4G/5G 适合作为快速部署、临时接入或备线。实际覆盖、路径、交付周期、地址资源和 SLA 必须向供应商逐项核实。
设计至少一条回退路径。常见方案包括双公网、专线+公网、专线+4G/5G。两条线路如果共享同一入楼光缆、同一机房、同一运营商或同一出口，名义上的双线不一定是真正的独立冗余。
定义选路策略。实时业务通常优先质量更稳定的链路，普通大流量业务可以考虑负载分担；当链路质量不满足业务要求时，策略应能切换到备用链路，并明确是否自动回切。华为云文档展示了按延迟、丢包和抖动配置业务选路、切换与回切的做法，但字段和菜单会因设备或版本变化，不能直接当作其他厂商的配置步骤，参考华为云智能选路配置案例。
用 PoC 验收，不用报价单验收。至少覆盖工作日高峰、非高峰、真实业务、双向路径、主备切换、恢复回切和故障日志。

推荐：如果你已确定办公地点、目标地区和业务类型，可把线路组合、延迟丢包测试与故障切换验收一起纳入边界云加速的网络方案评估。

线路类型怎么比较：不要把“专线”当成统一答案

下表是选型框架，不代表任何运营商的固定性能、价格或交付范围。相同名称的线路，在接入位置、国际段、运营商互联、末端距离、出口和 SLA 口径不同的情况下，实际结果可能不同。

线路类型	通常适合	主要优点	需要重点追问
公网宽带	普通办公、互联网访问、成本敏感场景	部署普遍较快，扩容方式相对灵活	高峰期拥塞、出口路径、对等互联、是否支持固定地址和故障响应
MPLS	多分支互联、对路径和运营商管理有要求的企业网络	便于纳入运营商级企业网络服务	覆盖范围、跨运营商段、末端接入、带宽升级和端到端 SLA
DIA	需要企业互联网接入和较明确交付边界的站点	适合把互联网接入作为可管理的企业线路来采购	是否真正独享、上下行规格、路由和地址资源、故障界面
IPLC 或其他跨地域专用连接	对跨地域路径、稳定性或专用连接有要求的业务	便于围绕指定地点和路径进行工程化设计	两端接入、国际段和末端是否包含、绕行方案、施工周期与合规要求
4G/5G	备线、临时站点、快速恢复或不便布线的场景	部署灵活，适合与固定线路形成异构备份	信号、资费与流量限制、地址类型、运营商覆盖、室内天线和高峰期波动

云互联也不能只看“有无专线”。例如云厂商文档会区分单连接、冗余连接、服务商覆盖范围和 SLA 边界；Google Cloud 明确说明部分 SLA 只覆盖云网络到服务商网络的连接，用户网络到服务商网络的部分还要看服务商合同，参考 Google Cloud Partner Interconnect 说明。因此跨云或跨境场景必须核对端到端责任边界。

PoC 验收：用真实业务确认线路是否合适

没有本项目实测数据，以下是可复用的核验框架，不是固定达标数值。测试时应记录测试时间、两端地址、线路标识、协议、包大小、并发量、主备状态和结果。

基线测试：在工作日高峰和非高峰分别测试两端往返延迟、丢包和抖动；至少做双向测试，避免只测单方向。
真实应用测试：使用实际 ERP、视频会议、VoIP、文件传输或 SaaS 流程，记录登录、查询、保存、通话、上传和下载是否出现超时或重传。
负载测试：模拟正常峰值和故障后由单条线路承载的流量，观察带宽利用率、队列、CPU、隧道和应用响应。
切换测试：在主线路可控中断时记录业务中断时间、会话是否重建、DNS 是否受影响、备用线路是否承载正确流量。
恢复测试：恢复主线路后确认是否自动回切、是否出现来回抖动，以及回切期间是否丢失会话。
留存证据：保存监控图、路径信息、设备日志、应用日志和供应商工单，作为上线验收与后续 SLA 核对依据。

对于需要可预测性能的云连接，官方文档同样强调冗余拓扑和连接边界；例如 Google Cloud 的互联说明要求根据可用性目标配置冗余连接，而不是把单条连接直接视为高可用方案，参考 Google Cloud Dedicated Interconnect 说明。

SLA 与总成本：报价单之外还要看什么

SLA 至少核对六项：

可用性如何计算：按月、按链路、按端口，还是按端到端业务。
故障边界在哪里：是否覆盖末端接入、国际段、运营商互联、设备、云连接和客户侧 CPE。
延迟、丢包和抖动是否写入承诺，还是只提供可观测数据。
故障响应、升级、现场支持和预计恢复时间分别是多少。
维护窗口、计划中断、不可抗力、客户配置错误和第三方故障如何排除。
赔付是服务抵扣还是其他形式，是否需要客户主动提交监控证据。

云厂商公开 SLA 也可能只覆盖服务链路的一部分，并受拓扑、配置和客户义务限制，不能把云端 SLA 自动延伸为企业办公室到应用的端到端承诺。可参考 Google Cloud Interconnect SLA。

总成本应按月和项目周期分别计算：线路费、安装费、CPE 或路由设备、机房或托管、IP 地址、云端端口、流量费、备线、监控、运维、人力、扩容和迁移都应列入。若供应商只给出“每月多少兆多少钱”，应要求补充一次性费用、最低承诺、超额费用、升级周期和取消条件。

边界与延伸：哪些情况不适合直接采购高规格线路

如果问题实际来自 DNS、MTU、Wi-Fi、终端网卡、应用服务器或错误路由，单纯升级线路可能无法解决。
如果只有一个站点、业务主要访问普通互联网、也没有连续性要求，先做双公网和故障切换 PoC，未必需要复杂专线。
如果目标是跨境办公，必须拆开测试本地接入、出口、国际段、目标地区入口和应用服务端，不能用办公室到最近测速点的结果代表业务体验。
如果业务需要加密、身份控制或访问隔离，应同时核对隧道、密钥、访问策略和日志能力；SD-WAN 的线路质量能力不等于完整安全方案。
如果供应商拒绝提供线路标识、测试窗口、责任边界或故障记录，先缩小采购承诺，改为 PoC 或可退出的试运行。

截至 2026 年 11 月 1 日，本文不提供任何线路测速、价格或可用性保证；具体版本、菜单、字段、覆盖区域和 SLA 以当前供应商页面、合同及现场测试结果为准。

常见问题

SD-WAN 是不是必须搭配专线？

不是。SD-WAN 可以使用一条或多条底层连接，底层可以是公网、企业互联网接入、专线或移动网络。是否使用专线，应由业务对延迟、丢包、连续性、路径和 SLA 的要求决定，而不是由 SD-WAN 这个名称决定。

SD-WAN 线路怎么选才不会只看带宽？

先按业务记录延迟、丢包、抖动、吞吐和可用性要求，再比较线路组合、路径独立性、故障切换、运维范围和 SLA。带宽只能说明传输能力，不能单独代表交互响应、视频通话质量或跨境应用体验。

专线加公网一定比双公网好吗？

不一定。专线加公网通常能形成不同类型的回退路径，但如果两条线路共享同一接入、机房或出口，实际冗余可能有限；双公网如果来自不同运营商、入口和路径，也可能更适合成本敏感场景。最终应通过故障切换和高峰期 PoC 验证。

跨境办公选择线路时最容易漏掉什么？

最容易漏掉国际段、目标地区入口、运营商互联、两端末端接入和 SLA 责任边界。应从办公地点到实际应用服务端做双向测试，并分别记录本地接入、出口、跨地域路径和应用层结果。

如何判断线路 PoC 是否通过？

先为每类关键业务定义成功标准，例如真实查询、通话、文件传输和故障切换都能完成；再在高峰与非高峰测试，记录延迟、丢包、抖动、吞吐、切换时间、会话恢复和日志。没有明确标准或只测测速点，不应直接作为上线依据。