本文记录了某企业通过飞连 SD-WAN 访问海外视频网站（如 Netflix）时遭遇卡顿，最终定位为客户端 DNS 配置错误导致应用调度失效的真实排障案例。通过借鉴此案例，管理员可以了解 SD-WAN 应用调度的底层路由逻辑，并掌握相关的 DNS 代理排障方法。

问题现象 #

用户通过 SD-WAN 分支选路访问国外视频网站（Netflix）时出现严重卡顿，主要表现为：视频开始播放前会经历长时间的起播延迟（首屏加载时间长，持续 30 秒至 1 分钟以上），

环境与拓扑确认 #

在开始排查前，需明确当前的组网拓扑：

• 明确流量的上车点 CPE（客户端接入侧）与下车点 CPE（海外出口侧）。
• 确认两端 CPE 均已下发并启用了对应的应用调度配置。

排查过程 #

1. 基础连通性测试（排除底层网络故障） #

• 操作：在终端侧使用 ping 和 curl 测试主域名 www.netflix.com，并使用 tracert（或 traceroute）检查路由路径。
• 结果：测试显示网络无延迟，且 tracert 结果表明去往主域名的流量确实经过了上车点及下车点 CPE 的隧道转发。
• 初步结论：底层 SD-WAN 隧道连通性正常，非全网断网。

2. 抓包分析定位异常域名 #

• 操作：由于主页能打开但视频卡顿，推测是页面内的关联资源加载失败。打开浏览器开发者工具（F12）-> 切换到 Network（网络）​标签页，观察加载缓慢的请求。
• 结果：卡顿主要由 Netflix 跳转资源加载超时引起（查看 Network 面板中请求处于长时间 Pending 或高延迟状态的域名），如 nflxso.net 与 nflxvideo.net。这些视频资源域名并未包含在飞连管理后台下发的“应用调度”域名列表中。
  

经验总结：如何获取关联资源域名？
在排查类似“主页能开、内容刷不出”的问题时，必须通过 F12 抓包，在 Network（网络）面板中，提取“域”列出现的所有域名并加入到应用调度名单中。

3. 补充域名后路由依然异常（定位调度失效） #

• 操作：在飞连管理后台将缺失的资源域名补充进调度列表，下发配置后再次使用 tracert 测试。
• 结果：加载缓慢问题依旧。通过 tracert 命令追踪发现，虽然流量第一跳到达了上车点 CPE，但后续路由直接进入了公网网段，并未通过隧道转发（正常的 SD-WAN 转发路径中应当出现下车点 CPE 的隧道 IP，例如 169.254.x.x）。
  
  
• 深层路由确认：登录上车点 CPE，检查系统路由表。从下方截图可以清楚看到，该资源域名解析出的 IP 没有匹配到去往 SD-WAN 隧道网卡（如 tun0）的路由规则，而是直接匹配了默认路由，通过物理接口（WAN 口）发送到了公网。这表明应用调度完全没有生效。
  

4. 拆解分析 DNS 代理机制 #

应用调度的核心原理是“DNS 劫持代理”：客户端向 CPE 发起 DNS 请求 -> CPE 识别到这是调度域名 -> CPE 将其解析为特定 IP 并强行引入隧道。
既然调度未生效，需排查解析链路：

1. 检查 CPE 配置下发
   查看 CPE 的应用调度配置文件 /etc/dnsmasq.d/gfw_domain.conf。如下方截图所示，通过 cat 命令确认目标域名已被正确写入文件，说明云端中心管控配置下发无异常。
   
2. 检查 CPE 本地解析能力
   在 CPE 本地执行 dig <异常域名> @127.0.0.1。如下方截图所示，dig 命令成功返回了 IP 地址（存在 ANSWER SECTION），说明 CPE 的 dnsmasq 代理服务本身运行正常，没有故障。
   
3. 检查 CPE 接收请求情况（关键点）
   查看 CPE 的 DNS 查询日志 /opt/feilian/cpe/log/dnsmasq.query.log。从截图中可以看到，在故障时间段内，CPE 没有收到过来自客户端关于该域名的解析记录（日志为空或仅有其他无关域名）。
   
