跳转至

多 WAN 策略路由错配决策树：微信能发图、飞书发不出图片怎么查

企业办公网里见过一种很迷惑的故障：员工说"飞书发不出图片和文件，但文字聊天好好的，微信图片却一点事没有"。第一反应常被带偏成"飞书服务器挂了"或"飞书客户端 bug"，甚至有人去查 DNS——结果飞书网页端能登录、文字能发，唯独富媒体卡住。

这类故障的核心特征是 "单应用、单流量类型"异常：它区分不了"全站都挂"和"只有某条应用的媒体流被错分出口"。下面这张决策树专门处理多 WAN 环境下"部分 SaaS 媒体流不通"这一类。

60 秒判断：是不是出口路由问题

用一句话自测：

微信图片正常、飞书图片/文件发不出但文字正常；或者 A 应用正常、B 应用只卡媒体 → 高度怀疑多 WAN 策略路由把媒体流错分到了不通的出口。

如果所有应用、所有流量都卡，那是某条 WAN 整体断了或网关问题，不在本文范围。

排障决策树

用户反馈：飞书能登录能打字，但图片/文件发不出（微信正常）
  │
  ├─ 先确认范围
  │    ├─ 只有飞书媒体卡？其他 SaaS 正常？→ 单应用媒体流问题（看策略路由）
  │    └─ 多个 SaaS 的媒体都卡？         → 可能主用 WAN 整体拥塞/故障（看 WAN 状态）
  │
  ├─ 解析层确认（排除 DNS）
  │    ├─ nslookup 飞书媒体域名 正常返回 IP？
  │    │     → 解析没问题，不是 DNS，往下查出口
  │    └─ nslookup 超时/错返？            → 先去查 DNS 下发（见内网 DNS 决策树）
  │
  ├─ tracert -d <飞书媒体服务器 IP>
  │    ├─ 第一跳就走了"故障/拥塞 WAN"的网关？→ 策略路由把这段 IP 错配了 ★最常见
  │    └─ 走了正确 WAN 但仍丢包？         → 该 WAN 链路本身问题（看链路质量）
  │
  ├─ 登录路由器核对策略路由（PBR）表
  │    ├─ 匹配飞书媒体 IP 段的规则指向了错误下一跳？→ 修正规则到主用 WAN
  │    ├─ 根本没这条规则、却按源 VLAN 被默认归到了备用 WAN？→ 补显式规则
  │    └─ 规则存在但"源接口"条件漏了新 VLAN？→ 把新 VLAN 纳入策略
  │
  └─ 根因定位
       ├─ 切到备用/默认出口飞书即恢复？→ 坐实错配，临时止血
       └─ 仍不通？→ 不是路由，去查该 WAN 链路质量或飞书侧

决策树的核心就一句：先分清"DNS/服务器"还是"出口选路"，再决定去查域名还是查路由表。前面那步 tracert 是整个判断的支点——它直接暴露媒体 IP 实际走了哪条 WAN。

三步定位命令

第一步：确认不是 DNS，并拿到媒体真实 IP

nslookup <飞书媒体域名>          :: 解析正常说明不是 DNS 问题，记下返回的一个媒体 IP
ping <该媒体 IP>                :: 能通说明三层可达，问题在"选路"不在"可达"

说明：SaaS 的媒体 CDN 域名常常和登录域名不同，要查的是"媒体/文件"那类的域名，不是登录域名。

第二步：看媒体流量实际走了哪条出口

tracert -d <飞书媒体 IP>        :: 第一跳网关的地址能看出走了哪条 WAN

把 tracert 第一跳的网关 IP，和路由器上各 WAN 接口的网关地址比对：如果它落到了那条"本来就不该承载飞书媒体"的 WAN，就是策略路由错配。

第三步：登录路由器核对策略路由与路由表

show ip route                              :: 看目的 IP 段匹配到哪条路由、下一跳是谁
show route-map / show policy-map           :: 看 PBR 策略（命令因厂商而异）
display policy-based-route                  :: 华为系常用

关键看：匹配飞书媒体 IP 段的规则，目的接口是不是主用 WAN；以及这条规则的"匹配条件"有没有漏掉出问题的内网 VLAN/源地址段。

一键应急：临时切回正确出口

下面这段不是脚本，而是在路由器上临时改路由的核对清单——这类操作必须在设备上做，没法用终端脚本代替，所以这里只给"该看什么、该改什么"，不假装能远程执行：

1. 确认飞书媒体 IP 段（从官方文档或 nslookup 实测拿到，至少 /24 粒度）
2. 在策略路由里为这段 IP 显式指定主用 WAN 接口 + 正确下一跳
3. 保存前先 session 测试：tracert 该 IP 应立刻走主用 WAN
4. 飞书图片恢复后，再把这条规则固化进配置并备份

诚实说明：多 WAN 策略路由的修复必须在路由器/防火墙设备上完成，终端侧没有等效脚本。上面是排障与改配的核对清单，不是可复制运行的代码；具体命令随厂商（Cisco/Juniper/华为/飞塔）差异很大，务必以你设备文档为准。

治本：让"错配"不再发生

单台切回只是止血。多 WAN 环境每增加一个 SaaS，就多一组媒体 IP 段要纳管，按这三层收口：

层级 动作 防的是什么
路由层 梳理并绘制多 WAN 路由总表；飞书/钉钉/会议等核心 SaaS 的媒体 IP 段显式指主用 WAN 媒体流被错分到故障/拥塞出口
流程层 建立《新增 SaaS 网络策略评估 SOP》：上线前必须拉官方 IP 段、写进 PBR、指定责任人 新增应用漏配、IP 段变更无人同步
监控层 对核心 WAN 链路做质量探测（时延/丢包/抖动），主用劣化自动告警或切备 主用 WAN 悄悄劣化却没人知道

一个常被忽略的点：SaaS 的媒体 IP 段会随厂商调度变化。钉钉、飞书、腾讯会议的媒体 CDN 都会动态扩段，评估 SOP 里必须写清"谁负责跟进 IP 段变更、变更后多久同步到路由"，否则今天配好的规则三个月后就过期。

决策速查表（拿来即用）

现象 第一反应（误判） 真实根因 该去查哪
微信图正常、飞书图发不出 飞书服务器宕机 / 客户端 bug 飞书媒体 IP 段被 PBR 错分出口 tracert 媒体 IP + 策略路由表
文字正常、图片卡 DNS 解析异常 非对称路由 / 媒体流出口不通 比对 WAN 网关、查链路质量
某 VLAN 全部门异常、其他 VLAN 正常 飞书针对该部门限流 新 VLAN 漏纳管进策略路由 PBR 源接口/源地址条件
切备用出口即恢复 问题消失不用管 只是止血，错配还在 固化主用出口规则
nslookup 媒体域名超时 飞书媒体服务器挂了 其实是 DNS 下发错（见 DNS 决策树） 终端 ipconfig /all 的 DNS

这张表就是"最容易被误判成什么"的落地版——这类工单开头八成被报成"飞书坏了"，按表反着查能省掉一大半无效排查。

常见问题（FAQ）

Q：为什么微信正常、偏偏飞书发不出图片？
A：微信和飞书的媒体走不同厂商的 CDN/对象存储，IP 段不同。多 WAN 路由按"目的 IP"选出口，一旦策略路由把飞书媒体那段 IP 错配到故障或拥塞的那条 WAN，飞书图片/文件就卡住；微信媒体 IP 落在另一条正常 WAN 上所以照常。文字聊天走长连接信令，和媒体不是同一出口路径，因此文字正常。

Q：tracert 看到飞书媒体 IP 走了错误出口，怎么确认是策略路由的问题？
A：登录路由器看 show ip route 和策略路由（PBR）表，找到匹配飞书媒体 IP 段的那条规则，核对它指向的下一跳/WAN 接口。再临时把该流量切到备用 WAN（或删掉错配规则走默认路由），飞书恢复即坐实。注意比对"源接口/源地址"条件——很多企业按内网 VLAN 做策略，错配常发生在新增 VLAN 没纳管时。

Q：切到备用出口就恢复，是不是可以不管了？
A：切备用只是止血。备用 WAN 一旦也出问题故障会复发；非对称路由（去程走 A、回程走 B）还会引发部分 CDN 源站校验失败。必须回到策略路由表，把飞书及同类 SaaS 的媒体 IP 段固化到正确主用出口，并写进评估 SOP，新增应用才不会再踩。

Q：新增一个 SaaS 最容易在哪踩坑？
A：最容易在"只配了域名白名单、没配媒体 IP 段"。SaaS 的登录域名和媒体 CDN 域名往往不同，媒体 IP 段又常随厂商调度变化。评估 SOP 必须要求拉出该 SaaS 官方公布的媒体/通话服务器 IP 段，在策略路由里显式指向主用 WAN，并预留"IP 段变更→路由同步更新"的责任人。

Q：这种故障和 DNS 解析异常怎么区分？
A：DNS 异常会让整个域名（包括登录）都失败，且 nslookup 媒体域名会得错误/超时结果；本类是"域名能解析、登录正常、唯独媒体流卡在出口"。一句话区分：nslookup 飞书媒体域名正常、但 tracert 其 IP 走了错误 WAN，就是策略路由，不是 DNS。

延伸阅读与参考

本文是面向运维排障的决策资产，外部链接仅作权威概念与官方 IP 段出处；具体路由命令随设备厂商差异很大，以你设备文档为准。

相关教程与工具

本文故障案例来自一线办公网现场，作为判断依据的可信锚点；具体 IP 段与命令以你内网实际地址与设备为准。