4. 检查终端 DNS 设置
   在确认 CPE 未接收到 DNS 请求后，需排查客户端自身的网络配置，以确认 DNS 请求的实际去向。检查 PC 终端的网络适配器，如下方截图所示，发现其 IPv4 属性中的 DNS 服务器地址被手动（或 DHCP 错误下发）设置为了公网 DNS 8.8.8.8 （Google DNS），而非 CPE 的 LAN 口 IP，导致应用调度未能触发。
   
5. 补充验证：辨析 IP 调度与应用调度的差异
   在上述排查中，一个容易引起困惑的现象是：既然客户端的 DNS 并没有指向 CPE（应用调度已失效），为什么一开始测试的主域名（www.netflix.com）却能成功通过隧道转发？
   这涉及飞连 CPE 中两种调度机制的优先级与工作原理差异：
   • 调度优先级：在飞连 CPE 的选路逻辑中，应用调度（基于域名代理）的优先级高于 IP 调度（基于目标 IP 网段）。从下方截图的配置文件中可以看出：优先级标识 1 代表域名调度优先；2 代表 IP 调度优先。
     
   • 原因剖析：虽然客户端越过了 CPE 直接向 8.8.8.8 请求了解析，导致应用调度失效，但主域名解析出的目标 IP 恰好包含在飞连后台下发的“海外 IP 调度列表”中（见下方配置截图）。因此，当流量到达 CPE 时，触发了底层的 IP 调度规则，流量被顺利送入隧道。而视频资源域名解析出的 IP 不在列表中，且应用调度因 DNS 旁路而失效，最终导致流量直接走本地公网被阻断。
     

根本原因总结 #

下车点 CPE 虽配置了完整的 IP 调度和应用调度，但客户端 PC 使用了外部公网 DNS（如 8.8.8.8），导致域名解析请求未经过 CPE 的 dnsmasq 代理，应用调度彻底失效。
在这种情况下，只有命中了 IP 调度规则的主域名流量走了隧道；而视频资源域名既未命中 IP 调度，又失去了应用调度，流量被发往本地公网（无法访问海外资源），从而表现为页面框架已加载，但视频一直处于高延迟缓冲状态。

最终解决方法 #

1. 修正客户端 DNS 指向：将故障客户端 PC 的 DNS 服务器地址，手动修改为上车点 CPE 的 LAN 口 IP 地址（如果是通过 DHCP 下发，需修改 DHCP Server 的 DNS 配置），确保所有 DNS 请求被 CPE 代理接管。
2. 补全应用调度名单：在飞连管理后台的应用调度配置中，确保已将所需的外部资源域名（如 nflxso.net、nflxvideo.net）全部录入。

排障思路总结 #

基于上述真实案例，当您在日常运维中遇到“某个网站/应用配置了 SD-WAN 调度但依然卡顿或无法访问”时，可参考以下排障思路进行定位：

1. 抓包补全资源域名
   • 现代网站（尤其是视频、网盘、大型 SaaS）通常由主域名和大量 CDN 资源域名组成。
   • 动作：不要只将主域名加入调度列表。必须通过浏览器 F12 > Network 抓包，找出耗时极长或加载失败的外部资源域名，一并加入应用调度名单。
2. 验证流量是否入隧道
   • 确认域名名单无误后，需验证流量是否真的被调度。
   • 动作：使用 tracert 或 traceroute 命令追踪目标域名。如果路由跳数中未出现 CPE 隧道 IP（169.254.x.x），则说明调度未生效，流量走了本地公网。
3. 确认 DNS 代理链路
   • 飞连的“应用调度”强依赖于 CPE 对终端 DNS 请求的代理劫持。若终端的 DNS 请求未发送至 CPE，则应用调度无法触发。
   • 动作：
     • 查终端：终端的 DNS 必须指向 CPE 的 LAN 口 IP。请勿将其手动配置为 8.8.8.8 或 114.114.114.114 等公网服务器。
     • 查日志：登录 CPE 查看 /opt/feilian/cpe/log/dnsmasq.query.log，确认是否有终端发来的域名解析请求。